Проверка подписи над отечественным Linux

https://portal.linuxtesting.ru/activity.html
https://portal.linuxtesting.ru/LvcKernelSignCheck.html
Есть, оказывается, вот такой вот проект с нашим fork-ом Linux.

У меня сертификат Минцифры в имеется, но проверку на этом сайте
сертификат не проходит. Смотрю в их сертификат, нахожу ссылку на другой
сертификат Минцифры, с точно таким же issuer/subject, но другим
серийником, ключом и временем жизни. Добавляю в CA хранилище. Не
проходит. Вижу что SKID⇔AKID всё равно отличаются. Видимо, есть ещё
какой-то сертификат Минцифры. Мало того, что эти уроды публиковали на
Госуслугах, которые у меня ни разу не открылись и с оригинального
источника я не видел сертификата, так их теперь ещё и не один имеется.
Ладно, пофиг, идём по не доверенным.

Скачал tarball, подпись. Конечно же она в "любимом" CMS формате. Пробую
распечатать и распарсить: имена в сертификатах вложенных выходят за
допустимые разрешённые границы (136 символов против 64). Как всегда,
ASN.1 схемы же для строгой валидации, ну ну. Правлю исходный код на
Python, меняю максимальные границы, теперь парсится.

В руководстве про проверке подписи предлагаю скачать самоподписанный
http://reestr-pki.ru/cdp/guc2022.crt. Типа с ним проверка должна пройти.
А вот фиг. Подписано оно вложенным в CMS сертификатом, который, в свою
очередь, выпущен не на этом guc2022. КриптоПро софт автоматически ходит
что ли в Интернет и докачивает недостающие сертификаты? Или же
документация не актуальна? Ладно, ссылка на CA в этом внутреннем
сертификате ведёт на http://crl.roskazna.ru/crl/ucfk_2024.crt. Вот он то
уже подписан guc2022.

Конечно же, проверка подписи CMS не выполнилась. Мы старались делать
наше ПО на Python строго следующем стандартам. И в нём нет обработчиков
для хэшей без указанных параметров (хотя бы NULL). Лень искать в
стандартах кто там прав, а кто нет -- всё равно конечный пользователь
вынужден смириться с тем, что делают все эти проприетарные средства.
Добавил обработчик для данных хэшей.

Конечно же упали дальше, не найдя допустимую пару sign⇔SPKI алгоритмов
проверки подписи! Тоже из-за отсутствия NULL параметров. Может быть у
нас ошибка, может есть обновлённые рекомендации X.509? Может быть.
Выходит что примерно раз в пять лет необходимо каждому править своё ПО,
так как меняются OID, меняются требования к AlgorithmIdentifier на моей
памяти с заядлой периодичностью. При этом всё продолжаются
использоваться CryptoPro параметры кривых, уже давно отсутствующие в
ТК26 рекомендациях. Ладно, правлю код, добавляю новые обработчики.

Опять же, лень искать, но мне всегда казалось, что CryptoPro-Xch кривые
так и называются "eXchange", потому что предназначены для DH/VKO, а не
подписи. Но тут сертификаты с Xch, судя по KeyUsage, для всего на свете
применяются. Может это, конечно, и не нарушает рекомендации, но вот
нафига так делать?

В итоге проверка прошла. Причём, удивительно, но нигде не было проблем с
endianness.

На странице руководства проверки подписи есть ссылка на эталонную
реализацию Стрибога. Клонируем, пробуем собрать:

    ld: error: duplicate symbol: uint512_u
    >>> defined at gost3411-2012-core.h:31 (./gost3411-2012-core.h:31)
    >>>            /tmp/gost3411-2012-6d90ab.o:(uint512_u)
    >>> defined at gost3411-2012-core.h:31 (./gost3411-2012-core.h:31)
    >>>            /tmp/gost3411-2012-core-b8b6a0.o:(.bss+0x0)

Замечательно, действительно переменная задана прямо в заголовочном файле:

    ALIGN(16) union uint512_u
    {
        unsigned long long QWORD[8];
    } uint512_u;

И как это может штатно собраться?

Люто ненавижу всю эту экосистему, ибо полный бардак, разброд и шатание.
И чуть ли не каждая проверка ГОСТовой подписи в CMS от разных систем
(налоговая, росреестр, ещё какие-то) приводит к обязательной правке
кода, так как везде какие-то выходящие за границы стандартов штуки.