ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [devel] X509v3: CRL Distribution Points: help is needed
@ 2018-08-08 15:43 manowar
  2018-08-08 16:33 ` Alexey V. Vissarionov
  0 siblings, 1 reply; 16+ messages in thread
From: manowar @ 2018-08-08 15:43 UTC (permalink / raw)
  To: ALT Linux Team development discussions


  Всем привет. Прошу помощи у тех, кто хорошо "шарит" в ASN.1.

  Имею экземпляр цифровой подписи в формате PKCS#7 (CMS). Для того,
чтобы её проверить по правилам, нужно принять во внимание списки отзыва
сертификатов (CRL).
  Согласно стандарту (RFC 3280, п. 4.2.1.14 [1]), информация о списках
отзыва (вернее о том, где можно их получить) представляется в виде
списка (SEQUENCE) объектов типа DistributionPoint. Каждый
DistributionPoint содержит 3 поля, одно из которых ---
distributionPoint --- и является собственно именем (адресом) для
получения CRL. Однако, по тому же стандарту (если я правильно его
понял), поле distributionPoint.fullName может, в свою очередь, быть
представлено _списком_ типа GeneralNames. Тогда получается, что для
каждого объекта DistributionPoint задать _несколько_ адресов одновременно.
  Возможность и смысл указания нескольких адресов подтверждается
наличием в документе следующих слов: "each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP" --- т.е. каждый адрес, входящий в состав
distributionPoint.fullName, вроде бы является _альтернативой_ для
получения _одного и того же_ списка отзыва.

  Вот как выглядит в разобранном виде та часть файла подписи, которая
отвечает за CRL:

> SEQUENCE(2 elem)
>   OBJECT IDENTIFIER2.5.29.31cRLDistributionPoints(X.509 extension)
>   OCTET STRING(1 elem)
>     SEQUENCE(2 elem)
>       SEQUENCE(1 elem)
>         [0](1 elem)
>           [0](1 elem)
>             [6]http://pki-lan/ocsp/6b00868389d200cf56b86be4e336101e1f72aec3.crl
>       SEQUENCE(1 elem)
>         [0](1 elem)
>           [0](1 elem)
>             [6]http://pki.grfc.ru/ra/cdp/6b00868389d200cf56b86be4e336101e1f72aec3.crl

( Весь файл целиком доступен по (сокр.) адресу:
https://tinyurl.com/ybpjg9ha )

  Теперь, собственно, сам вопрос: структура выше соответствует двум
разным CRL? или же это всё-таки два варианта получения одного и того же
CRL? Иными словами, что перед нами: два объекта типа DistributionPoint
или же две строки, относящиеся к одному такому объекту?
  Сам я склоняюсь к первому варианту --- формально заявлено два _разных_
CRL. Однако меня смущает указание на количество elem, которое я не
совсем понимаю как читать.

  Предыстория же моего вопроса связана с тем, что первый из указанных
адресов --- это, очевидно, адрес внутренней сети, а не Интернет. А это
значит, что издатель подписи (сертификата) рассчитывал на то, что оба
указанных им адреса будут расценены как альтернативные и, при
недоступности первого, проверяющий перейдёт по второму. Но dirmngr (из
пакета gnupg2) считает иначе: он расценивает указанную информацию как
список из двух различных CRL, которые, следовательно, оба требуются для
проверки подписи. Невозможность получить CRL по первому адресу в
результате приводит к невозможности подтвердить подпись.
  Короче говоря, мне нужно понять кто не прав: GnuPG или grfc.ru. В
пользу последнего как будто бы говорит его официальный статус УЦ. Но с
другой стороны, знаем мы эти статусы.

---
[1]: https://tools.ietf.org/html/rfc3280#section-4.2.1.14


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] X509v3: CRL Distribution Points: help is needed
  2018-08-08 15:43 [devel] X509v3: CRL Distribution Points: help is needed manowar
@ 2018-08-08 16:33 ` Alexey V. Vissarionov
  2018-08-08 16:52   ` Paul Wolneykien
  0 siblings, 1 reply; 16+ messages in thread
From: Alexey V. Vissarionov @ 2018-08-08 16:33 UTC (permalink / raw)
  To: ALT Linux Team development discussions; +Cc: gremlin

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

On 2018-08-08 18:43:25 +0300, manowar@altlinux.org wrote:

 > поле distributionPoint.fullName может, в свою очередь, быть
 > представлено _списком_ типа GeneralNames. Тогда получается, что
 > для каждого объекта DistributionPoint задать _несколько_ адресов
 > одновременно.

Да. И это будут несколько адресов _одного_ CRL.

 > Возможность и смысл указания нескольких адресов подтверждается
 > наличием в документе следующих слов: "each name describes a
 > different mechanism to obtain the same CRL.
				^^^^^^^^^^^^^
 > т.е. каждый адрес, входящий в состав distributionPoint.fullName,
 > вроде бы является _альтернативой_ для получения _одного и того
 > же_ списка отзыва.

Да.

 > Вот как выглядит в разобранном виде та часть файла подписи,
 > которая отвечает за CRL: [...]
 > Теперь, собственно, сам вопрос: структура выше соответствует
 > двум разным CRL?

Нет - это один CRL, для которого предусмотрена возможность взять
его как с локального зеркала (pki-lan), так и снаружи у ГРЧЦ.

 > или же это всё-таки два варианта получения одного и того же CRL?

Да.

 > Иными словами, что перед нами: два объекта типа DistributionPoint
 > или же две строки, относящиеся к одному такому объекту?

Это два места, откуда можно взять один и тот же CRL.

 > Сам я склоняюсь к первому варианту --- формально заявлено два
 > _разных_ CRL. Однако меня смущает указание на количество elem,
 > которое я не совсем понимаю как читать.

Список из двух списков, в каждом из которых по одному элементу.

 > Предыстория же моего вопроса связана с тем, что первый из
 > указанных адресов --- это, очевидно, адрес внутренней сети, а
 > не Интернет. А это значит, что издатель подписи (сертификата)
 > рассчитывал на то, что оба указанных им адреса будут расценены
 > как альтернативные и, при недоступности первого, проверяющий
 > перейдёт по второму.

Именно так. Локальное зеркало - best practice, ибо недоступность
CRL может привести к тому, что отозванный сертификат будет принят
как рабочий.

 > Но dirmngr (из пакета gnupg2) считает иначе: он расценивает
 > указанную информацию как список из двух различных CRL, которые,
 > следовательно, оба требуются для проверки подписи.

Идея здравая, но реализована, мягко говоря, per rectum.

 > Невозможность получить CRL по первому адресу в результате
 > приводит к невозможности подтвердить подпись.

Выражусь дипломатично: д, б.

Проверять, действительно, нужно все источники (на случай, если
какое-то свежее изменение в апстриме не доехало до зеркала), но
отваливаться по UTV (unable to verify|validate) следует только
когда недоступны _все_ источники.

 > Короче говоря, мне нужно понять кто не прав: GnuPG или grfc.ru.

Головожопы из GnuPG, которым стандарты не писаны.

 > В пользу последнего как будто бы говорит его официальный статус
 > УЦ.

Главное - в их пользу явно гласит стандарт.

 > Но с другой стороны, знаем мы эти статусы.

Плохо знаешь. У них за прошедшие лет 10 очень многое поменялось,
и прежде всего - они почти всех дедов-пердунов на пенсию выгнали.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] X509v3: CRL Distribution Points: help is needed
  2018-08-08 16:33 ` Alexey V. Vissarionov
