[gnutls-devel] GnuTLS 3.6.0 released

[Nikos Mavrogiannopoulos]

On Wed, Sep 6, 2017 at 1:28 PM, Daniel P. Berrange <berrange at redhat.com> 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 <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.

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