[devel] I: TLS/SSL policy - broken packages

[Mikhail Yakshin]

Konstantin A. Lepikhov пишет:
> Hi Mikhail!
> 
> Friday 09, at 01:22:07 AM you wrote:
> ..
>> firefox, thunderbird, xulrunner, seamonkey, libnspr - общая замечание ко
>> всем, использующим NSS - имеет смысл, видимо, при сборке добавлять новый
>> ALT CA таким builtin token, как сейчас добавляется старый (в файле типа
>> firefox-0.9-alt-ssl-addon-certs.txt). В идеале - не просто добавлять
>> один CA, а устроить обратное преобразование из PEM в формат файла
>> сертификатов Gecko-образных.
> кажется, у нас все-таки сделано наоборт ;)

Надо как-то закрепить технологический процесс. По идее - если мы - сами 
себе хозяева, то и CA bundle тоже должен собираться самостоятельно, на 
основе каких-то мотиваций мейнтейнера соответствующего пакета (или может 
быть создать tls team?) Т.е. единовременная конвертация из сертификатов 
из gecko - хорошо, но дальше может быть ее поддерживать самим? И, 
соответственно, строить преобразование именно в сторону ca-certificates 
=> gecko?

>> MySQL-server - несет в себе в документации пример сертификата CA,
>> который используется как сервером, так и клиентом. Несмотря на то, что
>> сертификат в документации и отключен по умолчанию, при реальном
>> использовании его или аналогов требуется указание положения некоего CA
>> bundle через ключ типа "ssl-ca=SSL/cacert.pem". Вопрос к мейнтейнеру -
>> нет ли возможности / стоит ли патчить или что-то менять в MySQL, чтобы
>> по умолчанию он имел в виду наш общий CA bundle?
> только если вынести сервер из chroot'а - поскольку в chroot все равно
> придется bundle вручную запихивать.

Логично. Тогда пока пропускаем, думаю. Это плавно цепляется за куда 
более сложный вопрос о том, что вообще будет в ближайшем будущем с 
chrooted сервисами.

> BTW, то же самое придется и делать с postfix.

Угу.

>> Дополнительный список:
>>
> ...
>> nginx
> тут все очень простенько и неинтересно. Даже патчить не надо, т.к.
> подобный функционал еще не предусмотрен.

Вычеркиваю.

-- 
WBR, GreyCat