@ 2018-08-08 16:52   ` Paul Wolneykien
  2018-08-10 12:52     ` Paul Wolneykien
  0 siblings, 1 reply; 16+ messages in thread
From: Paul Wolneykien @ 2018-08-08 16:52 UTC (permalink / raw)
  To: devel

08.08.2018 19:33, Alexey V. Vissarionov пишет:
> On 2018-08-08 18:43:25 +0300, manowar@altlinux.org wrote:
>  > Вот как выглядит в разобранном виде та часть файла подписи,
>  > которая отвечает за CRL: [...]
>  > Теперь, собственно, сам вопрос: структура выше соответствует
>  > двум разным CRL?
> 
> Нет - это один CRL, для которого предусмотрена возможность взять
> его как с локального зеркала (pki-lan), так и снаружи у ГРЧЦ.
> 
>  > или же это всё-таки два варианта получения одного и того же CRL?
> 
> Да.
> 
>  > Иными словами, что перед нами: два объекта типа DistributionPoint
>  > или же две строки, относящиеся к одному такому объекту?
> 
> Это два места, откуда можно взять один и тот же CRL.

  Ммм. А ты можешь всё-таки как-то это аргументировать? Я вижу две ветки
SEQUENCE в каждой из которых по три поля: [0](1 elem), [0](1 elem)
(кажется, это те самые "reasons" и "cRLIssuer") и [6]строка. Собственно,
ты сам пишешь:

