[Code Quality] Несогласованная семантика verify_ssl: из YAML true → путь к CA-bundle, из env true → bool #62

New Issue

artem.kokos · 2026-07-16T18:25:02+07:00

artem.kokos commented

2026-07-16 18:25:02 +07:00

Проблема

Одна и та же настройка verify_ssl даёт значения разных типов в зависимости от источника конфигурации.

YAML verify_ssl: true → путь /etc/ssl/certs/ca-certificates.crt (redmine_reporter/config.py:162-163):

if isinstance(value, bool):
    return DEFAULT_REDMINE_VERIFY if value else False

Env REDMINE_VERIFY=true → bool True (redmine_reporter/config.py:295-300):

if normalized in TRUE_VALUES:
    return True

Для requests оба варианта рабочие (True — системное хранилище CA, путь — конкретный bundle), но семантика различается: системное хранилище и захардкоженный путь (config.py:17, DEFAULT_REDMINE_VERIFY = "/etc/ssl/certs/ca-certificates.crt") — не одно и то же. На дистрибутивах с другим расположением CA или в контейнерах поведение YAML и env конфигураций будет разным при внешне одинаковых настройках.

Тесты явно фиксируют оба поведения, то есть расхождение осознанное, но недокументированное и запутанное для пользователя.

Связанные места

redmine_reporter/config.py:17 (DEFAULT_REDMINE_VERIFY)
redmine_reporter/config.py:160-170 (YAML verify_ssl)
redmine_reporter/config.py:295-300 (env REDMINE_VERIFY)
docs/CONFIG.md

Критерии приёмки

verify_ssl: true (YAML) и REDMINE_VERIFY=true (env) дают идентичный результат.
Поведение описано в docs/CONFIG.md.
Тесты обновлены и зелёные.

## Проблема Одна и та же настройка `verify_ssl` даёт значения разных типов в зависимости от источника конфигурации. YAML `verify_ssl: true` → **путь** `/etc/ssl/certs/ca-certificates.crt` (`redmine_reporter/config.py:162-163`): ```python if isinstance(value, bool): return DEFAULT_REDMINE_VERIFY if value else False ``` Env `REDMINE_VERIFY=true` → **bool** `True` (`redmine_reporter/config.py:295-300`): ```python if normalized in TRUE_VALUES: return True ``` Для `requests` оба варианта рабочие (`True` — системное хранилище CA, путь — конкретный bundle), но семантика различается: системное хранилище и захардкоженный путь (`config.py:17`, `DEFAULT_REDMINE_VERIFY = "/etc/ssl/certs/ca-certificates.crt"`) — не одно и то же. На дистрибутивах с другим расположением CA или в контейнерах поведение YAML и env конфигураций будет разным при внешне одинаковых настройках. Тесты явно фиксируют оба поведения, то есть расхождение осознанное, но недокументированное и запутанное для пользователя. ## Рекомендации 1. Унифицировать семантику: `true` из любого источника должно давать одно и то же значение (либо всегда `DEFAULT_REDMINE_VERIFY`, либо всегда `True`; путь к CA оставить настраиваемым отдельным параметром). 2. Задокументировать итоговое поведение в `docs/CONFIG.md`. 3. Обновить тесты, фиксирующие текущую асимметрию. ## Связанные места - `redmine_reporter/config.py:17` (`DEFAULT_REDMINE_VERIFY`) - `redmine_reporter/config.py:160-170` (YAML `verify_ssl`) - `redmine_reporter/config.py:295-300` (env `REDMINE_VERIFY`) - `docs/CONFIG.md` ## Критерии приёмки - [ ] `verify_ssl: true` (YAML) и `REDMINE_VERIFY=true` (env) дают идентичный результат. - [ ] Поведение описано в `docs/CONFIG.md`. - [ ] Тесты обновлены и зелёные.

artem.kokos added the config refactoring labels 2026-07-16 18:25:02 +07:00

artem.kokos referenced this issue from a commit

2026-07-17 14:52:44 +07:00

fix: unify verify_ssl semantics across config sources

artem.kokos closed this issue

2026-07-17 14:52:44 +07:00

artem.kokos referenced this issue from a commit

2026-07-17 18:40:48 +07:00

fix: use OS trust store for TLS verification via truststore

Sign in to join this conversation.