libgnutls-openssl and real openssl conflict

[Daniel P. Berrange]

On Thu, Aug 28, 2008 at 08:54:16PM -0700, John Poelstra wrote:
> Toshio Kuratomi wrote:
> >Hans de Goede wrote:
> >>
> >>Still we need to tackle this before it does become a bigger problem, 
> >>sofar I've seen very little attention for this thread, which is sad as 
> >>this is a *real* issue. So far only gkrellm seems to have been used by 
> >>people who also use nss_ldap, but sooner or later slrn or one of the 
> >>others will hit the same problem, and if more and more apps are moved 
> >>to these openssl compat libs then the problem becomes really large!
> >>
> >
> >Especially since Fedora is supposed to drive adoption of nss and the nss 
> >compat libs to aid in FIPS-140 compliance for downstream distros, this 
> >problem will only get bigger.

The NSS port would be much more compelling if people talked more about
the benefits of the work to Fedora users. With my (non-Red Hat) community
member hat on, the choice of development work to save commercial distros 
money on  FIPS certification  vs. fixing bugs that matter to Fedora users
is an easy one to make. That said I know there are end user benefits to 
having everything use NSS - people should talk about them instead of FIPS.

> Is there a concerted effort or SIG around this in Fedora?  I've been 
> seeing a lot of the associated bugs attached to this tracker 
> https://bugzilla.redhat.com/showdependencytree.cgi?id=333741&hide_resolved=1
>  as I triage NEW rawhide bugs.

That bug list doesn't demonstrate much success in the 'port everything
to NSS' plan. A handful fixed, 140 bugs being more or less ignored, and
another 50 marked CLOSED -> WONTFIX/NOTABUG. And that's not even counting
the packages that are missing from that list - for example I see that 
libvirt, qemu, kvm, xen, and gtk-vnc are absent from that list, yet all
are using either OpenSSL, or GNU TLS or both. 

That aside though, Fedora package maintainers shouldn't be in the business 
of re-writing large chunks of crypto code in applications, unless they
themselves are the upstream maintainer of said crypto code too. Even then
such work should be done upstream for sake of peer review, and not in
patches to Fedora RPMs. When you have distro code diverging from upstream 
in any area, the package maintainability will often suffer. In the area of
crypto though, it is just plain dangerous and very bad things can & will 
happen, even from trivial 1-liner patches as Debian recently found out 
with the unfortunate RNG bugs.

Fedora's role in this should be one of 'co-ordinator' - generating reports 
to track progress; identifying high priority apps to be ported; advising 
and communicating with upstream and testing any work they produce - all 
the things Fedora excels at. Filing bugs telling Fedora package maintainers
to do the development work to port apps is the wrong way to address this.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|