> ...
> Список из двух списков, в каждом из которых по одному элементу.

По одному. Следовательно, это не похоже на случай: "If the
DistributionPointName contains multiple values,...". Или всё-таки похоже?

>> В пользу последнего как будто бы говорит его официальный статус
>  > УЦ.
>
> Главное - в их пользу явно гласит стандарт.

Вот какой стандарт: RFC 3280? или сложившаяся практика обработки CRL?
Мне пока что интересно только одно: как результат ASN.1 разбора данного
файла соотносится с данным RFC, п. 4.2.1.14. Дальше видно будет.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] X509v3: CRL Distribution Points: help is needed
  2018-08-08 16:52   ` Paul Wolneykien
@ 2018-08-10 12:52     ` Paul Wolneykien
  2018-08-10 13:21       ` [devel] wiki altlinux.org внутренняя ошибка Александр Антонов
  2018-08-10 14:51       ` [devel] X509v3: CRL Distribution Points: help is needed Alexey V. Vissarionov
  0 siblings, 2 replies; 16+ messages in thread
From: Paul Wolneykien @ 2018-08-10 12:52 UTC (permalink / raw)
  To: devel

08.08.2018 19:52, Paul Wolneykien пишет:
> 08.08.2018 19:33, Alexey V. Vissarionov пишет:
>> On 2018-08-08 18:43:25 +0300, manowar@altlinux.org wrote:
>>  > Вот как выглядит в разобранном виде та часть файла подписи,
>>  > которая отвечает за CRL: [...]
>>  > Теперь, собственно, сам вопрос: структура выше соответствует
>>  > двум разным CRL?
>>
>> Нет - это один CRL, для которого предусмотрена возможность взять
>> его как с локального зеркала (pki-lan), так и снаружи у ГРЧЦ.

  Итак, я, прежде всего, точно выяснил, что же записано в оговоренной
секции сертификата. Разберу подробно тут, вдруг кому будет полезно (что
называется --- отвечаю сам себе).

  Начинается всё с

    SEQUENCE(2 elem)  --- Так кодируется экземпляр расширения
(extension) X.509. Элементами списка (именно --- 2 элемента) являются:

      OBJECT IDENTIFIER 2.5.29.31 --- кодовый номер расширения и
      OCTET STRING (длинная строка, длиной 153 байта) --- его
содержимое, которое мы разбираем ниже:

        SEQUENCE(2 elem) --- Снова список. На этот раз --- это список,
состоящий из нескольких DistributionPoint, каждый из которых является
тоже списком с количеством элементов от 0 до 3 (поскольку все они
опциональные):

          SEQUENCE(1 elem) --- Это DistributionPoint с единственным
указанным элементом, осталось понять, каким:

            [0](1 elem) --- Теперь ясно, что это элемент с тегом [0], а
именно --- DistributionPointName. Он, в свою очередь может быть
представлен двумя различными способами, поэтому следом снова указывается:

              [0](1 elem) --- Тем самым выбирается вариант fullName,
помеченный в схеме тегом [0] и имеющим тип GeneralNames. Тип
GeneralNames представляет собой список из 1 или более альтернативных
значений, в котором каждая альтернатива обозначается тегом с номером от
[0] до [8]. Поэтому следом идёт наконец:

                [6]http://pki-lan/ocsp... --- Это
uniformResourceIdentifier (тег [6]) типа IA5String.


  Второй DistributionPoint оформлен точно так же, как первый. Поэтому
формально --- это именно два разных DistributionPoint, т.е. два разных
CRL. И в каждом DistributionPoint только один URI.
  То, что возможно сделать иначе: задать несколько URI для каждой
DistributionPoint --- можно узнать, например, и следующей инструкции:


