Should we settle on one SSL implementation?

[Daniel P. Berrange]

On Tue, Oct 23, 2007 at 04:05:05PM +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?
> 
> Why doesn't the bug mention that it's a sha1 or md5 being used that
> would need porting rather than mentioning "security" libraries?
> 
> glib will soon get SHA1/MD5 as well[1], which is useful when this
> functionality is used in GTK+/GNOME applications. Will glib have to
> depend on NSS?

Well for that matter GLibC itself has MD5 in it....

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|