[gnutls-devel] GnuTLS 3.6.0 released

[Daniel P. Berrange]

On Wed, Sep 06, 2017 at 01:12:11PM +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote:
> >> We are proud to announce a new GnuTLS release: Version 3.6.0.
> >>
> >> GnuTLS is a modern C library that implements the standard network
> >> security protocol Transport Layer Security (TLS), for use by network
> >> applications.  GnuTLS is developed for GNU/Linux, but works on many
> >> Unix-like systems as well as Windows.
> >>
> >> The GnuTLS library is distributed under the terms of the GNU Lesser
> >> General Public License version 2 (or later).
> >>
> >> The project pages of the library are available at:
> >> http://www.gnutls.org/
> >
> > [snip]
> >
> >> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification
> >>    of certificates signed with SHA1 is now considered insecure and will
> >>    fail, unless flags intended to enable broken algorithms are set. Other uses
> >>    of SHA1 are still allowed. This can be reverted on compile time with the configure
> >>    flag --enable-sha1-support.
> >
> > FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will
> > be generating certs that will never validate, since that API is hardcoded to
> > use SHA1.  This tripped up the libvirt & QEMU test suites which used that API.
> > I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256
> > explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign()
> > to use SHA256 too, or must it stick with SHA1 for backcompat reasons ?
> 
> It is documented as signing with SHA1, so changing will introduce a
> behavioral "breakage", though I am not sure whether it matters in the
> end.
> 
> > If so, it would be worth putting a note in the API docs that any use of
> > gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted.
> 
> The options seem to be:
>  * deprecate the API and force applications specify explicitly a hash
> for signing
>  * Update/break the ABI for 3.6 and make the underlying algorithm used
> to be undefined (i.e., a secure but unspecified one).
> 
> I kind of like the second option, as applications may hard-code a
> digest which will bring the problem back when that hash is broken. Any
> other opinions/options?

Is there any way to let gnutls_x509_crt_sign2() take a system priority
as an alternative to a fixed algorithm ?  That way we can just pass
"@SYSTEM" when generating a cert and be confident that gnutls will pick
an algorithm that works when a session is set to use "@SYSTEM" priority
string too.


> PS. I have still not managed to run the libvirt and openconnect test
> suites under CI. gitlab runners for some reason cannot detect errors
> from fedpkg and a failing build is detected as successful. I'd
> appreciate any help on that item.
> https://gitlab.com/gnutls/gnutls/merge_requests/477
> https://gitlab.com/gnutls/gnutls/-/jobs/29756798

Perhaps it is confused by having multiple entries in the script:
block. Does it work if you just chain them all together in a single
command. eg

make && make install && fedpkg-wrapper apps/libvirt && ....


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|