Администраторы репозитория NPM по ошибке заблокировали пакет Stylus, распознав в нём несуществующее вредоносное ПО. Через 12 часов после отправки жалобы в NPM проблема была отмечена как не соответствующая действительности, объявление о наличии вредоносного ПО было отозвано, а пакет восстановлен в репозитории...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63635
> Мотивы действий разработчика "panya" не ясны, предполагается, что он мог проводить исследования, связанные с безопасностью."мотивы ограбления не ясны. предположительно, грабитель проводил исследования, связанные с деньгами."
1. Об исследованиях надо предупреждать
2. Учетку могли угнать и автор её давно забросил
3. блокировать другой проект. к которому он причастен, с учётом контроля Других участников, и без аудита этого пакета, который блокируют автоматически - не логично. Или авторы систему советов и администрация не верит миллиону глаз, в любви к которым признается в каждом письме?
Товарищи аминистраторы репозитория NPM, произошла чудовищная ошибка!
> Товарищи аминистраторы репозитория NPM, произошла чудовищная ошибка!Сопровождающий зарегистрировался на почтовом домене inbox.ru?
Хуже "mail.su"
Как от этого спасаться? package-lock.json?
Если у вас что-то важное, то поднимите свое зеркало пакетов, которые используются в вашем проекте. На зеркале включите сканеры безопасности. Создайте регламенты обновления, следите за изменениями и контролируйте каждую модификацию в package-lock.json. Это будет дорого. Поэтому если ни чего важного нет, то просто расслабьтесь.
Deno позволяет точечно регулировать праваРазрешить дёргать лишь определённые команды/пускать только в определённые директории на диске/подключаться к заданному списку доменных имён
А еще что?
Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция -- это либо линукс-неймспейсы, либо виртуалка.
> Это на уровне юзерленда ограничения, которые очень легко обойти. Настоящая изоляция --
> это либо линукс-неймспейсы, либо виртуалка.Ты их никак не обойдёшь, эти ограничения там стоят поверх всего уровня общения интерпрататора JS с системой
Неймспейсы и виртуалки это хорошо, но как они защитят тебя от майнера/слива данных из той бд/фс куда процессу нужно ходить, туда куда его хождение не было предусмотрено (сервер злоумышленника)?
Вот тут как раз только точечные ограничения помогут, будь то opensnitch или вот, ограничения Deno.
> поверх всего уровня общения интерпрататора JS с системойЧувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом spawn("curl"), или что там у вас в дено. А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой. Всегда всё можно обойти, вопрос лишь -- насколько целенаправленно искать. Дено -- это вообще не продакшн-ready история, я вообще вначале думал, что его пишет подросток, а там оказывается аффтар нодежс так и не вырос из штанишек.
>> поверх всего уровня общения интерпрататора JS с системой
> Чувак. Если есть возможность вызова подпроцессов, то сетевые ограничения обходятся вызовом
> spawn("curl")...При условии что ты явно разрешишь запускать curl
> А если в дено бывают нативные модули (аналог .node-модулей), то движок JS будет не единственным, кто общается с системой
Есть и .node модули, и dlopen/dlsym, и собственные нативные модули. Для всех есть whitelistы
> Дено -- это вообще не продакшн-ready история
Гоняю deno в продакшене, он обслуживает сотни людей, и я не один такой.
Правда не в исходном виде, а подключаю его как библиотеку, deno_coreЭто в целом намного более грамотно реализованная обёртка над v8 чем node.js, особенно если говорить о поддержке стандартов (В deno предпочтительным является использование web стандартов, а не node.js стандартной библиотеки, которая много где очень криво устроена)
> node.js стандартной библиотеки, которая много где очень криво устроенаВ Node.js можно передавать буфер в качестве имени файла. В дено считается, что имя файла -- это либо UTF-8-строка, либо URL, конвертирующийся в UTF-8-строку. Про то, что имя файла может содержать невалидные UTF-8-последовательности, аффтар дено не слышал. А в ноде -- слышали. Как итог, если ты хочешь получить список файлов в папке, нода вернет список целиком, а дено вернет только те файлы, у которых имена -- UTF-8-валидные. Этого достаточно, чтобы заявить, что дено -- это лишь игрушка в компьютерном классе средней образовательной школы.
> В дено считается,
> что имя файла -- это либо 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 развивается и улучшается).
> Я бы не сказал что это недостаток, у deno просто несколько иные
> цели.Ну и к слову, эти ограничения не в Deno придумали
Есть https://wintertc.org/, который занимается обсуждением того как должно выглядеть апи в JS рантаймах cloudflare workers, в браузерах, deno, и в целом кроссплатформенном жс, и у них по интерфейсам подразумевается что путь - URLNode.js туда тоже входит, и когда в общем стандарте будет добавлено для файлов что-либо кроме https://w3c.github.io/FileAPI/, то в nodejs эти апи тоже не будут работать с не-utf8 путями.
BTW, просто интересно, как часто и где ты сталкиваешься с именами файлов что не utf-8 совместимые, и при этом с ними надо работать из JS?
Звучит как очень странный кейс для не системного ЯП
> как часто и где ты сталкиваешься с именами файлов что не 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.
> 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 сэкономил кучу стрельбы себе в ноги, и с его стороны представление ФС вполне себе консистентное - он не видит ровно те файлы, которые через своё апи не позволяет создать
> апи там соответствует спеке 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).
> Если прога исполняется не внутри песочницы браузера, вебапи тупо неприменимЧто это млять значит?)
Что мешает 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 и нативной кодировкой системы, которую клиенты не знают
> Что мешает 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-имен. Платформа от непрофессионалов для непрофессионалов.
А сейчас идет твой коммент, в котором ты снова будешь мне приводить массу Сатурна, внутреннее устройство фетча и прочие вещи, которые меня не интересуют, никак меня не опровергают и отношения к диалогу не имеют. Итак, читаем твой невтемный коммент:
Тебе же сказали про поддержку node.js api, что ты ещё хочешь?
Где он там поддерживается? Дено НЕ поддерживает апи ноды в полной мере, а его документация врет:> If the encoding is set to 'buffer', the filenames returned will be passed as Buffer objects. -- https://docs.deno.com/api/node/fs/~/readdirSync
Пробуем:
$ touch $'\x80'
$ ls
''$'\200' hello.cjs$ cat hello.cjs
const fs = require("node:fs");
console.log(Array.from(Deno.readDirSync(".")));
console.log(fs.readdirSync(".", { encoding: "buffer" }));$ deno --allow-read hello.cjs
[
[Object: null prototype] {
name: "hello.cjs",
isFile: true,
isDirectory: false,
isSymlink: false
}
]
error: Uncaught (in promise) Error: TypeError [ERR_INVALID_OPT_VALUE_ENCODING]: The value "buffer" is invalid for option "encoding"Я же говорю -- immature язык, который врет разрабу не только о том, что есть в папке, но и в документации, не реализуя то, что обещал. Это по определению not production ready.
Удивительное королевство. Не вредоносные банить, вредоносные не банить.
Мы словили эту проблему через зависимости nx.Добавили оверайд в package.json на гитхаб.
Держу в курсе.
> привело к массовыми сбоям в сборочных системахтренировка прошла успешно
Апокалипсис продемонстрирован. ))
Может это сопровождающие солидарно демонстрируют свою власть в ответ на скрип с 10$ им за сопровождение в соответствие с инициативой Maintenance Fee? ))
После NPM в новости или как там его ещё этого, у питона, сразу понятно, что произошла какая-то феерическая фигня. Судьба у этих репозитариев такая.
Durilka? Как это может быть вредоносным пакетом?
Ну уж лучше так, чем если бы там на самом деле вредонос был и его бы не сразу удалили.
Какой-то васянство... Никто не будет качать себе с репозиториев, поэтому что там сомнительные личности выкладывает сомнительный софт.
А собирать это уже красноглазие и пердолинг с консолью в обнимку с бубеном.
Вот по этому и 4 процента дисктопа у Линукс.
Т.е. заблокировать автоматом пакет, у которого один из мантейнеров публикует вредоносные пакеты - это ошибка?