https://www.pixelstech.net/article/1445498968-Generate-certificate-with-cRLDistributionPoints-extension-using-OpenSSL


08.08.2018 19:33, Alexey V. Vissarionov пишет:
> On 2018-08-08 18:43:25 +0300, manowar@altlinux.org wrote:
>  > не Интернет. А это значит, что издатель подписи (сертификата)
>  > рассчитывал на то, что оба указанных им адреса будут расценены
>  > как альтернативные и, при недоступности первого, проверяющий
>  > перейдёт по второму.
>
> Именно так. Локальное зеркало - best practice, ибо недоступность
> CRL может привести к тому, что отозванный сертификат будет принят
> как рабочий.
>
>  > Но dirmngr (из пакета gnupg2) считает иначе: он расценивает
>  > указанную информацию как список из двух различных CRL, которые,
>  > следовательно, оба требуются для проверки подписи.
>
> Идея здравая, но реализована, мягко говоря, per rectum.
> ...
> Проверять, действительно, нужно все источники (на случай, если
> какое-то свежее изменение в апстриме не доехало до зеркала), но
> отваливаться по UTV (unable to verify|validate) следует только
> когда недоступны _все_ источники.

  А вот теперь вопрос, чья это идея (последний абзац выше): это твоё
личное представление о том, как должно быть или всё таки нечто
общепринятое? Допустим, ты сомневаешься насчёт верности реализации в
GnuPG. Но как тебе такое:

static X509_CRL *load_crl_crldp(STACK_OF(DIST_POINT) *crldp)
{
    int i;
    const char *urlptr = NULL;
    for (i = 0; i < sk_DIST_POINT_num(crldp); i++) {
        DIST_POINT *dp = sk_DIST_POINT_value(crldp, i);
        urlptr = get_dp_url(dp);
        if (urlptr)
            return load_crl(urlptr, FORMAT_HTTP);
    }
    return NULL;
}

  Это я обнаружил в OpenSSL. И там, как видно, внутри цикла выход по
return на _первой_ же непустой DistributionPoint. Следовательно,
реализация OpenSSL рассчитана на то, что _все_ указанные источники будут
доступны. И если какой-то недоступен, то будет ошибка (там bio_err
внутри load_crl).
  Проверяем на нашем примере:

$ openssl verify -engine gost -CAfile parsed2.txt -crl_download
-crl_check parsed.txt
engine "gost" set.
Error loading CRL from
http://pki-lan/ocsp/6b00868389d200cf56b86be4e336101e1f72aec3.crl
140430750978520:error:2006A066:BIO routines:BIO_get_host_ip:bad hostname
lookup:b_sock.c:146:host=pki-lan
parsed.txt: 1.2.643.100.3 = ...
error 3 at 0 depth lookup:unable to get certificate CRL

  Получаем тот же результат, что и через GnuPG. С той лишь разницей, что
в GnuPG заложен перебор нескольких альтернативных URI для одной
DistributionPoint, а вот OpenSSL даже не предполагает альтернатив ---
все должны быть доступны.

  Получается, что предположение о том, что в разбираемом сертификате оба
