стопроцентная уязвимость, пореверсил v2raytun под мак, выглядит как у них общая кодовая база с ios . и вот там также поднимается экстеншен и в нем заводится локал хост к которому можно прицепиться без авторизации
это конечно какой-то хайвмайнд, но как раз недавно закончил делать vless-tun командлайн-кли под мак и выложил в прошлую пятницу
ну и на фоне этих событий как раз проверил v2raytun и подтвердил слова автора (по крайней мере касаемо вектора атаки и уязвимости конкретно этого клиента) , статью также выложил в этой репе
Если у вас нет необходимости, можете не растить, джун сам уйдет со временем, а потребность останется та же. Вам надо налаживать ротацию кадров, низкий порог входа, чтоб каждый новый такой джун быстро мог влиться в рутину.
Мы не храним сторонние библиотеки в репозитории с проектом — они подключаются только на локальной машине. В git попадает чистый проект с внешними зависимостями.
Обычно мы добавляем одну и ту же зависимость и как локальную, и как удалённую. В таргете всегда указываем ремоут, а локал нужен лишь для удобства разработки: так быстрее резолвятся зависимости и проще править код прямо в проекте.
На CI/CD все локальные подключения убираются, происходит "честная" сборка с удалёнными зависимостями. Это позволяет сразу отловить забытые изменения — они всплывают на этапе merge request.
Такой подход даёт гибкость: можно временно подключить нужный пакет локально, поработать с ним, потом убрать — не влияя на чистоту основной сборки.
Да, если зависимостей становится слишком много и они занимают ощутимый объём, есть смысл хранить их на внешнем накопителе — это решает проблему с ограниченным местом на диске.
Привет. Столько, сколько весит кодовая база приложения и всех депенденсов, которые положили локально. Мы готовы пожертвовать местом на диске в угоду скорости резолва зависимостей в хкоде. Особенно учитывая, что это происходит достаточно часто
стопроцентная уязвимость, пореверсил v2raytun под мак, выглядит как у них общая кодовая база с ios . и вот там также поднимается экстеншен и в нем заводится локал хост к которому можно прицепиться без авторизации
это конечно какой-то хайвмайнд, но как раз недавно закончил делать vless-tun командлайн-кли под мак и выложил в прошлую пятницу
https://github.com/relux-works/multi-tun
ну и на фоне этих событий как раз проверил v2raytun и подтвердил слова автора (по крайней мере касаемо вектора атаки и уязвимости конкретно этого клиента) , статью также выложил в этой репе
https://github.com/relux-works/multi-tun/blob/main/artifacts/v2raytun-localhost-vs-vless-tun/README.md
артефакты аудита лежат в той же иерархии, для тех кому интересно
конечно потенциальный клиент айос разработки, в чем вообще вопрос?
Если у вас нет необходимости, можете не растить, джун сам уйдет со временем, а потребность останется та же. Вам надо налаживать ротацию кадров, низкий порог входа, чтоб каждый новый такой джун быстро мог влиться в рутину.
Мы не храним сторонние библиотеки в репозитории с проектом — они подключаются только на локальной машине. В git попадает чистый проект с внешними зависимостями.
Обычно мы добавляем одну и ту же зависимость и как локальную, и как удалённую. В таргете всегда указываем ремоут, а локал нужен лишь для удобства разработки: так быстрее резолвятся зависимости и проще править код прямо в проекте.
На CI/CD все локальные подключения убираются, происходит "честная" сборка с удалёнными зависимостями. Это позволяет сразу отловить забытые изменения — они всплывают на этапе merge request.
Такой подход даёт гибкость: можно временно подключить нужный пакет локально, поработать с ним, потом убрать — не влияя на чистоту основной сборки.
Да, если зависимостей становится слишком много и они занимают ощутимый объём, есть смысл хранить их на внешнем накопителе — это решает проблему с ограниченным местом на диске.
Привет. Столько, сколько весит кодовая база приложения и всех депенденсов, которые положили локально. Мы готовы пожертвовать местом на диске в угоду скорости резолва зависимостей в хкоде. Особенно учитывая, что это происходит достаточно часто