Удаленное выполнение произвольной команды в 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.

Magit это сторонний пакет. Пока ты сам себе его не поставишь, ты в безопасности ;-)

А можно в git запретить кастомные команды в .git? Мне кажется git status все кому не лень запускают, не только emacs.

Половина плагинов для PS1 делает так же.

Ну vc-git.el из коробки, по-моему. Magit — это от жира :)

уязвимость не в Emacs, а в git и исправлять это нужно именно в нём

Разработчики git считают это не уязвимостью, а фичей и исправлять ничего не планируют.

Поэтому это, таки, уязвимость в Emacs (и в любом другом софте, который дёргает git бездумно где попало) и исправлять её надо там. Ну или нигде не исправлять.

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

А как тогда? Пусть git чтоль спрашивает можно ли ему прочитать .git/config? Или в git добавить ключик –safe-mode-for-untrusted-dir-in-emacs чтобы он нужное читал из config, а не нужное не читал?

Да в том-то и дело, что непонятно как. Проблема, КМК, ровно в том, что если .git создается локально и под контролем пользователя, то таких проблем не возникает вовсе. Радикальным решением было бы отвязать .git от дерева исходников. Проблема бы решилась, если бы в условной директории ~/.local/git лежала бы иерархия служебных каталогов .git, соответствующая иерархии исходников. Или добавлять в обязательном порядке в .git какие-то метки, по которым можно однозначно установить, что каталог создан локально и по воле пользователя.

Проблема не только в емаксе. Какие-нибудь интеграционныне хуки или пре- и посткомитные хуки тоже опасны.

Ну хорошо, тот же VS-code спрашивает, а доверяете ли вы дереву исходников, в котором собираетесь открыть файл? И пользователь ничтоже сумняшеся радостно говорит — да, доверяю, сам же скачал! И случается то же самое. Ну не в курсе пользователь про такие неочевидные зависимости.

А чё, лмож кто поделится инфой с братбнями, зачем нужен емакс в 2026 году при наличии nvim?

зачем в 2026 году нужен lesopilorama, при наличии zabbal?

Пусть git чтоль спрашивает можно ли ему прочитать .git/config

а почему бы нет? Можно хотя бы давать предупреждение, что при выполнении git status будет выполнена такая-то команда (оно же знает что у него в core.fsmonitor указано и что будет запускаться). Судя по описанию, проблема действительно же касается всех, кто делает кто запускает git команды, а не только emacs

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

это maidcore какой-то, ведь правда ?

именно из-за этого я и подумал про предупреждение, так как достаточно просто перейти в склонированную репу. Но да, задолбает. Еще как вариант - условный git –safe-mode status, который не будет выполнять fsmonitor.

проблема-то есть и атак будет все больше и больше, в том числе такими неочевидными способами. При это обязательно должна быть возможность в $HOME/.gitconfig указать idgaf=true и отключить все проверки/ограничения

Господа, не забываем делиться инфой с братюнями о том, зачем нужен emacs на 2026 год господам, у которых есть neovim. Не ради срача вопросик, истинно интересно что мы упускаем. Без наброса.

Ммм… У меня есть пара знакомых, которые юзают neovim и честно признаются, что мечтают переехать на emacs, но не достаёт знаний :) Сорри, это сойдет за наброс, но это правда.

Emacs, на мой нубский взгляд, гораздо глубже, чем просто текстовый редактор. Это философия. Если он пропадёт, то возникнет вновь. «…к нему не зарастёт народная тропа», если обращаться к словам Александра Сергеевича.

vim/neovim это h-j-k-l и мнимая (опять же, на мой не самый просвещённый взгляд) «производительность», которой на самом деле нет, т.к. производительность в программировании - это не про скорость набора.

Если бы разработчики емакса реализовали гит в своём коде

И такое тоже есть - magit называется. Правда это не часть апстрима, во всяком случае пока - в нём до сих пор vc-git.el

Разработчики git считают это не уязвимостью, а фичей и исправлять ничего не планируют.

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

и исправлять её надо там. Ну или нигде не исправлять.

Во-первых не исправлять, а митигировать - исправить уязвимость в git без правки git просто невозможно. Во-вторых вместо 100500 заплаток в куче программ вполне достаточно одной в виде shell alias, который принудительно добавляет к каждому вызову git любой программой отключение этой «фичи».

vim/neovim это h-j-k-l и мнимая (опять же, на мой не самый просвещённый взгляд) «производительность»,

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

а то что и в е-мах-е что в (neo)vi(m)[который ваще визуальный(заместо строчного) ed] это вагон легаси ситуацию не улучшает

Кто-нибудь задумывался, как GDB запускает процесс для отладки? Ну все знаем: fork/vfork/spawn, далее exec… только exec к нам никогда не вернется… А нам отлаживаться.

шта? man ptrace

+ https://youtu.be/_2C2CNmK7dQ : Senior Engineer tries Vibe Coding.

Ну без ptrace там тоже не обойдешься. Как бы, README из той директории:

This directory holds the source code to a library used to replace the
`execve' and `execveat' system calls, used by the Android port of
Emacs to start executables without intervention from the system.

The most edifying resource for developers will be GDB, or to be precise,
the Linux target implementations for architectures of interest.