URI нужно расценивать как альтернативные, не подтверждается ни теорией
(структурой в ASN.1), ни практикой (openssl verify).
  Или скажешь, что OpenSSL тоже не аргумент? А кто же тогда у них главный?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 12:52     ` Paul Wolneykien
@ 2018-08-10 13:21       ` Александр Антонов
  2018-08-10 13:46         ` Dmitry V. Levin
  2018-08-10 14:57         ` Anton Farygin
  2018-08-10 14:51       ` [devel] X509v3: CRL Distribution Points: help is needed Alexey V. Vissarionov
  1 sibling, 2 replies; 16+ messages in thread
From: Александр Антонов @ 2018-08-10 13:21 UTC (permalink / raw)
  To: devel

Здравствуйте. Хотел переименовать тему страницы 
https://www.altlinux.org/Rujel_123 на Rujel. Но при смене названия 
происходит внутренняя ошибка.

[84f69f086f51276839713c3c] 
/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%83&action=submit 
MediaWiki\Storage\IncompleteRevisionException from line 308 of 
/var/www/mediawiki/includes/Storage/RevisionStore.php: sha1 field must 
not be ''!

Backtrace:

#0 /var/www/mediawiki/includes/Storage/RevisionStore.php(352): 
MediaWiki\Storage\RevisionStore->failOnEmpty(string, string)
#1 /var/www/mediawiki/includes/Revision.php(1123): 
MediaWiki\Storage\RevisionStore->insertRevisionOn(MediaWiki\Storage\MutableRevisionRecord, 
Wikimedia\Rdbms\DatabaseMysqli)
#2 /var/www/mediawiki/includes/MovePage.php(538): 
Revision->insertOn(Wikimedia\Rdbms\DatabaseMysqli)
#3 /var/www/mediawiki/includes/MovePage.php(271): 
MovePage->moveToInternal(User, Title, string, boolean, array)
#4 /var/www/mediawiki/includes/specials/SpecialMovepage.php(595): 
MovePage->move(User, string, boolean)
#5 /var/www/mediawiki/includes/specials/SpecialMovepage.php(128): 
MovePageForm->doSubmit()
#6 /var/www/mediawiki/includes/specialpage/SpecialPage.php(522): 
MovePageForm->execute(NULL)
#7 /var/www/mediawiki/includes/specialpage/SpecialPageFactory.php(568): 
SpecialPage->run(NULL)
#8 /var/www/mediawiki/includes/MediaWiki.php(288): 
SpecialPageFactory::executePath(Title, RequestContext)
#9 /var/www/mediawiki/includes/MediaWiki.php(861): 
MediaWiki->performRequest()
#10 /var/www/mediawiki/includes/MediaWiki.php(524): MediaWiki->main()
#11 /var/www/mediawiki/index.php(42): MediaWiki->run()
#12 {main}


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 13:21       ` [devel] wiki altlinux.org внутренняя ошибка Александр Антонов
@ 2018-08-10 13:46         ` Dmitry V. Levin
  2018-08-10 14:03           ` Grigory Ustinov
  2018-08-10 14:29           ` Paul Wolneykien
  2018-08-10 14:57         ` Anton Farygin
  1 sibling, 2 replies; 16+ messages in thread
From: Dmitry V. Levin @ 2018-08-10 13:46 UTC (permalink / raw)
  To: Александр
	Антонов
  Cc: ALT Devel discussion list

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

On Fri, Aug 10, 2018 at 04:21:24PM +0300, Александр Антонов wrote:
> Здравствуйте. Хотел переименовать тему страницы 

Здравствуйте.  Никогда не начинайте новый тред кнопкой "Ответить".


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 13:46         ` Dmitry V. Levin
@ 2018-08-10 14:03           ` Grigory Ustinov
  2018-08-10 14:07             ` Alexey V. Vissarionov
  2018-08-15 13:37             ` Sergey V Turchin
  2018-08-10 14:29           ` Paul Wolneykien
  1 sibling, 2 replies; 16+ messages in thread
From: Grigory Ustinov @ 2018-08-10 14:03 UTC (permalink / raw)
  To: devel

On 10.08.2018 16:46, Dmitry V. Levin wrote:
> On Fri, Aug 10, 2018 at 04:21:24PM +0300, Александр Антонов wrote:
>> Здравствуйте. Хотел переименовать тему страницы
> Здравствуйте.  Никогда не начинайте новый тред кнопкой "Ответить".
>
А как вы догадались, Холмс? Поясните, пожалуйста, чтобы другие тоже так 
не делали?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 14:03           ` Grigory Ustinov
@ 2018-08-10 14:07             ` Alexey V. Vissarionov
  2018-08-15 13:37             ` Sergey V Turchin
  1 sibling, 0 replies; 16+ messages in thread
From: Alexey V. Vissarionov @ 2018-08-10 14:07 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2018-08-10 17:03:01 +0300, Grigory Ustinov wrote:

 >>> Здравствуйте. Хотел переименовать тему страницы
 >> Здравствуйте. Никогда не начинайте новый тред кнопкой
 >> "Ответить".
 > А как вы догадались, Холмс? Поясните, пожалуйста, чтобы
 > другие тоже так не делали?

К.О. спешит на помощь: в сообщении был заголовок "In-Reply-To".

