Тот факт, что риск можно купировать с помощью песочницы, не делает сам метод доставки кода безопасным по определению.
Главный риск здесь даже не в отсутствии песочницы, а в отсутствии неизменяемого артефакта. При скачивании бинарника у меня есть файл > хеш > возможность аудита. При pipe в bash я исполняю то, что сервер решил прислать мне именно в эту миллисекунду. Даже если я запущу это в контейнере, я все равно исполняю “черный ящик”, который может вести себя по-разному при каждом перезапуске. подробнее уже писал ниже, чтобы я не повторялся, можете прочитать
Они сначала не спрашивают, но обычно предупреждают: имейте в виду, что если вы продолжите пополнять счёт, банк может запросить подтверждение источника дохода. У меня так было. Я ответил: “Без проблем, запрашивайте”. Но до этого не дошло.
Вы смешиваете психологию пользователя и техническую безопасность метода. По логике “всё равно никто не проверяет”, можно вообще перестать подписывать пакеты цифровой подписью или перестать использовать HTTPS, ведь обычный пользователь не проверяет цепочки сертификатов в браузере.
При make install или запуске локального файла пользователь запускает статичный объект. Если завтра этот софт признают вредоносным, у пользователя остался артефакт (файл), который можно отправить в вирусный анализ или сравнить с версией из репозитория.
pipe в bash - это запуск динамического потока. Сервер может отдавать разный код в зависимости от вашего IP, User-Agent или времени суток. Это позволяет реализовать таргетную атаку: 99% пользователей получат чистый установщик, а один конкретный администратор с определенным IP - бэкдор. В этом случае никакой “цифровой гигиены” не поможет, потому что код, который был исполнен, никогда не существовал в публичном репозитории и не сохранился на диске.
Аргумент “пользователи всё равно не проверяют” в безопасности не работает. Это как сказать, что подушки безопасности в авто бесполезны, потому что большинство водителей не читают инструкцию к ним. Инструмент должен быть безопасен по определению, а не полагаться на внезапную бдительность юзера.
Что касается контейнеризации - это не “мода”, а банальный принцип изоляции. Если однокнопочный скрипт окажется вредоносным и попытается снести систему через rm -rf / или переписать /etc/shadow, контейнер ограничит его влияние только своей средой, а запуск напрямую в ОС - нет. Удобство установки не должно идти в ущерб базовой безопасности системы.
Проблема “pipe в bash” не в том, что это “сложнее”, а в том, что это исключает возможность аудита кода перед запуском. Это, фактически, передача управления удаленному серверу в реальном времени. Сервер может отдать разный код в зависимости от вашего IP, User-Agent или времени суток. Это “черный ящик”, где между скачиванием и исполнением нет ни одной точки контроля.
С make install всё иначе: код локален. Можно проверить хеши скачанных файлов, открыть Makefile в текстовом редакторе перед запуском.
Что касается контейнеров, это не про “моду”, а про изоляцию. Чтобы какая-нибудь зависимость из сомнительного скрипта не затерла системные конфиги или не притащила в систему мусор, который потом придется вычищать вручную. Это вопрос гигиены системы, а не “девопсовства”.
Это может быть нормальным для Quick Start в тестовой среде, чтобы быстро проверить “взлетит или нет”. Но важно разделять PoC и полноценную установку. Для основной системы или продакшена пайп в bash - это недопустимый риск. Инструмент, который должен работать долго и надежно, ставится через репозиторий или пакеты, а не через слепой запуск скрипта из сети. Если пакетов нет, любую программу можно опакетить самому или контейнеризировать.
Это вопрос доверия к софту, которым вы пользуетесь. Если вы ему не доверяете, используйте песочницу. Сегодня хорошей практикой является запуск сервисов в контейнерах. А для пущей изоляции - чтобы процессы в контейнере не могли использовать zero-day эксплойты ядра - можно использовать gVisor.
Да, причём даже несмотря на то, что в компаниях часто используют свои локальные зеркала для этих пакетов. Компании нужно постоянно держать эти зеркала обновлёнными, либо обеспечивать им постоянный доступ к GitHub и другим официальным репозиториям пакетов для зеркалирования в реальном времени.
С точки зрения налогового права США (правила IRS), России (ФНС) и большинства других стран, сам по себе факт восстановления доступа к утерянному кошельку, подбор сид-фразы или ключа не является налогооблагаемым событием.
Покупка криптовалюты за фиатные деньги не создает налогооблагаемого дохода.
В глазах налоговых органов эти 5 BTC все это время принадлежали вам. Восстановление доступа — это просто техническое действие, а не получение нового дохода.
Налог на прирост капитала (Capital Gains Tax) возникнет только тогда, когда вы решите продать, обменять на другую крипту или потратить эти монеты. Вашей стоимостью приобретения (cost basis) будет цена BTC на момент покупки в 2014 году. Вся остальная сумма прибыли при продаже будет облагаться по долгосрочной ставке.
“Опенсорсить приложухи” и “показывать резюме” - это лишь верхушка айсберга. Современный софт почти никогда не пишется с нуля, он собирается из тысяч готовых библиотек и фреймворков. И подавляющее большинство этих инструментов живут, обновляются и развиваются именно на GitHub.
Даже если корпорация пишет свой закрытый код в приватном репозитории, она всё равно использует сотни опенсорсных пакетов. Когда в какой-нибудь популярной библиотеке находят критическую уязвимость, патч выходит на GitHub. Если мы оказываемся в “цифровом гетто”, процесс обновления и обеспечения безопасности превращается в ручной ад. Мы будем пользоваться устаревшими и дырявыми версиями инструментов, пока кто-то не решит переписать их с нуля внутри страны, что займет годы и потребует миллиардов.
Тут дело не в образовании или количестве населения (150 млн против 7 млрд), а в статистическом охвате и разности кейсов. Open Source ценен тем, что там работают лучшие специалисты со всего мира. Если в коде есть баг, который проявляется только на специфическом железе или в редких условиях, вероятность, что его найдет и исправит человек из другой страны, который уже столкнулся с этим, в разы выше, чем вероятность найти такого же узкого специалиста внутри одной страны. Это вопрос сетевого эффекта: безопасность и стабильность кода зависят от принципа “множества глаз”, которые его тестируют и критикуют. Без этого внешнего стресс-теста любая замкнутая система обречена на стагнацию.
Вы спрашиваете, как это повлияет на жизнь простого человека? Обычный пользователь не заметит исчезновения профиля какого-то разработчика. Но он заметит, что обновления ПО стали выходить реже, ошибки исправляются месяцами, а не часами, и новые сервисы становятся дороже. Почему дороже? Потому что компаниям придется тратить ресурсы не на развитие продукта, а на переписывание базовых инструментов, которые в остальном мире бесплатны и доступны. В итоге мы получаем более дорогие, менее стабильные и технологически отсталые продукты.
По поводу того, что 99% кода на GitHub “никому не нужен” - это опасное упрощение. Многие мировые стандарты начинались как “тулза на коленке” какого-то студента. Глобальная видимость позволяет такому проекту найти аудиторию и вырасти в индустриальный стандарт. Локальная платформа искусственно отсекает эту возможность. Мы просто потеряем те самые прорывные 10%, которые могли бы выстрелить только на глобальной арене.
Для бизнеса это вообще катастрофа с точки зрения репутации. Если компания делает Open-Source инструмент с платной Enterprise-версией, зарубежный заказчик или инвестор оценивает проект по количеству звезд и форков на мировых площадках. Это международный стандарт доверия. Переезд на локальный сервис делает “резюме” проекта нечитаемым для внешнего рынка.
Сравнение с Телеграмом тут не работает. Мессенджер - это инструмент для общения, его функция одна. А разработка ПО - это создание сложнейших продуктов силами сотен людей. Разорвать связь с глобальным потоком знаний и практик - это не импортозамещение, а добровольный отказ от эффективности. Нам нужны свои инструменты, но не за счет отсечения от мирового стандарта.
Почта Яндекса это глобальный сервис, он не замкнут внутри России. Есть даже yandex.com домен. Жители других стран там давно регистрируют себе аккаунты. Тарифы по Яндекс Диску кто-то считает выгодными.
Разработчикам уже советуют переносить проекты на другие Git-сервисы, включая российские аналоги.
Важно понимать, что прямых аналогов GitHub в России не существует. GitFlic, GitVerse и другие сервисы являются аналогами по функционалу (хранение кода, CI/CD), но не по сути. GitHub - это глобальная экосистема, социальная сеть и “цифровое резюме”, которое по умолчанию признают во всем мире. Аналогом GitHub может быть только такая же международная платформа, где сотрудничают миллионы людей со всего мира.
Весь смысл современной разработки - в Open Source и глобальном взаимодействии. Запираться в “национальных сервисах” - значит добровольно уйти в цифровую изоляцию и деградировать. Это не импортозамещение, а выстрел себе в ногу.
Хуже, потому что готовый бинарник можно изолировать перед запуском и посмотреть, что он делает. А wget something | bash предлагает шагнуть в пропасть неизведанного - и будь что будет. К примеру, может скачаться эксплойт, который затроянит ваш роутер, добавит его в ботнет и будет рассылать спам.
Использование национальных языков для подобных целей - это экзотика. А вот поддержка строк перевода в зависимости от значения глобальных переменных и подгрузка их из внешнего файла - здравая идея. Покажите мне программиста, которому привычнее писать системные сообщения, тексты ошибок и комментарии в коде не на английском. Вы не найдёте такого. И это касается не только России: во всем мире обычно пишут на английском. Те, кто хочет видеть перевод, всегда могут перевести самостоятельно.
В UNIX-like совместимых окружениях для таких целей принято использовать переменную LANG. Выставляете:
export LANG=ru_RU.UTF-8
После запуска программы она будет выводить сообщения на русском языке, если, конечно, автор предусмотрел такую возможность.
PS: Если бы компьютерная отрасль в СНГ не пришла в упадок после распада СССР или если бы страна не развалилась, сейчас бы во всем мире писали комментарии и сообщения программ одновременно и на русском, и на английском. Даже китайские программисты. Но история сложилась иначе, и теперь все используют английский язык.
Тот факт, что риск можно купировать с помощью песочницы, не делает сам метод доставки кода безопасным по определению.
Главный риск здесь даже не в отсутствии песочницы, а в отсутствии неизменяемого артефакта. При скачивании бинарника у меня есть файл > хеш > возможность аудита. При
pipe в bashя исполняю то, что сервер решил прислать мне именно в эту миллисекунду. Даже если я запущу это в контейнере, я все равно исполняю “черный ящик”, который может вести себя по-разному при каждом перезапуске. подробнее уже писал ниже, чтобы я не повторялся, можете прочитатьОни сначала не спрашивают, но обычно предупреждают: имейте в виду, что если вы продолжите пополнять счёт, банк может запросить подтверждение источника дохода. У меня так было. Я ответил: “Без проблем, запрашивайте”. Но до этого не дошло.
Вы смешиваете психологию пользователя и техническую безопасность метода. По логике “всё равно никто не проверяет”, можно вообще перестать подписывать пакеты цифровой подписью или перестать использовать HTTPS, ведь обычный пользователь не проверяет цепочки сертификатов в браузере.
При make install или запуске локального файла пользователь запускает статичный объект. Если завтра этот софт признают вредоносным, у пользователя остался артефакт (файл), который можно отправить в вирусный анализ или сравнить с версией из репозитория.
pipe в bash - это запуск динамического потока. Сервер может отдавать разный код в зависимости от вашего IP, User-Agent или времени суток. Это позволяет реализовать таргетную атаку: 99% пользователей получат чистый установщик, а один конкретный администратор с определенным IP - бэкдор. В этом случае никакой “цифровой гигиены” не поможет, потому что код, который был исполнен, никогда не существовал в публичном репозитории и не сохранился на диске.
Аргумент “пользователи всё равно не проверяют” в безопасности не работает. Это как сказать, что подушки безопасности в авто бесполезны, потому что большинство водителей не читают инструкцию к ним. Инструмент должен быть безопасен по определению, а не полагаться на внезапную бдительность юзера.
Что касается контейнеризации - это не “мода”, а банальный принцип изоляции. Если однокнопочный скрипт окажется вредоносным и попытается снести систему через
rm -rf /или переписать/etc/shadow, контейнер ограничит его влияние только своей средой, а запуск напрямую в ОС - нет. Удобство установки не должно идти в ущерб базовой безопасности системы.Проблема “pipe в bash” не в том, что это “сложнее”, а в том, что это исключает возможность аудита кода перед запуском. Это, фактически, передача управления удаленному серверу в реальном времени. Сервер может отдать разный код в зависимости от вашего IP, User-Agent или времени суток. Это “черный ящик”, где между скачиванием и исполнением нет ни одной точки контроля.
С make install всё иначе: код локален. Можно проверить хеши скачанных файлов, открыть Makefile в текстовом редакторе перед запуском.
Что касается контейнеров, это не про “моду”, а про изоляцию. Чтобы какая-нибудь зависимость из сомнительного скрипта не затерла системные конфиги или не притащила в систему мусор, который потом придется вычищать вручную. Это вопрос гигиены системы, а не “девопсовства”.
Это может быть нормальным для Quick Start в тестовой среде, чтобы быстро проверить “взлетит или нет”. Но важно разделять PoC и полноценную установку. Для основной системы или продакшена пайп в bash - это недопустимый риск. Инструмент, который должен работать долго и надежно, ставится через репозиторий или пакеты, а не через слепой запуск скрипта из сети. Если пакетов нет, любую программу можно опакетить самому или контейнеризировать.
Это вопрос доверия к софту, которым вы пользуетесь. Если вы ему не доверяете, используйте песочницу. Сегодня хорошей практикой является запуск сервисов в контейнерах. А для пущей изоляции - чтобы процессы в контейнере не могли использовать zero-day эксплойты ядра - можно использовать gVisor.
и FSearch, если Linux
Да, причём даже несмотря на то, что в компаниях часто используют свои локальные зеркала для этих пакетов. Компании нужно постоянно держать эти зеркала обновлёнными, либо обеспечивать им постоянный доступ к GitHub и другим официальным репозиториям пакетов для зеркалирования в реальном времени.
Вот что Google на эту тему пишет:
В США это обычная ежегодная процедура. Просто укажет, как есть.
“Опенсорсить приложухи” и “показывать резюме” - это лишь верхушка айсберга. Современный софт почти никогда не пишется с нуля, он собирается из тысяч готовых библиотек и фреймворков. И подавляющее большинство этих инструментов живут, обновляются и развиваются именно на GitHub.
Даже если корпорация пишет свой закрытый код в приватном репозитории, она всё равно использует сотни опенсорсных пакетов. Когда в какой-нибудь популярной библиотеке находят критическую уязвимость, патч выходит на GitHub. Если мы оказываемся в “цифровом гетто”, процесс обновления и обеспечения безопасности превращается в ручной ад. Мы будем пользоваться устаревшими и дырявыми версиями инструментов, пока кто-то не решит переписать их с нуля внутри страны, что займет годы и потребует миллиардов.
Тут дело не в образовании или количестве населения (150 млн против 7 млрд), а в статистическом охвате и разности кейсов. Open Source ценен тем, что там работают лучшие специалисты со всего мира. Если в коде есть баг, который проявляется только на специфическом железе или в редких условиях, вероятность, что его найдет и исправит человек из другой страны, который уже столкнулся с этим, в разы выше, чем вероятность найти такого же узкого специалиста внутри одной страны. Это вопрос сетевого эффекта: безопасность и стабильность кода зависят от принципа “множества глаз”, которые его тестируют и критикуют. Без этого внешнего стресс-теста любая замкнутая система обречена на стагнацию.
Вы спрашиваете, как это повлияет на жизнь простого человека? Обычный пользователь не заметит исчезновения профиля какого-то разработчика. Но он заметит, что обновления ПО стали выходить реже, ошибки исправляются месяцами, а не часами, и новые сервисы становятся дороже. Почему дороже? Потому что компаниям придется тратить ресурсы не на развитие продукта, а на переписывание базовых инструментов, которые в остальном мире бесплатны и доступны. В итоге мы получаем более дорогие, менее стабильные и технологически отсталые продукты.
По поводу того, что 99% кода на GitHub “никому не нужен” - это опасное упрощение. Многие мировые стандарты начинались как “тулза на коленке” какого-то студента. Глобальная видимость позволяет такому проекту найти аудиторию и вырасти в индустриальный стандарт. Локальная платформа искусственно отсекает эту возможность. Мы просто потеряем те самые прорывные 10%, которые могли бы выстрелить только на глобальной арене.
Для бизнеса это вообще катастрофа с точки зрения репутации. Если компания делает Open-Source инструмент с платной Enterprise-версией, зарубежный заказчик или инвестор оценивает проект по количеству звезд и форков на мировых площадках. Это международный стандарт доверия. Переезд на локальный сервис делает “резюме” проекта нечитаемым для внешнего рынка.
Сравнение с Телеграмом тут не работает. Мессенджер - это инструмент для общения, его функция одна. А разработка ПО - это создание сложнейших продуктов силами сотен людей. Разорвать связь с глобальным потоком знаний и практик - это не импортозамещение, а добровольный отказ от эффективности. Нам нужны свои инструменты, но не за счет отсечения от мирового стандарта.
Почта Яндекса это глобальный сервис, он не замкнут внутри России. Есть даже yandex.com домен. Жители других стран там давно регистрируют себе аккаунты. Тарифы по Яндекс Диску кто-то считает выгодными.
Если оплачивать криптовалютой, скорее всего, можно будет обойти ограничения через VPN.
А для последующего использования API VPN уже не потребуется: они пока не блокируют API для России, в отличие от Anthropic, Google и OpenAI.
В большинстве проектов есть README_EN.md
Очередное: “Нам не нужОн интернет ваш!”
Ощущение, что эта бабка из мема там где-то сидит и просто давит на кнопку с запретами.
Важно понимать, что прямых аналогов GitHub в России не существует. GitFlic, GitVerse и другие сервисы являются аналогами по функционалу (хранение кода, CI/CD), но не по сути. GitHub - это глобальная экосистема, социальная сеть и “цифровое резюме”, которое по умолчанию признают во всем мире. Аналогом GitHub может быть только такая же международная платформа, где сотрудничают миллионы людей со всего мира.
Весь смысл современной разработки - в Open Source и глобальном взаимодействии. Запираться в “национальных сервисах” - значит добровольно уйти в цифровую изоляцию и деградировать. Это не импортозамещение, а выстрел себе в ногу.
Хуже, потому что готовый бинарник можно изолировать перед запуском и посмотреть, что он делает. А
wget something | bashпредлагает шагнуть в пропасть неизведанного - и будь что будет. К примеру, может скачаться эксплойт, который затроянит ваш роутер, добавит его в ботнет и будет рассылать спам.А бан ведь можно как-то обойти? Они же не будут читать ваш код и делать выводы о том, что вы из России, исходя из ваших проектов?
Использование национальных языков для подобных целей - это экзотика. А вот поддержка строк перевода в зависимости от значения глобальных переменных и подгрузка их из внешнего файла - здравая идея. Покажите мне программиста, которому привычнее писать системные сообщения, тексты ошибок и комментарии в коде не на английском. Вы не найдёте такого. И это касается не только России: во всем мире обычно пишут на английском. Те, кто хочет видеть перевод, всегда могут перевести самостоятельно.
В UNIX-like совместимых окружениях для таких целей принято использовать переменную LANG. Выставляете:
После запуска программы она будет выводить сообщения на русском языке, если, конечно, автор предусмотрел такую возможность.
PS: Если бы компьютерная отрасль в СНГ не пришла в упадок после распада СССР или если бы страна не развалилась, сейчас бы во всем мире писали комментарии и сообщения программ одновременно и на русском, и на английском. Даже китайские программисты. Но история сложилась иначе, и теперь все используют английский язык.
Судя по действиям, только “пятая колонна” способна на такое.
На самом деле, это мечта врагов России - чтобы Россия сама вводила против себя санкции.