[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Should we settle on one SSL implementation?



On Tue, 2007-10-23 at 16:05 +0100, Bastien Nocera wrote:
> On Tue, 2007-10-23 at 16:42 +0200, Tomas Mraz wrote:
> > On Tue, 2007-10-23 at 15:38 +0100, Daniel P. Berrange wrote:
> > > On Tue, Oct 23, 2007 at 02:13:18PM +0000, seth vidal wrote:
> > > > 
> > > > On Tue, 2007-10-23 at 09:11 -0500, Rex Dieter wrote:
> > > > > John Dennis wrote:
> > > > > 
> > > > > > So why did Peter Vrabec open bugs against a slew of packages a few hours
> > > > > > ago all with the summary:
> > > > > > 
> > > > > > "Port XXX to use NSS library for cryptography"
> > > > > > 
> > > > > > I haven't seen a consensus this how package maintainers should be
> > > > > > spending their time.
> > > > > 
> > > > > I'm assuming those bugs are mostly for tracking purposes.
> > > > > 
> > > > 
> > > > and a lot of them are wrong.
> > > 
> > > Yep, this is just creating yet bug triage work for maintainers. When entering
> > > tickets one could at least check the app in question to see if it actually
> > > uses the crypto libraries we're being told to remove. Not useful.
> > Not only crypto libraries but built-in code as well. I have checked that
> > the packages actually contain the code. I hardly could in reasonable
> > time check whether the code is always used and so on. I'd expect some
> > help from maintainers in these corner cases.
> 
> The problem I have with the bugs is the description. Most of my packages
> don't use "security" or encryption libraries. But they will have md5 or
> sha1 implementations. Do we really expect libraries with barely any
> dependencies to drag in NSS to do md5 or sha1?

It does seem that we should look at and solve the SSL part of this
problem first, even to the detriment of leaving part of a package's
migration to NSS incomplete, before going after each and every call of
md5().  

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]