Так-то! :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 13:46         ` Dmitry V. Levin
  2018-08-10 14:03           ` Grigory Ustinov
@ 2018-08-10 14:29           ` Paul Wolneykien
  2018-08-10 14:56             ` Leonid Krivoshein
  1 sibling, 1 reply; 16+ messages in thread
From: Paul Wolneykien @ 2018-08-10 14:29 UTC (permalink / raw)
  To: devel

10.08.2018 16:46, Dmitry V. Levin пишет:
> On Fri, Aug 10, 2018 at 04:21:24PM +0300, Александр Антонов wrote:
>> Здравствуйте. Хотел переименовать тему страницы 
> 
> Здравствуйте.  Никогда не начинайте новый тред кнопкой "Ответить".
>

  Я тоже не начинал кнопкой "ответить", а честно сделал новое письмо. Но
сегодня, когда листал архив в mailman, то обнаружил, что моя тема про
CRL приклеилась к alt-gpgkeys.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] X509v3: CRL Distribution Points: help is needed
  2018-08-10 12:52     ` Paul Wolneykien
  2018-08-10 13:21       ` [devel] wiki altlinux.org внутренняя ошибка Александр Антонов
@ 2018-08-10 14:51       ` Alexey V. Vissarionov
  1 sibling, 0 replies; 16+ messages in thread
From: Alexey V. Vissarionov @ 2018-08-10 14:51 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On 2018-08-10 15:52:26 +0300, Paul Wolneykien wrote:

 >>> А это значит, что издатель подписи (сертификата) рассчитывал
 >>> на то, что оба указанных им адреса будут расценены как
 >>> альтернативные и, при недоступности первого, проверяющий
 >>> перейдёт по второму.
 >> Именно так. Локальное зеркало - best practice, ибо недоступность
 >> CRL может привести к тому, что отозванный сертификат будет
 >> принят как рабочий.
 >>> Но dirmngr (из пакета gnupg2) считает иначе: он расценивает
 >>> указанную информацию как список из двух различных CRL, которые,
 >>> следовательно, оба требуются для проверки подписи.
 >> Идея здравая, но реализована, мягко говоря, per rectum.
 >> ...
 >> Проверять, действительно, нужно все источники (на случай, если
 >> какое-то свежее изменение в апстриме не доехало до зеркала), но
 >> отваливаться по UTV (unable to verify|validate) следует только
 >> когда недоступны _все_ источники.
 > А вот теперь вопрос, чья это идея (последний абзац выше): это
 > твоё личное представление о том, как должно быть или всё таки
 > нечто общепринятое?

Это мое личное мнение, основанное на моих же представлениях о том,
как можно злоупотребить некорректной реализацией :-)

 > Допустим, ты сомневаешься насчёт верности реализации в GnuPG.
 > Но как тебе такое:
 > [...]
 > Это я обнаружил в OpenSSL. И там, как видно, внутри цикла выход
 > по return на _первой_ же непустой DistributionPoint.

То, что эти реализации различаются между собой, свидетельствует о
том, что как минимум одна из них некорректна. Я же придерживаюсь
мнения о том, что некорректны обе :-)

 > Получаем тот же результат, что и через GnuPG. С той лишь разницей,
 > что в GnuPG заложен перебор нескольких альтернативных URI для
 > одной DistributionPoint, а вот OpenSSL даже не предполагает
 > альтернатив --- все должны быть доступны.

Дурь. Ибо кладем один источник - и вся система огребает DoS.

 > Получается, что предположение о том, что в разбираемом
 > сертификате оба URI нужно расценивать как альтернативные, не
 > подтверждается ни теорией (структурой в ASN.1), ни практикой
 > (openssl verify). Или скажешь, что OpenSSL тоже не аргумент?
 > А кто же тогда у них главный?

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 14:29           ` Paul Wolneykien
@ 2018-08-10 14:56             ` Leonid Krivoshein
  0 siblings, 0 replies; 16+ messages in thread
From: Leonid Krivoshein @ 2018-08-10 14:56 UTC (permalink / raw)
  To: ALT Linux Team development discussions


10.08.2018 17:29, Paul Wolneykien пишет:
> 10.08.2018 16:46, Dmitry V. Levin пишет:
>> On Fri, Aug 10, 2018 at 04:21:24PM +0300, Александр Антонов wrote:
>>> Здравствуйте. Хотел переименовать тему страницы
>> Здравствуйте.  Никогда не начинайте новый тред кнопкой "Ответить".
>>
>    Я тоже не начинал кнопкой "ответить", а честно сделал новое письмо. Но
> сегодня, когда листал архив в mailman, то обнаружил, что моя тема про
> CRL приклеилась к alt-gpgkeys.

Заметил: очень часто, когда кто-то начинает новую тему (неважно, в какой 
рассылке), она приклеивается к последнему сообщению в этом месяце.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 13:21       ` [devel] wiki altlinux.org внутренняя ошибка Александр Антонов
  2018-08-10 13:46         ` Dmitry V. Levin
@ 2018-08-10 14:57         ` Anton Farygin
  2018-08-10 15:09           ` Leonid Krivoshein
  2018-08-10 15:29           ` Dmitry V. Levin
  1 sibling, 2 replies; 16+ messages in thread
