Hacker News Digest

Исследователь обнаружил уязвимость в CLI-клиенте 1Password (op), позволяющую злоумышленникам получать доступ к хранилищу паролей после однократного ввода мастер-пароля пользователем. Уязвимость была ответственно раскрыта через BugCrowd в октябре 2023 года, а публикация разрешена в январе 2024. Основная проблема — CLI остаётся авторизованным до перезагрузки системы, что создаёт риски в supply-chain атаках.

Два основных вектора атаки: через IDE-расширения и через инструменты разработчика. Например, вредоносное расширение темы или плагина может использовать авторизованный сеанс op для перечисления и эксфильтрации всех доступных хранилищ. Уязвимость подтверждена на последних версиях macOS с оболочками zsh и bash, подчеркивая важность осторожности при установке стороннего ПО.

• Пользователи выражают обеспокоенность тем, что CLI 1Password предоставляет полный доступ ко всем хранилищам после однократной аутентификации, что создает риск при выполнении недоверенных скриптов.
• Обсуждается, является ли это уязвимостью или ожидаемым поведением, так как при выполнении произвольного кода на машине пользователя злоумышленник может получить доступ к данным и другими способами.
• Отмечается, что ответственное раскрытие уязвимости было проведено через BugCrowd в октябре 2023 года, а публикация была авторизована только в январе 2024 года.
• В качестве меры защиты предлагается использовать отдельные сервисные аккаунты для CLI с ограниченным доступом только к необходимым секретам.
• Некоторые пользователи критикуют 1Password за использование устаревших версий Electron, что может вызывать проблемы с производительностью и безопасностью.

zoxide — это умная замена команды cd, которая запоминает часто посещаемые каталоги и позволяет быстро переходить по ним с помощью частичного совпадения имён. Она поддерживает все основные оболочки, включая bash, zsh и fish, и использует алгоритм ранжирования для предложения наиболее релевантных путей.

Инструмент работает быстрее аналогов вроде autojump, так как написан на Rust, и интегрируется с fzf для интерактивного выбора. Практический бонус — экономия времени при навигации в сложных проектных структурах.

• Критика zoxide за нечёткость работы и потенциальные ошибки при навигации, а также предпочтение встроенного поиска по истории ZSH или комбинации с fzf.
• Положительные отзывы о значительном ускорении навигации и интеграции zoxide в рабочий процесс, особенно в сочетании с другими инструментами (fzf, bat, starship).
• Обсуждение альтернатив и схожих инструментов (autojump, z, navita, CDPATH в bash/zsh), их сравнение с zoxide.
• Варианты настройки и использования zoxide, включая алиасы для cd, флаг basedir и интерактивный режим zi.
• Замечания о том, что для многих пользователей нативные возможности оболочки или другие инструменты покрывают большинство потребностей.

rv — новый Ruby-менеджер
Десять лет я мечтал о менеджере, который одновременно управляет Ruby-версиями, ставит уже скомпилированные интерпретаторы и запускает любой скрипт без конфликтов. Такой инструмент уже есть — это Python-утилита uv. Вдохновившись ею, я начал делать rv.

Что умеет rv

• Написан на Rust ⇒ всё мгновенно: установка Ruby 3.4.x на macOS/Ubuntu занимает 1 с.
• rv tool run — запуск любой gem-команды (gist, rubocop, …) в изолированном окружении без предварительной настройки.
• rv tool install — ставит CLI-утилиту с собственным Ruby и гемами, не трогая проект.
• Однофайловые скрипты: внутри .rb хранятся версия Ruby и lock-файл; rv run script.rb — и всё работает.
• Единая команда вместо цепочки rvm install, bundle install, bundle exec.

Команда и статус
Уже подключились Samuel Giddins (RubyGems) и Sam Stephenson (rbenv). Сейчас rv умеет переключать Ruby в zsh и ставить готовые сборки.
Попробовать: spinel-coop/rv и roadmap.

• Участники обсуждают новый инструмент rv для Ruby, вдохновлённый uv из Python-мира.
• Одни рады скорости и «одному инструменту для всего» (Ruby + gems + инструменты), другие считают, что Bundler и так работает нормально.
• Часть разработчиков предпочитает универсальные менеджеры (mise, asdf, Nix), чтобы не плодить отдельные утилиты под каждый язык.
• Есть опасения, что Ruby может пойти по пути «venv-ада» Python или потребовать Rust для вклада.
• Несколько человек просят сравнительную таблицу с rvm/rbenv и поддержку .tool-versions.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.