On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange <[email protected]> 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? regards, Nikos 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
