Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"NPM-пакет Stylus был по ошибке заблокирован из-за подозрений в наличии вредоносного кода"	+/–
Сообщение от opennews (?), 27-Июл-25, 10:27
Администраторы репозитория NPM по ошибке заблокировали пакет Stylus, распознав в нём несуществующее вредоносное ПО. Через 12 часов после отправки жалобы в NPM проблема была отмечена как не соответствующая действительности, объявление о наличии вредоносного ПО было отозвано, а пакет восстановлен в репозитории... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63635
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

3. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+9 +/–
Сообщение от Аноним (3), 27-Июл-25, 11:54
> Мотивы действий разработчика "panya" не ясны, предполагается, что он мог проводить исследования, связанные с безопасностью. "мотивы ограбления не ясны. предположительно, грабитель проводил исследования, связанные с деньгами."
Ответить | Правка | Наверх | Cообщить модератору

	19. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+2 +/–
	Сообщение от Аноним (19), 27-Июл-25, 14:05
	1. Об исследованиях надо предупреждать 2. Учетку могли угнать и автор её давно забросил 3. блокировать другой проект. к которому он причастен, с учётом контроля Других участников, и без аудита этого пакета, который блокируют автоматически - не логично. Или авторы систему советов и администрация не верит миллиону глаз, в любви к которым признается в каждом письме?
	Ответить | Правка | Наверх | Cообщить модератору

4. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	–1 +/–
Сообщение от 1 (??), 27-Июл-25, 12:03
Товарищи аминистраторы репозитория NPM, произошла чудовищная ошибка!
Ответить | Правка | Наверх | Cообщить модератору

	45. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (45), 28-Июл-25, 09:23
	> Товарищи аминистраторы репозитория NPM, произошла чудовищная ошибка! Сопровождающий зарегистрировался на почтовом домене inbox.ru?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+1 +/–
	Сообщение от голос_из_леса (ok), 29-Июл-25, 00:17
	Хуже "mail.su"
	Ответить | Правка | Наверх | Cообщить модератору

5. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
Сообщение от Аноним (5), 27-Июл-25, 12:17
Как от этого спасаться? package-lock.json?
Ответить | Правка | Наверх | Cообщить модератору

	8. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+2 +/–
	Сообщение от 1 (??), 27-Июл-25, 12:34
	Если у вас что-то важное, то поднимите свое зеркало пакетов, которые используются в вашем проекте. На зеркале включите сканеры безопасности. Создайте регламенты обновления, следите за изменениями и контролируйте каждую модификацию в package-lock.json. Это будет дорого. Поэтому если ни чего важного нет, то просто расслабьтесь.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от morphe (?), 27-Июл-25, 17:28
	Deno позволяет точечно регулировать права Разрешить дёргать лишь определённые команды/пускать только в определённые директории на диске/подключаться к заданному списку доменных имён
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	40. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (40), 28-Июл-25, 03:54
	А еще что?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 28-Июл-25, 07:07
	Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция -- это либо линукс-неймспейсы, либо виртуалка.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	55. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от morphe (?), 28-Июл-25, 15:31
	> Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция -- > это либо линукс-неймспейсы, либо виртуалка. Ты их никак не обойдёшь, эти ограничения там стоят поверх всего уровня общения интерпрататора JS с системой Неймспейсы и виртуалки это хорошо, но как они защитят тебя от майнера/слива данных из той бд/фс куда процессу нужно ходить, туда куда его хождение не было предусмотрено (сервер злоумышленника)? Вот тут как раз только точечные ограничения помогут, будь то opensnitch или вот, ограничения Deno.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 28-Июл-25, 21:09
	> поверх всего уровня общения интерпрататора JS с системой Чувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом spawn("curl"), или что там у вас в дено. А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой. Всегда всё можно обойти, вопрос лишь -- насколько целенаправленно искать. Дено -- это вообще не продакшн-ready история, я вообще вначале думал, что его пишет подросток, а там оказывается аффтар нодежс так и не вырос из штанишек.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+1 +/–
	Сообщение от morphe (?), 28-Июл-25, 22:15
	>> поверх всего уровня общения интерпрататора JS с системой > Чувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом > spawn("curl") ...При условии что ты явно разрешишь запускать curl > А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой Есть и .node модули, и dlopen/dlsym, и собственные нативные модули. Для всех есть whitelistы > Дено -- это вообще не продакшн-ready история Гоняю deno в продакшене, он обслуживает сотни людей, и я не один такой. Правда не в исходном виде, а подключаю его как библиотеку, deno_core Это в целом намного более грамотно реализованная обёртка над v8 чем node.js, особенно если говорить о поддержке стандартов (В deno предпочтительным является использование web стандартов, а не node.js стандартной библиотеки, которая много где очень криво устроена)
	Ответить | Правка | Наверх | Cообщить модератору

	58. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 28-Июл-25, 22:53
	> node.js стандартной библиотеки, которая много где очень криво устроена В Node.js можно передавать буфер в качестве имени файла. В дено считается, что имя файла -- это либо UTF-8-строка, либо URL, конвертирующийся в UTF-8-строку. Про то, что имя файла может содержать невалидные UTF-8-последовательности, аффтар дено не слышал. А в ноде -- слышали. Как итог, если ты хочешь получить список файлов в папке, нода вернет список целиком, а дено вернет только те файлы, у которых имена -- UTF-8-валидные. Этого достаточно, чтобы заявить, что дено -- это лишь игрушка в компьютерном классе средней образовательной школы.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	–1 +/–
	Сообщение от morphe (?), 29-Июл-25, 03:04
	> В дено считается, > что имя файла -- это либо UTF-8-строка, либо URL, конвертирующийся в > UTF-8-строку. Да, это так. Как я и сказал, в deno ориентируются на web api при проентировании своих интерфейсов, а потому названия файлов должны быть валидными URL Я бы не сказал что это недостаток, у deno просто несколько иные цели. В Deno ты например можешь аналогично браузеру читать файлы в одной директории со скриптом через await fetch(new URL('file.txt', import.meta.url)). Так нельзя было бы поступать, если бы deno считал за валидные имена файлов что-то не URL-совместимое Было бы хуже если бы его апи поддерживали одновременно URL и Buffer TBH, потому что в этом случае потребовалось бы вводить непонятно работающие конверсии между этим всем. Однако deno также поддерживает node.js api, и через node.js api Buffer принимается, и невалидный utf8 обрабатывается аналогично ноде (т.е можно передать encoding функциям производящим пути. Deno однако я так понял только binary и utf-8 тут поддерживает, но если кому надо чот большее - поддержка nodejs api в Deno развивается и улучшается).
	Ответить | Правка | Наверх | Cообщить модератору

	62. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от morphe (?), 29-Июл-25, 05:05
	> Я бы не сказал что это недостаток, у deno просто несколько иные > цели. Ну и к слову, эти ограничения не в Deno придумали Есть https://wintertc.org/, который занимается обсуждением того как должно выглядеть апи в JS рантаймах cloudflare workers, в браузерах, deno, и в целом кроссплатформенном жс, и у них по интерфейсам подразумевается что путь - URL Node.js туда тоже входит, и когда в общем стандарте будет добавлено для файлов что-либо кроме https://w3c.github.io/FileAPI/, то в nodejs эти апи тоже не будут работать с не-utf8 путями.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от morphe (?), 29-Июл-25, 03:10
	BTW, просто интересно, как часто и где ты сталкиваешься с именами файлов что не utf-8 совместимые, и при этом с ними надо работать из JS? Звучит как очень странный кейс для не системного ЯП
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	63. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 29-Июл-25, 07:59
	> как часто и где ты сталкиваешься с именами файлов что не utf-8 совместимые Речь не о том, как часто. Речь о том, что стандартная библиотека языка врет. В папке может оказаться сто файлов, а стд библиотека скажет, что файлов там нет. Любой язык, системный или нет, должен давать возможность работать с реальным миром в полной мере. Питон такую возможность дает. Нода -- дает. А дено решил попробовать натянуть сову на глобус со своей концепцией "все есть урл". А это значит, что есть как минимум одно приложение, которое на дено ты написать не сможешь никогда: файловый менеджер вроде ls, exa, nnn, mc, ranger, да даже веб-сервис типа cockpit, в котором есть веб-версия файлового менеджера. Это разве "системные утилиты"? Нет, не системные, вполне юзерленд, вполне высокоуровневые. А на дено их принципиально не реализовать, потому что стд библиотека врет. > Было бы хуже если бы его апи поддерживали одновременно URL и Buffer TBH, потому что в этом случае потребовалось бы вводить непонятно работающие конверсии между этим всем Я тебе даже больше скажу: console.log(filenameAsString) может тебе испортить консоль UTF-8-корректными ANSI-последовательностями. Следовательно, у тебя уже как минимум должны быть две строки: реальное имя файла и имя файла, где ANSI-последовательности заэкранированы. Следовательно, как минимум одна конверсия должна быть. А там, где есть одна конверсия, будет и другая: try to convert to utf-8. В нормальных языках это понимают. В дено -- нет. tldr: дено плох, потому что его стд библиотека допустила ошибки в самом апи. Имя файла -- это не строка, а буфер. Источник -- сходи в вики, Comparison of file systems.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	–1 +/–
	Сообщение от morphe (?), 29-Июл-25, 16:52
	> tldr: дено плох, потому что его стд библиотека допустила ошибки в самом апи. Имя файла -- это не строка, а буфер. Источник -- сходи в вики, Comparison of file systems. Опять же, апи там соответствует спеке wintertc/webapi, там имя файла - url Надо большее - node.js api в дено реализованы, можешь использовать их > Следовательно, как минимум одна конверсия должна быть. А там, где есть одна конверсия, будет и другая: try to convert to utf-8. В нормальных языках это понимают Как раз таки конверсия в utf8 обычных путей это неверно, и в нормальных языках (Rust) это понимают, и для путей заводят отдельный тип - Path, который и не строка, и не массив байт В golang притворяются что путь это строка, и получают не-utf8 строку, с которой стандартная библиотека зачастую плохо работает и ломает, потому что строки в golang это конечно массивы байт, однако много апи ожидают что они utf-8 Опять же nodejs по дефолту тебе тоже ломает пути, потому что для правильного перечисления файлов в директории например нужно передавать {encoding: "binary"} Питон действительно пытается распарсить путь как utf8, и если не получается - возвращает байтовую строку... А теперь вопрос - как много приложений это обрабатывают и не падают? Кроме того это ещё не идёт речи про не-utf8 системные кодировки, где у тебя конверсия в utf8 будет lossy, и при roundtrip у тебя может получиться не исходный путь (e.g utf16 в винде) Винда в этом плане ещё смешнее, потому что в зависимости от системной кодировки, ты через posix api не ко всем файлам можешь обращаться, надо либо конвертировать нормальный путь в short string "file-с-русскими-буквами-в-имени" => "FILE~1", либо использовать wstr варианты всех апи, которые явно принимают utf-16 Perl там тоже может не работать по той же причине, надо использовать Win32::Unicode::Dir->new И таких приколов тут миллиард В этом плане deno сэкономил кучу стрельбы себе в ноги, и с его стороны представление ФС вполне себе консистентное - он не видит ровно те файлы, которые через своё апи не позволяет создать
	Ответить | Правка | Наверх | Cообщить модератору

	65. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 29-Июл-25, 17:43
	> апи там соответствует спеке wintertc/webapi Если прога исполняется не внутри песочницы браузера, вебапи тупо неприменим. Это и есть то самое натягивание совы на глобус. Со своим уставом в чужую церковь, как говорится. У тебя есть файловая система, и есть дено, которая с этой файловой системой работать _не умеет_. Ну и нахрена такая дено? > для путей заводят отдельный тип - Path Снова неверно. Path -- это просто обертка над массивом байт, предоставляющая более-менее удобный апи для работы с путями. А внутри все тот же массив байт. > nodejs по дефолту тебе тоже ломает пути Сделано видимо для совместимости с совсем уж древней нодой, в которой аффтар дено допустил ровно ту же ошибку. Потом за аффтаром прибирались, добавив binary. Н - Необучаемость. > теперь вопрос - как много приложений это обрабатывают и не падают? Чувак, указывай тип данных явно -- и будут приходить тебе значения одного типа. Где здесь можно запутаться? > Кроме того это ещё не идёт речи про не-utf8 системные кодировки, где у тебя конверсия в utf8 будет lossy, и при roundtrip у тебя может получиться не исходный путь (e.g utf16 в винде) Следовательно надо пользоваться исходными данными, а не конвертировать их туда-сюда. Получил от ядра список файлов -- все, считай это черным ящиком. Хочешь вывести их пользователю -- попытайся конвертить в строку, но будь готов к тому, что это будет невалидная строка. В GLib совсем уж шикарное апи: они различают name, display name, edit name и copy name. Название, которое годится для вывода в UI, может содержать в скобках " (неверная кодировка)" в конце имени. Именно это значение ты увидишь в гуе наутилуса. В дено тем временем делают вид, что кодировка всегда верна. > он не видит ровно те файлы, которые через своё апи не позволяет создать Таким образом ты признаешь, что аффтар дено -- непрофессионал, поскольку профессиональный разраб всегда думает над edge cases. Как ребенку объясняю, ей богу. Если твоя платформа не позволяет создать файл -- то твоя платформа фуфло, и для прода не годится. Если я не могу пролистать список файлов с использованием дено, то такая дено отправляется в shred(1).
	Ответить | Правка | Наверх | Cообщить модератору

	66. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от morphe (?), 29-Июл-25, 19:09
	> Если прога исполняется не внутри песочницы браузера, вебапи тупо неприменим Что это млять значит?) Что мешает node.js реализовывать fetch, WebCache, WebSocket, DOM, OffScreenCanvas, и всё прочее? Ничего не мешает. Но он это не реализует, а потому приходится костылять обёртки которые будут работать и там, и там, но в браузерах через нативные апи, а в node.js подключать непонятные пакеты с реализацией тех же апи сомнительного качества После чего полученный код для браузеров компилировать возможно только через бандлеры https://docs.deno.com/runtime/reference/web_platform_apis/ > Снова неверно. Path -- это просто обертка над массивом байт, предоставляющая более-менее удобный апи для работы с путями. А внутри все тот же массив байт. Может ты всё же доку не читал?) Path - обёртка не над байтами, а над OsStr, и OsStr пускай в текущей реализации и является обёрткой над [u8], не имеет прямых конверсий туда-обратно, потому что это не просто массив байт, а массив байт который будет корректно конвертироваться в данные для системных вызовов, что в случае винды означает WTF-8 для конверсии в UTF-16/UCS-2. Его нельзя losslessly сконвертировать в массив байт и обратно, Rust не предоставляет такого API, только конвертацию в wide string: https://doc.rust-lang.org/std/ffi/struct.OsStr.html#impl-OsS... > Чувак, указывай тип данных явно -- и будут приходить тебе значения одного типа. Где здесь можно запутаться? > В дено тем временем делают вид, что кодировка всегда верна. Никто не делает этого вида, файлы с неверной кодировкой не выдаются через его API/wintercg. Опять же - если тебе эти файлы нужны, то есть поддержка node.js api По твоему универсальные апи должны принимать URL | ArrayBuffer | string в качестве путей? Ну вот приходи с этим предложением в WinterTC, с радостью тебя выслушаем > Если твоя платформа не позволяет создать файл Создавай любой файл, as long as name conforms to utf-8 > Следовательно надо пользоваться исходными данными, а не конвертировать их туда-сюда. Получил от ядра список файлов -- все, считай это черным ящиком. Хочешь вывести их пользователю -- попытайся конвертить в строку, но будь готов к тому, что это будет невалидная строка. Так ты про автоматические конверсии говоришь, а не ручные. Ручные это как раз Path из Rust Also назови мне хоть один web файловый менеджер что поддерживает произвольные пути файлов. Самый распространённый стандарт для такого - webdav, обычно не поддерживает такие названия, потому что с ними не способны работать большая часть клиентов, т.к надо выполнять конверсию между utf8 и нативной кодировкой системы, которую клиенты не знают
	Ответить | Правка | Наверх | Cообщить модератору

	67. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (41), 29-Июл-25, 19:38
	> Что мешает node.js реализовывать fetch, WebCache, WebSocket, DOM, OffScreenCanvas, и всё прочее? Не юли, речь шла про ФС-с-точки-зрения-вебапи. > Path - обёртка не над байтами, а над OsStr > OsStr пускай в текущей реализации и является обёрткой над [u8] Деталь реализации, не имеющая отношения к теме разговора. Сейчас ты пытаешься умничать, приводя мне какие-то сведения про Path, в то время как мне плевать, как он устроен. Все, что достаточно знать по теме -- это то, что взрослые языки и платформы вроде раста, питона и ноды (да, нода -- это взрослая платформа) --- все эти платформы считают первичным типом буфер, а не строку. > По твоему универсальные апи должны принимать URL | ArrayBuffer | string в качестве путей? Именно. > приходи с этим предложением в WinterTC, с радостью тебя выслушаем Зачем мне соваться в вебапи, который для браузеров? Проблема не в вебапи, а в том, что дено пытается реализовывать вебапи там, где никакого браузера нет. Дено работает не в браузере, а сразу на системе. При этом он ограничивает тебя своим браузер-онли апи, следовательно, является совой, натянутой на глобус. Следовательно, является игрушечным языком для средней школы. > Создавай любой файл, as long as name conforms to utf-8 Далеко не у всех ФС есть такое ограничение. Дено налагает на тебя ограничения там, где их нет. Следовательно... ну ты понел. Toy immature platform, not for production. > Так ты про автоматические конверсии говоришь, а не ручные Следи за руками, пример задачи, где конверсия не нужна вообще: для каждого файла в папке вызывать chmod. Зовем readdir, НЕ конвертируем имена (оставляем байтами) и в цикле вызываем chmod, передавая исходные буферы в качестве имени. В дено такое возможно? Нет, дено не в курсе про существование не-utf-имен. Платформа от непрофессионалов для непрофессионалов. А сейчас идет твой коммент, в котором ты снова будешь мне приводить массу Сатурна, внутреннее устройство фетча и прочие вещи, которые меня не интересуют, никак меня не опровергают и отношения к диалогу не имеют. Итак, читаем твой невтемный коммент:
	Ответить | Правка | Наверх | Cообщить модератору

	68. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от erphov (?), 29-Июл-25, 21:26
	Тебе же сказали про поддержку node.js api, что ты ещё хочешь?
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

7. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+3 +/–
Сообщение от Аноним (7), 27-Июл-25, 12:26
Удивительное королевство. Не вредоносные банить, вредоносные не банить.
Ответить | Правка | Наверх | Cообщить модератору

12. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+1 +/–
Сообщение от Аноним (-), 27-Июл-25, 13:20
Мы словили эту проблему через зависимости nx. Добавили оверайд в package.json на гитхаб. Держу в курсе.
Ответить | Правка | Наверх | Cообщить модератору

15. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
Сообщение от Аноним (15), 27-Июл-25, 13:56
> привело к массовыми сбоям в сборочных системах тренировка прошла успешно
Ответить | Правка | Наверх | Cообщить модератору

	20. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
	Сообщение от Аноним (19), 27-Июл-25, 14:09
	Апокалипсис продемонстрирован. ))
	Ответить | Правка | Наверх | Cообщить модератору

	21. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+1 +/–
	Сообщение от Аноним (19), 27-Июл-25, 14:18
	Может это сопровождающие солидарно демонстрируют свою власть в ответ на скрип с 10$ им за сопровождение в соответствие с инициативой Maintenance Fee? ))
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

26. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
Сообщение от Tron is Whistling (?), 27-Июл-25, 16:09
После NPM в новости или как там его ещё этого, у питона, сразу понятно, что произошла какая-то феерическая фигня. Судьба у этих репозитариев такая.
Ответить | Правка | Наверх | Cообщить модератору

31. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+3 +/–
Сообщение от Аноним (31), 27-Июл-25, 17:57
Durilka? Как это может быть вредоносным пакетом?
Ответить | Правка | Наверх | Cообщить модератору

33. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+2 +/–
Сообщение от Саркофандр (?), 27-Июл-25, 19:35
Ну уж лучше так, чем если бы там на самом деле вредонос был и его бы не сразу удалили.
Ответить | Правка | Наверх | Cообщить модератору

34. Скрыто модератором	–2 +/–
Сообщение от Аноним (34), 27-Июл-25, 20:12
Какой-то васянство... Никто не будет качать себе с репозиториев, поэтому что там сомнительные личности выкладывает сомнительный софт. А собирать это уже красноглазие и пердолинг с консолью в обнимку с бубеном. Вот по этому и 4 процента дисктопа у Линукс.
Ответить | Правка | Наверх | Cообщить модератору

49. "NPM-пакет Stylus был по ошибке заблокирован из-за подозрений..."	+/–
Сообщение от Аноним (49), 28-Июл-25, 10:53
Т.е. заблокировать автоматом пакет, у которого один из мантейнеров публикует вредоносные пакеты - это ошибка?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема