From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45CC3019.3050209@altlinux.org> Date: Fri, 09 Feb 2007 11:26:01 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <45CBA28F.9020804@altlinux.org> <20070208225523.GB26130@basalt.office.altlinux.org> In-Reply-To: <20070208225523.GB26130@basalt.office.altlinux.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] I: TLS/SSL policy: broken packages X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2007 08:28:29 -0000 Archived-At: List-Archive: List-Post: Dmitry V. Levin пишет: > On Fri, Feb 09, 2007 at 01:22:07AM +0300, Mikhail Yakshin wrote: >> nut-server - несет в себе файл /etc/nut/upsd.pem, который пуст. Хотелось >> бы услышать комментарии мейнтейнера, зачем он такой? > > /etc/nut/upsd.pem -- это не пустой файл, а ссылка на пустой файл > /var/lib/nut/etc/nut/upsd.pem, который является местом для приватного > ключа и сертификата, которые может создать администратор сервера upsd для > того чтобы клиенты могли его аутентифицировать; аналог файлов > /etc/httpd/conf/ssl/server.* из пакета mod_ssl с тем отличием, > что ключ и сертификат с пакетом не поставляется. Вообще, есть желание как-то зафиксировать и тут ситуацию. У нас есть куча пакетов, таскающих с собой бесполезные (потому как не совпадает hostname), обычно еще и просроченные, примеры сертификатов. Один пакет вот вообще таскает пустой файл под видом файла с сертификатом. Может быть сделать на всех один макрос, который бы генерил свежие самоподписанные сертификаты и проследить, чтобы все его использовали? >> Финальное замечание: рассмотрены были пока только пакеты, которые явно >> несли в себе некие признаки использования openssl, не соответствующего >> policy. Кроме того, нужно просто вручную рассмотреть все пакеты, которые >> зависят от libssl с куда более пристрастной проверкой: внутри каждого из >> них может быть инициализация openssl с использованием наших общих CA или >> без. Во втором случае это предполагается исправлять. >> >> Дополнительный список: > > В этот список попали пакеты, которые из libssl используют только > libcrypto. Такие пакеты рассматривать нет смысла. Согласен. Хотел еще заметить, что в этом списке уже те пакеты, которым хуже точно не будет, т.е. если кто-то из них и раньше не поддерживал CA из общего CA bundle (того же openssl'ного), то он не работал ни раньше, ни теперь, если мы только этот факт не выявим и не исправим. >> elinks >> lftp >> wget > > Эти по умолчанию используют для проверки тот CA bundle, на который настроен > openssl. Сейчас сделаю страничку на wiki, будем там вычеркивать. Вешать на такие пакеты баги нельзя, хотя бы не проверив. Проверять-то просто - взять и с помощью такого пакета приконнектиться к https://heap.altlinux.org или чему-то подобному. -- WBR, GreyCat