From: Anton Farygin @ 2018-08-10 14:57 UTC (permalink / raw)
  To: ALT Linux Team development discussions,
	Александр
	Антонов

А по делу то кто-то скажет ?

10.08.2018 16:21, Александр Антонов пишет:
> Здравствуйте. Хотел переименовать тему страницы 
> https://www.altlinux.org/Rujel_123 на Rujel. Но при смене названия 
> происходит внутренняя ошибка.
>
> [84f69f086f51276839713c3c] 
> /index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%83&action=submit 
> MediaWiki\Storage\IncompleteRevisionException from line 308 of 
> /var/www/mediawiki/includes/Storage/RevisionStore.php: sha1 field must 
> not be ''!
>
> Backtrace:
>
> #0 /var/www/mediawiki/includes/Storage/RevisionStore.php(352): 
> MediaWiki\Storage\RevisionStore->failOnEmpty(string, string)
> #1 /var/www/mediawiki/includes/Revision.php(1123): 
> MediaWiki\Storage\RevisionStore->insertRevisionOn(MediaWiki\Storage\MutableRevisionRecord, 
> Wikimedia\Rdbms\DatabaseMysqli)
> #2 /var/www/mediawiki/includes/MovePage.php(538): 
> Revision->insertOn(Wikimedia\Rdbms\DatabaseMysqli)
> #3 /var/www/mediawiki/includes/MovePage.php(271): 
> MovePage->moveToInternal(User, Title, string, boolean, array)
> #4 /var/www/mediawiki/includes/specials/SpecialMovepage.php(595): 
> MovePage->move(User, string, boolean)
> #5 /var/www/mediawiki/includes/specials/SpecialMovepage.php(128): 
> MovePageForm->doSubmit()
> #6 /var/www/mediawiki/includes/specialpage/SpecialPage.php(522): 
> MovePageForm->execute(NULL)
> #7 
> /var/www/mediawiki/includes/specialpage/SpecialPageFactory.php(568): 
> SpecialPage->run(NULL)
> #8 /var/www/mediawiki/includes/MediaWiki.php(288): 
> SpecialPageFactory::executePath(Title, RequestContext)
> #9 /var/www/mediawiki/includes/MediaWiki.php(861): 
> MediaWiki->performRequest()
> #10 /var/www/mediawiki/includes/MediaWiki.php(524): MediaWiki->main()
> #11 /var/www/mediawiki/index.php(42): MediaWiki->run()
> #12 {main}
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 14:57         ` Anton Farygin
@ 2018-08-10 15:09           ` Leonid Krivoshein
  2018-08-10 15:29           ` Dmitry V. Levin
  1 sibling, 0 replies; 16+ messages in thread
From: Leonid Krivoshein @ 2018-08-10 15:09 UTC (permalink / raw)
  To: devel


10.08.2018 17:57, Anton Farygin пишет:
> А по делу то кто-то скажет ?
>
> 10.08.2018 16:21, Александр Антонов пишет:
>> Здравствуйте. Хотел переименовать тему страницы 
>> https://www.altlinux.org/Rujel_123 на Rujel. Но при смене названия 
>> происходит внутренняя ошибка.
>>
>> [84f69f086f51276839713c3c] 
>> /index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%83&action=submit 
>> MediaWiki\Storage\IncompleteRevisionException from line 308 of 
>> /var/www/mediawiki/includes/Storage/RevisionStore.php: sha1 field 
>> must not be ''!
>>

Этот движок внутренне не знаю и не знаю, кто заведует ВиКи. В 
оригинальном коде на гитхабе в 308 строке исключения возникнуть не могло 
по определению -- там комментарий. Судя по описаниям в Интернете, 
проблема возникает после обновления движка МедиаВики и наличии не всех 
заполненных записей с полем sha1. Может помочь очистка поля sha1 для 
всех записей и повторный запуск populateRevisionSha1.php, но это всё к 
админам ВиКи и после бэкапа, разумеется.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 14:57         ` Anton Farygin
  2018-08-10 15:09           ` Leonid Krivoshein
@ 2018-08-10 15:29           ` Dmitry V. Levin
  2018-08-10 16:26             ` Anton Farygin
  1 sibling, 1 reply; 16+ messages in thread
From: Dmitry V. Levin @ 2018-08-10 15:29 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Fri, Aug 10, 2018 at 05:57:27PM +0300, Anton Farygin wrote:
> А по делу то кто-то скажет ?

Мантейнер (если читает)?
Другие варианты: повесить баг, написать мантейнеру лично, использовать
альтернативные средства связи.


-- 
ldv


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 15:29           ` Dmitry V. Levin
@ 2018-08-10 16:26             ` Anton Farygin
  0 siblings, 0 replies; 16+ messages in thread
From: Anton Farygin @ 2018-08-10 16:26 UTC (permalink / raw)
  To: ALT Linux Team development discussions

10.08.2018 18:29, Dmitry V. Levin пишет:
> On Fri, Aug 10, 2018 at 05:57:27PM +0300, Anton Farygin wrote:
>> А по делу то кто-то скажет ?
> Мантейнер (если читает)?
> Другие варианты: повесить баг, написать мантейнеру лично, использовать
> альтернативные средства связи.
>
>
Я уже.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [devel] wiki altlinux.org внутренняя ошибка
  2018-08-10 14:03           ` Grigory Ustinov
  2018-08-10 14:07             ` Alexey V. Vissarionov
@ 2018-08-15 13:37             ` Sergey V Turchin
  1 sibling, 0 replies; 16+ messages in thread
From: Sergey V Turchin @ 2018-08-15 13:37 UTC (permalink / raw)
  To: ALT Linux Team development discussions

On Friday, 10 August 2018 17:03:01 MSK Grigory Ustinov wrote:
> On 10.08.2018 16:46, Dmitry V. Levin wrote:
> > On Fri, Aug 10, 2018 at 04:21:24PM +0300, Александр Антонов wrote:
> >> Здравствуйте. Хотел переименовать тему страницы
> > 
> > Здравствуйте.  Никогда не начинайте новый тред кнопкой "Ответить".
> 
> А как вы догадались, Холмс? Поясните, пожалуйста, чтобы другие тоже так
> не делали?
Даже гадать не надо.
https://photos.app.goo.gl/QLQBwqnFfsaUjUScA

-- 
Regards, Sergey.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2018-08-15 13:37 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-08 15:43 [devel] X509v3: CRL Distribution Points: help is needed manowar
2018-08-08 16:33 ` Alexey V. Vissarionov
2018-08-08 16:52   ` Paul Wolneykien
2018-08-10 12:52     ` Paul Wolneykien
2018-08-10 13:21       ` [devel] wiki altlinux.org внутренняя ошибка Александр Антонов
2018-08-10 13:46         ` Dmitry V. Levin
2018-08-10 14:03           ` Grigory Ustinov
2018-08-10 14:07             ` Alexey V. Vissarionov
2018-08-15 13:37             ` Sergey V Turchin
2018-08-10 14:29           ` Paul Wolneykien
2018-08-10 14:56             ` Leonid Krivoshein
2018-08-10 14:57         ` Anton Farygin
2018-08-10 15:09           ` Leonid Krivoshein
2018-08-10 15:29           ` Dmitry V. Levin
2018-08-10 16:26             ` Anton Farygin
2018-08-10 14:51       ` [devel] X509v3: CRL Distribution Points: help is needed Alexey V. Vissarionov

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git