Комментарии 34
... злоумышленники получили доступ минимум к 3800 репозиториям.
к которым они не должны были иметь доступа?
Все произошло из-за зараженного расширения VS Code ...
А можно ли техническим языком описать суть вопроса? (Не раскрывая ничего лишнего.) Каким образом внутреннее устройство расширения влияет на получение доступа к репозиториям? Как, вообще, организована работа с репозиториями в разного рода IDE?
По дефолту все расширения в VS автоматически обновляются, даже 15 минут хватит в маркетплейсе повисеть новой версии чтобы у кого-то тригернуло обновление. Внедренный скрипт в расширение как правило крадет ключи\пароли ко всем возможным сервисам и отправляет их злоумышленнику, а те уже скачивают репы-шарятся по инфре и тянут все до чего могут дотянуться с украденными ключами.
А как это можно где-то просто таки прочитать ключи/пароли? откуда доступ?
Банально ssh приватные ключи на диске лежат обычно.
Ключи обычно складывают в переменные окружения для работы консольных утилит. Экстеншен просто делает process.env и забирает весь список
У меня на работе VS code, все авто апдейты отключены как для IDE, так и для плагинов. За 30 дней студия накачала примерно 500 мб. Откуда - хз
Что такое в наши дни каких-то жалких 500 Мб. Схему колорирования с сервера подгрузить в джейсончике.
У меня папка проекта хелло-ворлда на C++ сразу после генерации и сборки, то есть, где-то за 30 секунд, стала весить 3.4 Гб. Вот как у настоящих мастеров, в настоящей студии, а не в том любительском изделии, которое Code и которое каких-то 500 Мб тянуло из Интернета целых 30 дней.
(Если кто-то не понял, это был сарказм).
У меня папка проекта хелло-ворлда на C++ сразу после генерации и сборки, то есть, где-то за 30 секунд, стала весить 3.4 Гб.
это из-за новых модулей c++?
Откомпилировал под Debug и Release — 2 гига как с куста за счёт одних precompiled headers.
Вообще, это просто уже не C++. Там один голимый интероп и интеропом погоняет. И собирается он, кстати, не в .exe’шник. Собирается он в нечто под названием MSIX. Вся суть которого, как я понял, в том, чтобы вы свои приложения распространяли через WinStore и никак иначе. Можно (пока что) руками дописать флаг в XML проектного файла, чтобы снова получить запускаемый .exe'шник. Это называется “unpackaged application”. Размер бинарей, которые при этом генерируются рядом с .exe'шником (их надо распространять вместе с приложением) — около ста мегабайт. Из них одних только байндингов к ИИ — больше двух мегабайт. Это вот такие сейчас приложения официально рекомендуется делать под Windows.
И кстати, я когда смотрел на Files (про него в новостях тут часто пишут), знатно офигел оттого, какое же это всё тормозное гэ.
Я не спал неделю, искал способы сделать всё, нужное мне, включая Mica- и Acrylic-эффекты на настоящем C++ и WinAPI, и нашёл. Теперь чувствую себя как Алита. Утраченные технологии предков! Один .exe'шник без зависимостей размером 100 Кб!
(Я говорю про десктопные приложения. Разработка какого-нибудь бэкенда, возможно, выглядит иначе).
Теперь чувствую себя как Алита. Утраченные технологии предков! Один .exe'шник без зависимостей размером 100 Кб!
Как Вы это сделали?
Что именно? Акрилик/Мику на WinAPI?
ну то что в 100кб вышло?)))
Так обычное классическое приложение:
int APIENTRY wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow)
{
…
MyRegisterClass(hInstance);
if (!::InitInstance(hInstance, nCmdShow))
{
return FALSE;
}
MSG msg;
while (GetMessage(&msg, nullptr, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
…
return (int) msg.wParam;
}
Просто сейчас, наверно, мало кто захочет так программировать. В комментариях к статье У Microsoft не было целостной концепции GUI со времён Петцольда один человек написал, НЕУЖЕЛИ, мол, руками диспатчить сообщения?! Ну да, руками. Зато результат окупает себя в смысле размера.
Проблема была в том, как через WinAPI получить требуемые мне эффекты при отображении окон (в первую очередь — гауссово размытие фона). Как я написал в комментариях к той же статье, далеко не всё в современной винде можно сделать на WinAPI (спасибо Майкрософту). К тому же, вызов новых фич из WinAPI сейчас толком не документируют. Пишут на learn (бывший MSDN): просто используй MUC/WUC. Я посидел недельку и нашёл способ сделать на WinAPI акрил (любую из стандартных разновидностей, в том числе нужную мне сильно прозрачную) легально, без недокументированных функций. Но вот радиус для гауссова размытия так просто уже не поменять, там понадобится интероп. С другой стороны, если бы я посидел ещё недельку, может и радиус бы нашёл способ поменять. Скажем, покурить колстек с перехватчиком функций.
А самый простой способ добиться желаемого, где вообще не надо думать, это описать WinUI окно на XAML… И получится описанный выше проект на 3.4 ГБ на диске и 100 Мб бинарей после сборки (чтобы .exe’шник можно было запустить из Explorer’а).
Жестоко. Ненавижу современную отрасль.
Может упустил мысль, а всякие современные qt не дают сделать и чтобы было красиво (или как надо) и компактно?
Если в Qt нет кода по работе с DWM, Qt не даст вам сделать акрил. И насколько я знаю (я об этом только читал, но не проверял сам), Qt это действительно не умеет. В принципе, это логично. Это же кросс-платформенный фреймворк, он не обязан глубоко уметь в платформенно-зависимые тонкости. Тот фреймворк, который использую я, тоже не умеет. Его авторы написали байндинг к WinAPI (и другим ОС), но лучше бы ничего не писали, чем такой колхоз (я им не пользуюсь, написал свой).
Некоторые неочевидные моменты:
Вам не надо делать таким макаром (диспетчеризуя мессиджи) весь интерфейс. На WinAPI вы можете создать акриловое окно, а рисовать поверх него чем угодно. «Что угодно» должно уметь обрабатывать юзерский ввод и генерировать кадры в frame buffer. А вы их оттуда берёте и выводите поверх. Для этих целей можно и Qt использовать, наверно.
Qt не синоним компактности. Я смотрел более-менее универсальные приложения на его последних версиях, и он вытягивал на 50 метров оверхеда. Фреймворк, которым пользуюсь я, занимает всего 40 (и рассчитан на 60+ fps). Но он намного универсальнее, чем Qt (писать на нём гораздо приятнее, хоть там и нет готовых компонентов, зато запилить любой компонент — раз плюнуть). А если учесть, что Qt ударился в политику… Я считаю, он сильно переоценён.
P.S. А с описанным выше подходом Microsoft вам надо 100 мегабайт потратить только на акриловое окно, а потом ещё 50 мегабайт потратить на Qt. Вот в чём мысль ))
Об этом как раз моя вчерашняя статья, которая к сожалению до сих пор на модерации
Автообновления в корп сегменте вообще надо резать на корню... Ставить можно только проверенные версии с локального зеркала маркетплейса
Малварь просто собирает урожай из папки .aws, .ssh и конфигов гита. Получив эти ключи, хакер локально клонирует репы без всяких танцев с бубном
А, собственно, какого расширения-то?
Зараженного. Там же написано.
Тут есть предположение https://habr.com/ru/news/1037148/
важнее не то, чем заразился сотрудник, а какие репозитории скомпрометированы и каким образом. то есть о самом главном в новости ни слова.
Изоляция процессов в IDE давно напрашивается на жесткий рефакторинг. Плагины не должны иметь прямой доступ к файловой системе и переменным окружения без явного аппрува
Масштабный инцидент в GitHub: зараженное расширение VS Code привело к компрометации 3800 репозиториев