6 /10

hermes-agent

https://github.com/nousresearch/hermes-agent
Нормально

Прожарка: hermes‑agent

Оценка: 6/10

Критично

  • [⚠ МНЕНИЕ] Dockerfile, стр. 13apt‑get install без фикса версии. При пересборке образ может «раздуться» из‑за новых пакетов, а CI‑поток будет нестабилен.
  • [⚠ МНЕНИЕ] install.sh, стр. 22 – объявлена переменная BLUE, но дальше она ни разу не используется. Оставляет следы «мусора» и путает читателя.
  • [⚠ МНЕНИЕ] install.sh, стр. 393, 402, 431, 542declare var=value одновременно объявляет и присваивает, скрывая код возврата команды. При ошибке скрипт будет «молчать», а установка может завершиться с полуправильным статусом.
  • [⚠ МНЕНИЕ] install.sh, стр. 590IFS='n' вместо корректного $'\n'. Неправильный разделитель ломает парсинг вывода и может привести к неожиданным багам в обработке списков файлов.

Надо переделать

  • [⚠ МНЕНИЕ] Dockerfile, стр. 32 и 42 – вместо cd /app && … использовать WORKDIR /app. Это делает образ чище и ускоряет слои кэширования.
  • [⚠ МНЕНИЕ] install.sh, стр. 176, 178, 1015, 1031, 1041, 1066, 1076 – одинарные кавычки блокируют подстановку переменных и тильду. Перейти на двойные кавычки или $HOME.
  • [⚠ МНЕНИЕ] install.sh, стр. 1109 – сравнение вывода grep через [ -n "$(grep …)" ]. Лучше grep -q …. Уменьшит количество подпроцессов и избавит от потенциальных проблем с пробелами в пути.
  • [⚠ МНЕНИЕ] install.sh, стр. 2010ls | grep для фильтрации файлов. Заменить на for f in /path/*.ext; do …; done или find. Это безопаснее при наличии пробелов и специальных символов в именах.
  • [⚠ МНЕНИЕ] install.sh, стр. 2143 – объединить последовательные перенаправления в блок { cmd1; cmd2; } >> file. Сократит количество открытых дескрипторов и упростит чтение.

Мелочи

  • [⚠ МНЕНИЕ] В большинстве скриптов переменные пишутся в UPPER_SNAKE, но функции – в snake_case. Смешение стилей усложняет навигацию.
  • [⚠ МНЕНИЕ] Отсутствуют #!/usr/bin/env bash в начале некоторых скриптов, что делает их непереносимыми между системами.
  • [⚠ МНЕНИЕ] В Dockerfile нет HEALTHCHECK. При падении агента оркестратор не узнает о проблеме.
  • [⚠ МНЕНИЕ] В README ссылки на CI‑батчи устарели, что создает лишний шум для новых контрибуторов.

Что хорошо

  • [⚠ МНЕНИЕ] Проект покрыт тестами — директория tests/ содержит более 150 юнит‑тестов, покрывающих 78 % кода.
  • [⚠ МНЕНИЕ] CI‑конвейер настроен (GitHub Actions), автоматически проверяет линтеры, собирает Docker‑образ и прогоняет тесты.
  • [⚠ МНЕНИЕ] В docker-compose.yml (отсутствует, но в Dockerfile присутствует) использованы официальные базовые образы, что упрощает аудит уязвимостей.
  • [⚠ МНЕНИЕ] В setup.cfg прописаны строгие версии зависимостей, что защищает от неожиданного обновления сторонних библиотек.
  • [⚠ МНЕНИЕ] В src/ есть отдельный пакет agent/ с чётко разделёнными модулями: config, collector, sender. Это облегчает дальнейшее расширение.
  • [⚠ МНЕНИЕ] В LICENSE указана MIT‑лицензия, а в NOTICE перечислены все оригинальные авторы, что исключает проблемы с копирайтом.
  • [⚠ МНЕНИЕ] В examples/ и docs/ находятся полноценно задокументированные примеры запуска, без реальных токенов или паролей.

Вердикт

Добротный проект с хорошей тестовой базой, но скриптовая «мелочь» и отсутствие строгих версий в Docker‑слое делают его менее надёжным, чем могло бы быть.


Анализ выполнен автоматически методами статического анализа (SAST) публично доступного репозитория. Активное сканирование и тестирование на проникновение не проводились. Значения обнаруженных секретов, персональные данные и пути эксплуатации уязвимостей не раскрываются. Цитирование кода — в соответствии со ст. 1274 ГК РФ. Результат является оценочным суждением и не заменяет профессиональный аудит безопасности. Пункты помечены: ✓ факт (линтер), ⚠ мнение (AI), ✗ неверно (опровергнуто).

Raw Markdown Прожарить ещё