pgAdmin

Декодирует версию из cache-busting параметра запроса ?ver=NNNNN, который pgAdmin добавляет к каждому статическому ресурсу на странице входа — так задумано, поскольку она обязана рендериться ещё до появления какой-либо сессии.

targets:
  - id: pgadmin-main
    product: pgadmin
    address: https://pgadmin.example.com

Аутентификация

Отсутствует — эндпоинт не принимает никакого credential.

Как декодируется версия

Подтверждено на реальном контейнере dpage/pgadmin4 и собственном исходном коде pgAdmin (version.py): NNNNN — это APP_VERSION_INT, документированный там как [X]XYYZZ — релиз, ревизия, затем код суффикса — например, 91700 для релиза 9, ревизии 17, суффикса 00 (GA). Восстанавливается только пара релиз.ревизия; ненулевой код суффикса (сборка beta/dev) не имеет документированного текстового соответствия, чтобы восстановить его только из кода, поэтому он показывается в extra.suffixCode, а не угадывается.

Записываемые поля

• version — например, 9.17
• extra.suffixCode, только если он ненулевой

Сопоставление с CVE

Сверяется с NVD и БДУ ФСТЭК, если настроен блок cve:.

Резолвер жизненного цикла

github-tags:pgadmin-org/pgadmin4. У endoflife.date нет календаря для pgAdmin (подтверждено 404), а у pgadmin-org/pgadmin4 вообще нет GitHub Releases (подтверждено вживую: эндпоинт releases возвращает пустой массив) — только теги, в форме REL-9_17, а не версии через точки. Тип резолвера github-tags создан именно для такого случая: он превращает эту форму в 9.17 и выбирает тег с максимально разбираемой версией среди полученных, а не полагается на порядок в списке — в отличие от Releases с их обратной хронологией, у эндпоинта тегов никакой гарантии порядка не документировано. Как и обычный резолвер github:, он знает только «последнюю версию» — без дат eol/support/lts, поскольку у эндпоинта тегов их просто нет. Переменная окружения GITHUB_TOKEN, поднимающая лимит запросов для этого резолвера, описана в Поддерживаемых продуктах.