Удаленное выполнение произвольной команды в Emacs

Кстати говоря, (я не прочитал всю тему, возможно кто-то уже говорил, тогда сорри) у Emacs есть своя подобная фиговина, .dir-locals.el, и вот там он спрашивает можно ли доверять файлу.

Это все хорошо. Но неправильно перекладывать на прикладной софт заботу о безопасности базовых утилит.

Ну есть, а magit про нее знает?

Иные редакторы спрашивают, доверяешь ли ты содержимому папки

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

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

Можешь и в емаксе. Отключи автозапуск гит и смотри.

Это все хорошо. Но неправильно перекладывать на прикладной софт заботу о безопасности базовых утилит.

Каких нафик базовых утилит? Запуск git команд в каталоге — это не «базовая утилита».

Ну вот и емакс пропатчат, я надеюсь.

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

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

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

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

make ещё фиг бы с ним. Ты представь какая дыра любой shell.

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

shеll это не дыра - это набор щелей в интерфейсе

Да я согласен, что не дело редакторов следить за утилитами. Но от дурака защититься можно. Только уж больно много таких защит. Отвязывать надо конфигурационные каталоги от дерева исходников.

Нужно встроить в make надежную систему безопасности от неправомерного выполнения кода.

И еще подтверждение возраста не забудь.

Проблема тут действительно вообще не в емаксе. Многие пользуются всякими умными bashrc, которые в промте рисуют дополнительную информацию о каталоге, в котором ты сейчас находишься. В частности - опрашивают гит, если видят наличие ./.git.

Атакующий может распространять вредоносный архив с чем угодно. Ты его открываешь, делаешь туда cd - и всё, привет. Буквально включенный autorun.inf.

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

Мне это напоминает старую добрую виндовую удобнейшую фичу с автозапуском с флэшек когда то и чем это закончилось. Лет 20 назад еще. Не знаю, есть ли оно у них сейчас.

но что с этим делать не есть понятно

в MacOS проблему решили элементарнейшим образом.

The com.apple.quarantine extended attribute is a macOS security feature (Gatekeeper) that flags files downloaded from the internet or external sources. It triggers warnings and can block shell scripts or apps from running, often causing «permission denied» errors. Use xattr -d com.apple.quarantine <file> to remove it.

1. Downloaded Files: Any file downloaded via browsers, mail, or messenger apps is automatically tagged.
2. Unzipping: Files extracted from a ZIP archive often inherit the quarantine flag.
3. Security Check: The flag forces Gatekeeper to check the file’s signature, notarization, and run an XProtect scan upon first opening.

В Макос и Windows у гита встроенный файловый монитор, там этой проблемы просто не возникает.

Этак можно и tar пропатчить на тему не распаковывать из архива директорию .git. Чисто на всякий случай.

tar ничего не запускает на исполнение. Так что аналогия некорректна.

А кто знает, какая тулза из этой директории что-то на исполнение запустит? Я ж сказал, «на всякий случай», что бы даже попыток не было.

А кто знает, какая тулза из этой директории что-то на исполнение запустит?

Никакая тулза сама по себе не запустится и ничего не запустит. Её нужно руками запускать. Если команда ls dir вместо показа каталога будет запускать dir/.autorun, то это будет очень нехорошо. Потому что юзер не ожидает этого. Если он хочет запустить dir/.autorun, то он сделает это сам, и ответственность за последствия будет на нём. А если это сделает ls вместо показа каталога (или в дополнение к показу), то претензии будут к разработчикам ls. Ибо нефиг делать то, чего юзер на хотел.

Борода обрился??? Залягай меня кошка… Настали последние дни, истинно говорю вам.

См кммент от liksys выше.

Любая операционная система рано или поздно с этим сталкивается )))

А ещё не писали разве? Отстают!

У нас на работе народ произвел расследование на тему и кто же нам в гите такую подставу-то организовал. Ивот, та-да-дам!!!

commit 883e248b8a0fd88773cb902ab8e91273eb147d07
Author: Ben Peart <benpeart@microsoft.com>
Date:   Fri Sep 22 12:35:40 2017 -0400

Вот от них все зло и пошло!

Я провел дополнителные исследования.

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

Возможно, ребята, которые делают гит, не следят за новостями, с ним связанными. Или не считают уязвимостью. Ты не видел ответа гитовцев на эту тему?

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

ИИ ничего самостоятельно не нашел

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

Да с багрепортом я и сам могу починить %) Нафиг он мне нужен тогда.

Имха ии замечательный доубедитель _ закрепитель ибо оно реально эхочембирит напропалую

Рок

Причём здесь язык, если ошибка в логике работы. А если язык Си так не нравится и вокруг безграничное число уязвимостей - ну переходи на другую ОС, Linux тебе точно не годится, он процентов на 50-70 состоит Си кода (вместе с c++, уверен, что тебе и c++ кажется небезопасным), а ядро так и вообще процентов на 97.

Вообще фанатикам безопасности надо было бы смотреть в сторону Idris и DO-178, а не бытовых языков, которые пытаются себя выдавать за безопасные, даже не будем упоминать каких.

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

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

Проблема и там и там. В логике работы. Кто бы мог предположить, что git status, или там git log начнёт выполнять неизвестно что. Что же до emacs, то их позиция понятна, что правильно исправлять в git-е, но вообще по хорошему иногда можно идти на какой-то компромисс, что-то вроде сейчас отключим/введём предупреждение, а потом вернём как было, когда git исправят.

И вообще, какая в конце концов разница на каком языке ты пишешь, если всё равно пишешь код теперь уже не ты, а opus.