On Wed, Sep 6, 2017 at 1:28 PM, Daniel P. Berrange <[email protected]> wrote: > 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 <[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? > > 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.
The @SYSTEM applies to TLS sessions only, and there is nothing similar to global configuration for non-TLS functionality. >> 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 && .... I've pushed a version like that: https://gitlab.com/gnutls/gnutls/-/jobs/31497850 regards, Nikos _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
