From cloos at jhcloos.com  Sat May  6 18:41:11 2017
From: cloos at jhcloos.com (James Cloos)
Date: Sat, 06 May 2017 12:41:11 -0400
Subject: [gnutls-devel] gnutls-cli vs service name
Message-ID: <m3mvaq0wgo.fsf@carbon.jhcloos.org>

I tried to use gnutls-cli to test out my xmpp server, but was unable to
do so because the --starttls-proto=xmpp support uses the server name in
the jabber:client bit of xml rather than a service name.

And the server vs service issue is more generic.  All of the SRV protos
of course require supplying both service and server, but even https can
need both, such as when testing a new server before switching the A RRs.

How do you feel about a --service-name option?  Or maybe just --service?

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From nmav at gnutls.org  Sun May  7 03:03:08 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 7 May 2017 03:03:08 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
Message-ID: <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>

On Sat, May 6, 2017 at 6:41 PM, James Cloos <cloos at jhcloos.com> wrote:
> I tried to use gnutls-cli to test out my xmpp server, but was unable to
> do so because the --starttls-proto=xmpp support uses the server name in
> the jabber:client bit of xml rather than a service name.
>
> And the server vs service issue is more generic.  All of the SRV protos
> of course require supplying both service and server, but even https can
> need both, such as when testing a new server before switching the A RRs.
>
> How do you feel about a --service-name option?  Or maybe just --service?

Would that be useful on any other option than xmpp? If it is only
related with xmpp, would the option of using
--starttls-proto=xmpp:service work?

regards,
Nikos


From thomas2.klute at uni-dortmund.de  Sun May  7 12:40:00 2017
From: thomas2.klute at uni-dortmund.de (Thomas Klute)
Date: Sun, 7 May 2017 12:40:00 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
Message-ID: <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>

Am 07.05.2017 um 03:03 schrieb Nikos Mavrogiannopoulos:
> On Sat, May 6, 2017 at 6:41 PM, James Cloos <cloos at jhcloos.com> wrote:
>> I tried to use gnutls-cli to test out my xmpp server, but was unable to
>> do so because the --starttls-proto=xmpp support uses the server name in
>> the jabber:client bit of xml rather than a service name.
>>
>> And the server vs service issue is more generic.  All of the SRV protos
>> of course require supplying both service and server, but even https can
>> need both, such as when testing a new server before switching the A RRs.
>>
>> How do you feel about a --service-name option?  Or maybe just --service?
> 
> Would that be useful on any other option than xmpp? If it is only
> related with xmpp, would the option of using
> --starttls-proto=xmpp:service work?

I don't use gnutls-cli with STARTTLS, I but would like to have a similar
feature to set the host name for SNI, e.g. for testing HTTPS servers
with name based virtual hosts. If I want to test such a server at the
moment, I have to make sure that gnutls-cli can actually resolve the
virtual host names I want to use in a way that points to the test
system. Something like

  gnutls-cli --sni-host=test.example.com -p 443 ::1

would be very helpful.

Regards,
Thomas


From cloos at jhcloos.com  Sun May  7 17:05:38 2017
From: cloos at jhcloos.com (James Cloos)
Date: Sun, 07 May 2017 11:05:38 -0400
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Sun, 7 May 2017 03:03:08
 +0200")
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
Message-ID: <m360hc1zct.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

JC>> I tried to use gnutls-cli to test out my xmpp server, but was unable to
JC>> do so because the --starttls-proto=xmpp support uses the server name in
JC>> the jabber:client bit of xml rather than a service name.

JC>> And the server vs service issue is more generic.  All of the SRV protos
JC>> of course require supplying both service and server, but even https can
JC>> need both, such as when testing a new server before switching the A RRs.

JC>> How do you feel about a --service-name option?  Or maybe just --service?

NM> Would that be useful on any other option than xmpp? If it is only
NM> related with xmpp, would the option of using
NM> --starttls-proto=xmpp:service work?

I see startls support for sip is missing (as are postgres and rfc2817),
so for now xmpp is the only SRV protocol.  But as I (and a followup)
mentioned, there are times when one needs to pass a different name for
tls than one needs for dns.

For xmpp, --starttls-proto=xmpp:service is enough.

But a more general option remains welcome.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From nmav at gnutls.org  Mon May  8 06:55:48 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 08 May 2017 06:55:48 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <m360hc1zct.fsf@carbon.jhcloos.org>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <m360hc1zct.fsf@carbon.jhcloos.org>
Message-ID: <1494219348.25191.2.camel@gnutls.org>

On Sun, 2017-05-07 at 11:05 -0400, James Cloos wrote:
> > > > > > "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> JC>> I tried to use gnutls-cli to test out my xmpp server, but was
> unable to
> JC>> do so because the --starttls-proto=xmpp support uses the server
> name in
> JC>> the jabber:client bit of xml rather than a service name.
> 
> JC>> And the server vs service issue is more generic.??All of the SRV
> protos
> JC>> of course require supplying both service and server, but even
> https can
> JC>> need both, such as when testing a new server before switching
> the A RRs.
> 
> JC>> How do you feel about a --service-name option???Or maybe just --
> service?
> 
> NM> Would that be useful on any other option than xmpp? If it is only
> NM> related with xmpp, would the option of using
> NM> --starttls-proto=xmpp:service work?
> 
> I see startls support for sip is missing (as are postgres and
> rfc2817),
> so for now xmpp is the only SRV protocol.??But as I (and a followup)
> mentioned, there are times when one needs to pass a different name
> for
> tls than one needs for dns.
> 
> For xmpp, --starttls-proto=xmpp:service is enough.
> 
> But a more general option remains welcome.

I do not see much connection between SNI and SRV. How do you see the
general option? Would you like to propose one via a merge request?

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Mon May  8 06:57:59 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 08 May 2017 06:57:59 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
Message-ID: <1494219479.25191.3.camel@gmail.com>

On Sun, 2017-05-07 at 12:40 +0200, Thomas Klute wrote:
> Am 07.05.2017 um 03:03 schrieb Nikos Mavrogiannopoulos:
> > On Sat, May 6, 2017 at 6:41 PM, James Cloos <cloos at jhcloos.com>
> > wrote:
> > > I tried to use gnutls-cli to test out my xmpp server, but was
> > > unable to
> > > do so because the --starttls-proto=xmpp support uses the server
> > > name in
> > > the jabber:client bit of xml rather than a service name.
> > > 
> > > And the server vs service issue is more generic.??All of the SRV
> > > protos
> > > of course require supplying both service and server, but even
> > > https can
> > > need both, such as when testing a new server before switching the
> > > A RRs.
> > > 
> > > How do you feel about a --service-name option???Or maybe just --
> > > service?
> > 
> > Would that be useful on any other option than xmpp? If it is only
> > related with xmpp, would the option of using
> > --starttls-proto=xmpp:service work?
> 
> I don't use gnutls-cli with STARTTLS, I but would like to have a
> similar
> feature to set the host name for SNI, e.g. for testing HTTPS servers
> with name based virtual hosts. If I want to test such a server at the
> moment, I have to make sure that gnutls-cli can actually resolve the
> virtual host names I want to use in a way that points to the test
> system. Something like
> 
> ? gnutls-cli --sni-host=test.example.com -p 443 ::1
> 
> would be very helpful.

Right. I thought gnutls-cli had such an option but I mistook it for the
option in gnutls-serv.

An option like that seems trivial to add so I've made a merge request
at [0], however, I'll wait in case Jim has a better option that can
merge both SNI and SRV.

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/merge_requests/377



From cloos at jhcloos.com  Mon May  8 19:38:33 2017
From: cloos at jhcloos.com (James Cloos)
Date: Mon, 08 May 2017 13:38:33 -0400
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <1494219479.25191.3.camel@gmail.com> (Nikos Mavrogiannopoulos's
 message of "Mon, 08 May 2017 06:57:59 +0200")
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
 <1494219479.25191.3.camel@gmail.com>
Message-ID: <m3pofjuu3q.fsf@carbon.jhcloos.org>

The starttls support can be done on top of that pull.

All it needs is to use OPT_ARG(SNI_HOSTNAME) instead of socket->hostname
when HAVE_OPT(SNI_HOSTNAME).  And only smtp, lmtp and xmpp use that.

I'm not sure of the best way to pass OPT_ARG(SNI_HOSTNAME) to socket_open()
and on to socket_starttls().  Would another const char* and another FLAG
work?  Or just a const char* which is ignored if NULL?

(Inclidently, my earlier note of missing pg support was daft.  It is not
mentioned in the man page, but seeing it in the code reminds me that it
was announced some time back, and I thing I congradulated that announce.)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From n.mavrogiannopoulos at gmail.com  Mon May  8 21:23:56 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 8 May 2017 21:23:56 +0200
Subject: [gnutls-devel] oss-fuzz and gnutls
Message-ID: <CAJU7zaJyXEdN6DsKXJFU8gbzgQkpfwjC4e6BrZwFXDZYXFp+Mg@mail.gmail.com>

Hi,
 Few months ago Alex Gaynor created the first fuzzers for gnutls client
and server and submitted them in Google's oss-fuzz. Since then more
fuzzers have been added by Alex and me and some formal rules followed
in [0]. That qualified the initial integration definition of Google [1]
and a 1000$ reward was received, and forwarded to Alex for introducing
that support in gnutls. Thank you Alex!

[0]. https://gitlab.com/gnutls/gnutls/blob/master/devel/fuzz/README.md
[1]. https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html


From n.mavrogiannopoulos at gmail.com  Tue May  9 14:48:08 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 9 May 2017 14:48:08 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
Message-ID: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>

Hi,
 gnutls 3.5.x is more strict in certificate decoding and performs
various checks in the Time fields to ensure they are properly DER
formatted. However, it is seems that this caused regressions with
certain certificates generated by ovirt as seen in [0]. I am not sure
which software was used to generate the problematic ones, however, it
is most likely openssl, or some other open source software. Are you
aware of other or similar decoding issues which were a result of 3.5.x
being more strict in DER rules?

The options we have are:
 1. Ignore the error and insist on DER correctness in input certificates.
 2. Allow incorrect formatted time fields in certificates
unconditionally, e.g., with a special libtasn1 flag:
https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc

any other option I've missed? While I favor the first for its
simplicity, reality has shown over the years we must yield towards the
'work' part.

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/196


From berrange at redhat.com  Tue May  9 15:04:33 2017
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 9 May 2017 14:04:33 +0100
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
Message-ID: <20170509130433.GI1669@redhat.com>

On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
> Hi,
>  gnutls 3.5.x is more strict in certificate decoding and performs
> various checks in the Time fields to ensure they are properly DER
> formatted. However, it is seems that this caused regressions with
> certain certificates generated by ovirt as seen in [0]. I am not sure
> which software was used to generate the problematic ones, however, it
> is most likely openssl, or some other open source software. Are you
> aware of other or similar decoding issues which were a result of 3.5.x
> being more strict in DER rules?
> 
> The options we have are:
>  1. Ignore the error and insist on DER correctness in input certificates.
>  2. Allow incorrect formatted time fields in certificates
> unconditionally, e.g., with a special libtasn1 flag:
> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
> 
> any other option I've missed? While I favor the first for its
> simplicity, reality has shown over the years we must yield towards the
> 'work' part.

Have you succeeded in getting any contact with oVirt community to find
out how they are generating their certs ? That might give some clarity
on whether it is just a minor bug in their code, vs following common/
wide practice. It isn't clear if it even affects all oVirt users or
just some subset of them, vs likely to affect large numbers of non-oVirt
users too

While being lenient in what you accept has been a good strategy in many
cases, it feels like the web browser vendors in general have changed
tack over the past few years, to favour strictness wrt TLS/x509.

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 :|


From n.mavrogiannopoulos at gmail.com  Tue May  9 20:26:55 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 09 May 2017 20:26:55 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <20170509130433.GI1669@redhat.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509130433.GI1669@redhat.com>
Message-ID: <1494354415.2148.1.camel@gmail.com>

On Tue, 2017-05-09 at 14:04 +0100, Daniel P. Berrange wrote:
> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos
> wrote:
> > Hi,
> > ?gnutls 3.5.x is more strict in certificate decoding and performs
> > various checks in the Time fields to ensure they are properly DER
> > formatted. However, it is seems that this caused regressions with
> > certain certificates generated by ovirt as seen in [0]. I am not
> > sure
> > which software was used to generate the problematic ones, however,
> > it
> > is most likely openssl, or some other open source software. Are you
> > aware of other or similar decoding issues which were a result of
> > 3.5.x
> > being more strict in DER rules?
> > 
> > The options we have are:
> > ?1. Ignore the error and insist on DER correctness in input
> > certificates.
> > ?2. Allow incorrect formatted time fields in certificates
> > unconditionally, e.g., with a special libtasn1 flag:
> > https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b4
> > 6b251ab7484e5dc
> > 
> > any other option I've missed? While I favor the first for its
> > simplicity, reality has shown over the years we must yield towards
> > the
> > 'work' part.
> 
> Have you succeeded in getting any contact with oVirt community to
> find
> out how they are generating their certs ? That might give some
> clarity
> on whether it is just a minor bug in their code, vs following common/
> wide practice. It isn't clear if it even affects all oVirt users or
> just some subset of them, vs likely to affect large numbers of non-
> oVirt users too

Seems like a good point. I wouldn't know where to ask. Any suggestions?

regards,
Nikos



From kurt at roeckx.be  Tue May  9 20:47:10 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 9 May 2017 20:47:10 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
Message-ID: <20170509184709.idwqqb3nmccrclmb@roeckx.be>

On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
> Hi,
>  gnutls 3.5.x is more strict in certificate decoding and performs
> various checks in the Time fields to ensure they are properly DER
> formatted. However, it is seems that this caused regressions with
> certain certificates generated by ovirt as seen in [0]. I am not sure
> which software was used to generate the problematic ones, however, it
> is most likely openssl, or some other open source software. Are you
> aware of other or similar decoding issues which were a result of 3.5.x
> being more strict in DER rules?
> 
> The options we have are:
>  1. Ignore the error and insist on DER correctness in input certificates.
>  2. Allow incorrect formatted time fields in certificates
> unconditionally, e.g., with a special libtasn1 flag:
> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
> 
> any other option I've missed? While I favor the first for its
> simplicity, reality has shown over the years we must yield towards the
> 'work' part.

NSS is strict in what it accepts. We've recently changed openssl to be
more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
https://github.com/openssl/openssl/issues/2620), but maybe not
strict enough yet.

Anyway, as the github issue says, I could only find 35
certificates that chain to the mozilla root store that fail
the most strict check.


Kurt



From n.mavrogiannopoulos at gmail.com  Wed May 10 10:54:43 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 10 May 2017 10:54:43 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <m3pofjuu3q.fsf@carbon.jhcloos.org>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
 <1494219479.25191.3.camel@gmail.com>
 <m3pofjuu3q.fsf@carbon.jhcloos.org>
Message-ID: <CAJU7za+=hZMgVax011hpCH2-=tg_hdhp_3bzuGkvTuuwRoqQ7w@mail.gmail.com>

On Mon, May 8, 2017 at 7:38 PM, James Cloos <cloos at jhcloos.com> wrote:
> The starttls support can be done on top of that pull.
>
> All it needs is to use OPT_ARG(SNI_HOSTNAME) instead of socket->hostname
> when HAVE_OPT(SNI_HOSTNAME).  And only smtp, lmtp and xmpp use that.
>
> I'm not sure of the best way to pass OPT_ARG(SNI_HOSTNAME) to socket_open()
> and on to socket_starttls().  Would another const char* and another FLAG
> work?  Or just a const char* which is ignored if NULL?
> (Inclidently, my earlier note of missing pg support was daft.  It is not
> mentioned in the man page, but seeing it in the code reminds me that it
> was announced some time back, and I thing I congradulated that announce.)

Maybe splitting socket_open() to socket_init() and socket_open() would
allow simplifying that. We can then have:
socket_init()
socket_set_sni_hostname()
socket_open()

and socket_starttls() could read the sni hostname when needed. What do
you think?

regards,
Nikos


From berrange at redhat.com  Wed May 10 11:12:43 2017
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 10 May 2017 10:12:43 +0100
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <1494354415.2148.1.camel@gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509130433.GI1669@redhat.com>
 <1494354415.2148.1.camel@gmail.com>
Message-ID: <20170510091243.GG31558@redhat.com>

On Tue, May 09, 2017 at 08:26:55PM +0200, Nikos Mavrogiannopoulos wrote:
> On Tue, 2017-05-09 at 14:04 +0100, Daniel P. Berrange wrote:
> > On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos
> > wrote:
> > > Hi,
> > > ?gnutls 3.5.x is more strict in certificate decoding and performs
> > > various checks in the Time fields to ensure they are properly DER
> > > formatted. However, it is seems that this caused regressions with
> > > certain certificates generated by ovirt as seen in [0]. I am not
> > > sure
> > > which software was used to generate the problematic ones, however,
> > > it
> > > is most likely openssl, or some other open source software. Are you
> > > aware of other or similar decoding issues which were a result of
> > > 3.5.x
> > > being more strict in DER rules?
> > > 
> > > The options we have are:
> > > ?1. Ignore the error and insist on DER correctness in input
> > > certificates.
> > > ?2. Allow incorrect formatted time fields in certificates
> > > unconditionally, e.g., with a special libtasn1 flag:
> > > https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b4
> > > 6b251ab7484e5dc
> > > 
> > > any other option I've missed? While I favor the first for its
> > > simplicity, reality has shown over the years we must yield towards
> > > the
> > > 'work' part.
> > 
> > Have you succeeded in getting any contact with oVirt community to
> > find
> > out how they are generating their certs ? That might give some
> > clarity
> > on whether it is just a minor bug in their code, vs following common/
> > wide practice. It isn't clear if it even affects all oVirt users or
> > just some subset of them, vs likely to affect large numbers of non-
> > oVirt users too
> 
> Seems like a good point. I wouldn't know where to ask. Any suggestions?

Simplest is probably to ping #ovirt channel on irc.oftc.net  [1]

Regards,
Daniel

[1] https://www.ovirt.org/community/
-- 
|: 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 :|


From n.mavrogiannopoulos at gmail.com  Wed May 10 14:06:42 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 10 May 2017 14:06:42 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <20170509184709.idwqqb3nmccrclmb@roeckx.be>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
Message-ID: <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>

On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  gnutls 3.5.x is more strict in certificate decoding and performs
>> various checks in the Time fields to ensure they are properly DER
>> formatted. However, it is seems that this caused regressions with
>> certain certificates generated by ovirt as seen in [0]. I am not sure
>> which software was used to generate the problematic ones, however, it
>> is most likely openssl, or some other open source software. Are you
>> aware of other or similar decoding issues which were a result of 3.5.x
>> being more strict in DER rules?
>>
>> The options we have are:
>>  1. Ignore the error and insist on DER correctness in input certificates.
>>  2. Allow incorrect formatted time fields in certificates
>> unconditionally, e.g., with a special libtasn1 flag:
>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>>
>> any other option I've missed? While I favor the first for its
>> simplicity, reality has shown over the years we must yield towards the
>> 'work' part.
>
> NSS is strict in what it accepts. We've recently changed openssl to be
> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
> https://github.com/openssl/openssl/issues/2620), but maybe not
> strict enough yet.

Thank you, that is really helpful. It seems that Kurt has found out
the culprit. There seem to be a user input validation issue in openssl
when generating certs:
https://gitlab.com/gnutls/gnutls/issues/196#note_29192381

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Wed May 10 14:07:55 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 10 May 2017 14:07:55 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
Message-ID: <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>

On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>>> Hi,
>>>  gnutls 3.5.x is more strict in certificate decoding and performs
>>> various checks in the Time fields to ensure they are properly DER
>>> formatted. However, it is seems that this caused regressions with
>>> certain certificates generated by ovirt as seen in [0]. I am not sure
>>> which software was used to generate the problematic ones, however, it
>>> is most likely openssl, or some other open source software. Are you
>>> aware of other or similar decoding issues which were a result of 3.5.x
>>> being more strict in DER rules?
>>>
>>> The options we have are:
>>>  1. Ignore the error and insist on DER correctness in input certificates.
>>>  2. Allow incorrect formatted time fields in certificates
>>> unconditionally, e.g., with a special libtasn1 flag:
>>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>>>
>>> any other option I've missed? While I favor the first for its
>>> simplicity, reality has shown over the years we must yield towards the
>>> 'work' part.
>>
>> NSS is strict in what it accepts. We've recently changed openssl to be
>> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
>> https://github.com/openssl/openssl/issues/2620), but maybe not
>> strict enough yet.
>
> Thank you, that is really helpful. It seems that Kurt

Sorry, I meant to write Tim here!

regards,
Nikos


From nmav at gnutls.org  Thu May 11 07:53:21 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 11 May 2017 07:53:21 +0200
Subject: [gnutls-devel] gnutls 3.5.12
Message-ID: <1494482001.29735.1.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.5.12. This is a bug fix release on the
3.5.x branch.

* Version 3.5.12 (released 2017-05-11)

** libgnutls: enabled TCP Fast open for MacOSX. Patch by Tim Ruehsen.

** libgnutls: gnutls_x509_crt_check_hostname2() no longer matches IP
   addresses against DNS fields of certificate (CN or DNSname). The
   previous behavior?was to tolerate some misconfigured servers, but
   that was non-standard?and skipped any IP constraints present in
   higher level certificates.

** libgnutls: when converting to IDNA2008, fallback to IDNA2003 (i.e.,
   transitional?encoding) if the domain cannot be converted. That
   provides maximum compatibility?with browsers like firefox that
   perform the same conversion.

** libgnutls: fix issue in RSA-PSK client callback which resulted in no
   username?being sent to the peer. Patch by Nicolas Dufresne.

** libgnutls: fix regression causing stapled extensions in trust
   modules not?to be considered.

** certtool: introduced the email_protection_key option.??This option
   was introduced?in documentation for certtool without an
   implementation of it. It is a shortcut for option
   'key_purpose_oid =?1.3.6.1.5.5.7.3.4'.

** certtool: made printing of key ID and key PIN consistent between
   certificates,?public keys, and private keys. That is the private
   key printing now uses the?same format as the rest.

** gnutls-cli: introduced the --sni-hostname option. This allows?
   overriding the hostname advertised to the peer.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.??A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ compressed sources:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.12.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.12.tar.xz.sig

Note that it has been signed with my openpgp key:
pub???3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid??????????????????Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid??????????????????Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From kurt at roeckx.be  Thu May 11 18:46:32 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 11 May 2017 18:46:32 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
 <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
Message-ID: <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>

On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
> <n.mavrogiannopoulos at gmail.com> wrote:
> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> >> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
> >>> Hi,
> >>>  gnutls 3.5.x is more strict in certificate decoding and performs
> >>> various checks in the Time fields to ensure they are properly DER
> >>> formatted. However, it is seems that this caused regressions with
> >>> certain certificates generated by ovirt as seen in [0]. I am not sure
> >>> which software was used to generate the problematic ones, however, it
> >>> is most likely openssl, or some other open source software. Are you
> >>> aware of other or similar decoding issues which were a result of 3.5.x
> >>> being more strict in DER rules?
> >>>
> >>> The options we have are:
> >>>  1. Ignore the error and insist on DER correctness in input certificates.
> >>>  2. Allow incorrect formatted time fields in certificates
> >>> unconditionally, e.g., with a special libtasn1 flag:
> >>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
> >>>
> >>> any other option I've missed? While I favor the first for its
> >>> simplicity, reality has shown over the years we must yield towards the
> >>> 'work' part.
> >>
> >> NSS is strict in what it accepts. We've recently changed openssl to be
> >> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
> >> https://github.com/openssl/openssl/issues/2620), but maybe not
> >> strict enough yet.
> >
> > Thank you, that is really helpful. It seems that Kurt
> 
> Sorry, I meant to write Tim here!

And today someone filed this in Debian:
https://bugs.debian.org/862335


Kurt



From ametzler at bebt.de  Thu May 11 19:49:07 2017
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 11 May 2017 19:49:07 +0200
Subject: [gnutls-devel] gnutls 3.5.12 does not run pgp test due to typo
Message-ID: <20170511174907.trt655xhfw3rtnu2@argenau.bebt.de>

Hello,

there is a typo in d0c241dca5cbdf60dbc7c930046280d5b2088787. It checks
for ENABLED_OPENPGP instead of ENABLE_OPENPGP.

diff --git a/tests/openpgp-callback.c b/tests/openpgp-callback.c
index 3df10aca4..cdf90cd60 100644
--- a/tests/openpgp-callback.c
+++ b/tests/openpgp-callback.c
@@ -27,7 +27,7 @@
 #include <stdio.h>
 #include <stdlib.h>

-#if defined(_WIN32) || !defined(ENABLED_OPENPGP)
+#if defined(_WIN32) || !defined(ENABLE_OPENPGP)

 /* socketpair isn't supported on Win32. */
 int main(int argc, char **argv)


And while we are at it "convertions" in lib/x509/x509_dn.c should read
"conversions".

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Thu May 11 22:03:54 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 11 May 2017 22:03:54 +0200
Subject: [gnutls-devel] gnutls 3.5.12 does not run pgp test due to typo
In-Reply-To: <20170511174907.trt655xhfw3rtnu2@argenau.bebt.de>
References: <20170511174907.trt655xhfw3rtnu2@argenau.bebt.de>
Message-ID: <CAJU7zaLmA6i+5v2hApSmOJXz4gyxLhmc2Ccw=rLA9_UUiHp2Lg@mail.gmail.com>

On Thu, May 11, 2017 at 7:49 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
>
> there is a typo in d0c241dca5cbdf60dbc7c930046280d5b2088787. It checks
> for ENABLED_OPENPGP instead of ENABLE_OPENPGP.
>
> diff --git a/tests/openpgp-callback.c b/tests/openpgp-callback.c
> index 3df10aca4..cdf90cd60 100644
> --- a/tests/openpgp-callback.c
> +++ b/tests/openpgp-callback.c
> @@ -27,7 +27,7 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>
> -#if defined(_WIN32) || !defined(ENABLED_OPENPGP)
> +#if defined(_WIN32) || !defined(ENABLE_OPENPGP)
>
>  /* socketpair isn't supported on Win32. */
>  int main(int argc, char **argv)
>
>
> And while we are at it "convertions" in lib/x509/x509_dn.c should read
> "conversions".

Thank you! Both committed.


From nmav at gnutls.org  Sun May 14 09:43:21 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 14 May 2017 09:43:21 +0200
Subject: [gnutls-devel] [gnutls-help] the problem about "stream usage"
 in dtls/sctp
In-Reply-To: <CAJM8vyjJivu=kHOcZ6CrwkDRhs0=8jCuw1W_2XaBO+2aSwZCNQ@mail.gmail.com>
References: <CAJM8vyjJivu=kHOcZ6CrwkDRhs0=8jCuw1W_2XaBO+2aSwZCNQ@mail.gmail.com>
Message-ID: <1494747801.2134.2.camel@gnutls.org>

On Thu, 2017-05-11 at 23:26 +0800, Wei Cheng wrote:
> hi,guys!
> 
> i have read the rfc6083 which ?describes the usage of the Datagram
> Transport Layer Security (DTLS) protocol over the Stream Control
> Transmission Protocol (SCTP).
> 
> "stream usage " is as follows:
> 4.4.? Stream Usage
> ? ?All DTLS messages of the ChangeCipherSpec, Alert, or Handshake
> ? ?protocol MUST be transported on stream 0 with unlimited
> reliability
> ? ?and with the ordered delivery feature.
> ? ?DTLS messages of the ApplicationData protocol SHOULD use multiple
> ? ?streams other than stream 0; they MAY use stream 0 for everything
> if
> ? ?they do not care about minimizing head of line blocking.
> 
> 
> i write a push_function .like that:
> static ssize_t push_func(gnutls_transport_ptr_t p, const void *data,
> size_t size)
> {
> ? ? priv_data_st *priv = p;
> ? ? int ret;
> ? ? // ?i sent msg on stream #0
> ? ? ret = sctp_sendmsg(priv->fd, data,size ,NULL, 0,0, 0,0, 0,0);
> ? ? if (ret < 0)
> ? ? ? ? ?printf("fail to sent msg \n");
> ? ? ?else
> ? ? ? ? ?printf("success to sent msg in push\n");
> ? ? ?return ret;
> }
> 
> i use gnutls_transpoet_set_push_fnuction to register my push
> function,
> so that all message would be sent by my push_function.
> i want to sent alert,handshake,changesuite on stream #0, while
> appilcaiton data is sent on others streams.
> in push_function,all data is already encryped,
> how i can distinguish which kind of msg it is ?
> how should i write my push_function??
> i doubt that i am wrong in this part.

Given that you are in DTLS, the data you receive in the push function
are a complete record message. Thus you can check the ContentType field
of the record message (first byte) to determine the type.

The API however was designed for TCP/UDP and although there are few
instructions at [1], I'm not happy with that. We need simpler functions
to handle SCTP. If you or anyone else has a good proposal for extending
gnutls (new push/pull functions and/or a wrapper for
gnutls_transport_set_fastopen) for it I'd say go for it and open a
merge request. There was an example for TLS over SCTP several years
ago, but we most likely need a much simpler version of it for DTLS.


[0]. https://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00009.html
[1]. https://www.gnutls.org/manual/html_node/DTLS-and-SCTP.html

regards,
Nikos



From ametzler at bebt.de  Sun May 14 11:28:14 2017
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 14 May 2017 11:28:14 +0200
Subject: [gnutls-devel] [Patch] Incorrect autoconf progress message
Message-ID: <20170514092814.sp3sq5ochafelucu@argenau.bebt.de>

Hello,

the progress message for heartbeat does not match the yes/no outcome:

./configure --disable-heartbeat-support 
[...]
checking whether to disable TLS heartbeat support... no
[...]
  Heartbeat support:    no
----------------
./configure 
[...]
checking whether to disable TLS heartbeat support... yes
[...]
 Heartbeat support:    yes

Trivial patch attached.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-autoconf-progress-message-concerning-heartbeat.patch
Type: text/x-diff
Size: 827 bytes
Desc: not available
URL: </pipermail/attachments/20170514/6d17728c/attachment.patch>

From nmav at gnutls.org  Sun May 14 14:54:50 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 14 May 2017 14:54:50 +0200
Subject: [gnutls-devel] [Patch] Incorrect autoconf progress message
In-Reply-To: <20170514092814.sp3sq5ochafelucu@argenau.bebt.de>
References: <20170514092814.sp3sq5ochafelucu@argenau.bebt.de>
Message-ID: <1494766490.1974.0.camel@gnutls.org>

On Sun, 2017-05-14 at 11:28 +0200, Andreas Metzler wrote:
> Hello,
> 
> the progress message for heartbeat does not match the yes/no outcome:
> 
> ./configure --disable-heartbeat-support?
> [...]
> checking whether to disable TLS heartbeat support... no
> [...]
> ? Heartbeat support:????no
> ----------------
> ./configure?
> [...]
> checking whether to disable TLS heartbeat support... yes
> [...]
> ?Heartbeat support:????yes
> 
> Trivial patch attached.
> 

Applied, thank you.



From nmav at gnutls.org  Sun May 14 14:59:46 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 14 May 2017 14:59:46 +0200
Subject: [gnutls-devel] [gnutls-help] the problem about "stream usage"
 in dtls/sctp
In-Reply-To: <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org>
References: <CAJM8vyjJivu=kHOcZ6CrwkDRhs0=8jCuw1W_2XaBO+2aSwZCNQ@mail.gmail.com>
 <1494747801.2134.2.camel@gnutls.org>
 <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org>
Message-ID: <1494766786.1974.2.camel@gnutls.org>

On Sun, 2017-05-14 at 13:05 +0100, Jeremy Harris wrote:
> On 14/05/17 08:43, Nikos Mavrogiannopoulos wrote:
> > The API however was designed for TCP/UDP and although there are few
> > instructions at [1], I'm not happy with that. We need simpler
> > functions
> > to handle SCTP.
> 
> Somewhat related
> 
> - the equivalent of send( , , , MSG_MORE).??I could do it with a push
> ? function, but that's just more hassle and I'd only be using it for
> ? my application protocol startup sequence anyway.

You can use the gnutls_record_cork() and uncork functions for that.
Would that work for you, or did I miss the context?

> - would there be any benefit in a sendfile() equivalent???I assume
> not
> ? for a userland/cpu driven session encryption engine - but are there
> ? any hardware engine implementations?

There is AF_KTLS [0] which can work with gnutls and can be used to
achieve sendfile-like functionality. However I do not know whether
something like that would ever reach mainline linux kernel. What
functionality/optimization do you have in mind?

[0]. https://github.com/ktls/af_ktls

regards,
Nikos



From jgh at wizmail.org  Sun May 14 15:28:17 2017
From: jgh at wizmail.org (Jeremy Harris)
Date: Sun, 14 May 2017 14:28:17 +0100
Subject: [gnutls-devel] [gnutls-help] the problem about "stream usage"
 in dtls/sctp
In-Reply-To: <1494766786.1974.2.camel@gnutls.org>
References: <CAJM8vyjJivu=kHOcZ6CrwkDRhs0=8jCuw1W_2XaBO+2aSwZCNQ@mail.gmail.com>
 <1494747801.2134.2.camel@gnutls.org>
 <6e36544c-cb67-ddf1-0d11-8ce6b3d5ed16@wizmail.org>
 <1494766786.1974.2.camel@gnutls.org>
Message-ID: <51cdd570-4b9a-ab06-e50f-08ce99976006@wizmail.org>

On 14/05/17 13:59, Nikos Mavrogiannopoulos wrote:
>> - the equivalent of send( , , , MSG_MORE).  I could do it with a push
>>   function, but that's just more hassle and I'd only be using it for
>>   my application protocol startup sequence anyway.
> 
> You can use the gnutls_record_cork() and uncork functions for that.
> Would that work for you, or did I miss the context?

They would work, but might mean I need to carry more state around.
I assume they're cheap calls?
Is uncork safe to call if cork has never been used?

>> - would there be any benefit in a sendfile() equivalent?  I assume
>> not
>>   for a userland/cpu driven session encryption engine - but are there
>>   any hardware engine implementations?
> 
> There is AF_KTLS [0] which can work with gnutls and can be used to
> achieve sendfile-like functionality. However I do not know whether
> something like that would ever reach mainline linux kernel. What
> functionality/optimization do you have in mind?

Hand it an fd and a TLS-context handle; copies data from the fd
and sends it down the TLS channel - using fewer syscalls and/or
expensive tls-library calls than an application loop: read,write,
and fewer bulk-data copies.

Bonus features are:
a) data size limit
b) starting seek-point in the source
c) support for non-seekable source fds   [ excluding (b) ]

-- 
Cheers,
  Jeremy


From andreas.radke at mailbox.org  Sun May 14 20:23:44 2017
From: andreas.radke at mailbox.org (Andreas Radke)
Date: Sun, 14 May 2017 20:23:44 +0200
Subject: [gnutls-devel] gnutls 3.5.12
In-Reply-To: <1494482001.29735.1.camel@gnutls.org>
References: <1494482001.29735.1.camel@gnutls.org>
Message-ID: <20170514202344.03e30994@laptop64.home>

The new release fails to build in tests here:

  CC       trust-store.o
trust-store.c: In function 'doit':
trust-store.c:50:2: warning: implicit declaration of function 'gnutls_gnutls_global_init' [-Wimplicit-function-declaration]
  gnutls_gnutls_global_init();
  ^~~~~~~~~~~~~~~~~~~~~~~~~
trust-store.c:50:2: warning: nested extern declaration of 'gnutls_gnutls_global_init' [-Wnested-externs]
  CCLD     trust-store
trust-store.o: In function `doit':
trust-store.c:(.text+0x35): undefined reference to `gnutls_gnutls_global_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:4704: trust-store] Error 1
make[3]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
make[2]: *** [Makefile:7471: check-am] Error 2
make[2]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
make[1]: *** [Makefile:5228: check-recursive] Error 1
make[1]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
make: *** [Makefile:1463: check-recursive] Error 1
==> ERROR: A failure occurred in check().


Is this known? Do you have a fix? Latest git commits don't seem to be related.

-Andy
Arch Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170514/96cf3b17/attachment.sig>

From nmav at gnutls.org  Mon May 15 07:52:53 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 15 May 2017 07:52:53 +0200
Subject: [gnutls-devel] gnutls 3.5.12
In-Reply-To: <20170514202344.03e30994@laptop64.home>
References: <1494482001.29735.1.camel@gnutls.org>
 <20170514202344.03e30994@laptop64.home>
Message-ID: <CAJU7zaJR6S3OLDUXe4_=qOzox5SStAiCRhqYOKsiZTbqJ1ab9w@mail.gmail.com>

On Sun, May 14, 2017 at 8:23 PM, Andreas Radke
<andreas.radke at mailbox.org> wrote:
> The new release fails to build in tests here:
>
>   CC       trust-store.o
> trust-store.c: In function 'doit':
> trust-store.c:50:2: warning: implicit declaration of function 'gnutls_gnutls_global_init' [-Wimplicit-function-declaration]
>   gnutls_gnutls_global_init();
>   ^~~~~~~~~~~~~~~~~~~~~~~~~
> trust-store.c:50:2: warning: nested extern declaration of 'gnutls_gnutls_global_init' [-Wnested-externs]
>   CCLD     trust-store
> trust-store.o: In function `doit':
> trust-store.c:(.text+0x35): undefined reference to `gnutls_gnutls_global_init'
> collect2: error: ld returned 1 exit status
> make[3]: *** [Makefile:4704: trust-store] Error 1
> make[3]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
> make[2]: *** [Makefile:7471: check-am] Error 2
> make[2]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
> make[1]: *** [Makefile:5228: check-recursive] Error 1
> make[1]: Leaving directory '/build/gnutls/src/gnutls-3.5.12/tests'
> make: *** [Makefile:1463: check-recursive] Error 1
> ==> ERROR: A failure occurred in check().
> Is this known? Do you have a fix? Latest git commits don't seem to be related.

Hi,
 Could it be that you kept the patch to work around the issue in the
test last month?

regards,
Nikos


From cloos at jhcloos.com  Tue May 16 22:31:02 2017
From: cloos at jhcloos.com (James Cloos)
Date: Tue, 16 May 2017 16:31:02 -0400
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <CAJU7za+=hZMgVax011hpCH2-=tg_hdhp_3bzuGkvTuuwRoqQ7w@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Wed, 10 May 2017 10:54:43
 +0200")
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
 <1494219479.25191.3.camel@gmail.com>
 <m3pofjuu3q.fsf@carbon.jhcloos.org>
 <CAJU7za+=hZMgVax011hpCH2-=tg_hdhp_3bzuGkvTuuwRoqQ7w@mail.gmail.com>
Message-ID: <m3pof8mtmh.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

NM> Maybe splitting socket_open() to socket_init() and socket_open() would
NM> allow simplifying that. We can then have:
NM> socket_init()
NM> socket_set_sni_hostname()
NM> socket_open()

Did I reply to this?  If not, I like that.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From n.mavrogiannopoulos at gmail.com  Wed May 17 11:21:46 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 17 May 2017 11:21:46 +0200
Subject: [gnutls-devel] gnutls-cli vs service name
In-Reply-To: <m3pof8mtmh.fsf@carbon.jhcloos.org>
References: <m3mvaq0wgo.fsf@carbon.jhcloos.org>
 <CAJU7zaKmajLd+UYe-rrLGV7aeJjHWSnN4YcWKYhNt0tvwdtcOg@mail.gmail.com>
 <4f538c2d-f3ff-f158-35fd-4d85e59f9835@uni-dortmund.de>
 <1494219479.25191.3.camel@gmail.com>
 <m3pofjuu3q.fsf@carbon.jhcloos.org>
 <CAJU7za+=hZMgVax011hpCH2-=tg_hdhp_3bzuGkvTuuwRoqQ7w@mail.gmail.com>
 <m3pof8mtmh.fsf@carbon.jhcloos.org>
Message-ID: <CAJU7zaKRkdm5XJpFN--e3J52VqbvH-C8mS-AgV0sHst+rFFULw@mail.gmail.com>

On Tue, May 16, 2017 at 10:31 PM, James Cloos <cloos at jhcloos.com> wrote:
>>>>>> "NM" == Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:
>
> NM> Maybe splitting socket_open() to socket_init() and socket_open() would
> NM> allow simplifying that. We can then have:
> NM> socket_init()
> NM> socket_set_sni_hostname()
> NM> socket_open()
>
> Did I reply to this?  If not, I like that.

Thanks. Could you submit an MR with that change?


From n.mavrogiannopoulos at gmail.com  Mon May 29 09:53:26 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 29 May 2017 09:53:26 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
 <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
 <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>
Message-ID: <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>

On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
>> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
>> <n.mavrogiannopoulos at gmail.com> wrote:
>> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> >> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>> >>> Hi,
>> >>>  gnutls 3.5.x is more strict in certificate decoding and performs
>> >>> various checks in the Time fields to ensure they are properly DER
>> >>> formatted. However, it is seems that this caused regressions with
>> >>> certain certificates generated by ovirt as seen in [0]. I am not sure
>> >>> which software was used to generate the problematic ones, however, it
>> >>> is most likely openssl, or some other open source software. Are you
>> >>> aware of other or similar decoding issues which were a result of 3.5.x
>> >>> being more strict in DER rules?
>> >>>
>> >>> The options we have are:
>> >>>  1. Ignore the error and insist on DER correctness in input certificates.
>> >>>  2. Allow incorrect formatted time fields in certificates
>> >>> unconditionally, e.g., with a special libtasn1 flag:
>> >>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>> >>>
>> >>> any other option I've missed? While I favor the first for its
>> >>> simplicity, reality has shown over the years we must yield towards the
>> >>> 'work' part.
>> >>
>> >> NSS is strict in what it accepts. We've recently changed openssl to be
>> >> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
>> >> https://github.com/openssl/openssl/issues/2620), but maybe not
>> >> strict enough yet.
>> >
>> > Thank you, that is really helpful. It seems that Kurt
>>
>> Sorry, I meant to write Tim here!
>
> And today someone filed this in Debian:
> https://bugs.debian.org/862335

I have a patch set which will tolerate incorrectly formatted dates to
work around these issues in openssl:
https://gitlab.com/gnutls/gnutls/merge_requests/400

I am still not sure that tolerating invalid formatted data is a good
thing, however, in case of infrastructure already deployed based on
openssl tools, there is not much an administrator/user can do. What
I'm thinking to do is set a cut-off date after which the original
strict behavior will be re-instated, though I cannot see how would
that help eliminating that issue.

regards,
Nikos


From kurt at roeckx.be  Mon May 29 21:48:02 2017
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 29 May 2017 21:48:02 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
 <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
 <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>
 <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
Message-ID: <20170529194802.lr6clh74lersfift@roeckx.be>

On Mon, May 29, 2017 at 09:53:26AM +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> > On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
> >> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
> >> <n.mavrogiannopoulos at gmail.com> wrote:
> >> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> >> >> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
> >> >>> Hi,
> >> >>>  gnutls 3.5.x is more strict in certificate decoding and performs
> >> >>> various checks in the Time fields to ensure they are properly DER
> >> >>> formatted. However, it is seems that this caused regressions with
> >> >>> certain certificates generated by ovirt as seen in [0]. I am not sure
> >> >>> which software was used to generate the problematic ones, however, it
> >> >>> is most likely openssl, or some other open source software. Are you
> >> >>> aware of other or similar decoding issues which were a result of 3.5.x
> >> >>> being more strict in DER rules?
> >> >>>
> >> >>> The options we have are:
> >> >>>  1. Ignore the error and insist on DER correctness in input certificates.
> >> >>>  2. Allow incorrect formatted time fields in certificates
> >> >>> unconditionally, e.g., with a special libtasn1 flag:
> >> >>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
> >> >>>
> >> >>> any other option I've missed? While I favor the first for its
> >> >>> simplicity, reality has shown over the years we must yield towards the
> >> >>> 'work' part.
> >> >>
> >> >> NSS is strict in what it accepts. We've recently changed openssl to be
> >> >> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
> >> >> https://github.com/openssl/openssl/issues/2620), but maybe not
> >> >> strict enough yet.
> >> >
> >> > Thank you, that is really helpful. It seems that Kurt
> >>
> >> Sorry, I meant to write Tim here!
> >
> > And today someone filed this in Debian:
> > https://bugs.debian.org/862335
> 
> I have a patch set which will tolerate incorrectly formatted dates to
> work around these issues in openssl:
> https://gitlab.com/gnutls/gnutls/merge_requests/400
> 
> I am still not sure that tolerating invalid formatted data is a good
> thing, however, in case of infrastructure already deployed based on
> openssl tools, there is not much an administrator/user can do. What
> I'm thinking to do is set a cut-off date after which the original
> strict behavior will be re-instated, though I cannot see how would
> that help eliminating that issue.

At least on the OpenSSL side we'll work on not allowing to create
such invalid files anymore.


Kurt



From home_pw at msn.com  Mon May 29 23:21:26 2017
From: home_pw at msn.com (Peter Williams)
Date: Mon, 29 May 2017 21:21:26 +0000
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
 <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
 <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>,
 <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
Message-ID: <BY2PR06MB4865011BD92B2C5416E594F92F30@BY2PR06MB486.namprd06.prod.outlook.com>

Der compliance is required by pkix rfc compliance. It is unambiguous in dates. It has been unambiguous for 30+ years.

Assuming this community cares about pkix compliance. Netscape-compliance is also commonly accepted.

In general in the USA, anything to do with money (or insurance or warranty) requires pkix compliance.

Posting a rant to your blog site can be Netscape compliant.



Sent from my iPhone

> On May 29, 2017, at 12:54 AM, Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> 
>> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>> On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
>>> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>>>>> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>>>>>> Hi,
>>>>>> gnutls 3.5.x is more strict in certificate decoding and performs
>>>>>> various checks in the Time fields to ensure they are properly DER
>>>>>> formatted. However, it is seems that this caused regressions with
>>>>>> certain certificates generated by ovirt as seen in [0]. I am not sure
>>>>>> which software was used to generate the problematic ones, however, it
>>>>>> is most likely openssl, or some other open source software. Are you
>>>>>> aware of other or similar decoding issues which were a result of 3.5.x
>>>>>> being more strict in DER rules?
>>>>>> 
>>>>>> The options we have are:
>>>>>> 1. Ignore the error and insist on DER correctness in input certificates.
>>>>>> 2. Allow incorrect formatted time fields in certificates
>>>>>> unconditionally, e.g., with a special libtasn1 flag:
>>>>>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>>>>>> 
>>>>>> any other option I've missed? While I favor the first for its
>>>>>> simplicity, reality has shown over the years we must yield towards the
>>>>>> 'work' part.
>>>>> 
>>>>> NSS is strict in what it accepts. We've recently changed openssl to be
>>>>> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
>>>>> https://github.com/openssl/openssl/issues/2620), but maybe not
>>>>> strict enough yet.
>>>> 
>>>> Thank you, that is really helpful. It seems that Kurt
>>> 
>>> Sorry, I meant to write Tim here!
>> 
>> And today someone filed this in Debian:
>> https://bugs.debian.org/862335
> 
> I have a patch set which will tolerate incorrectly formatted dates to
> work around these issues in openssl:
> https://gitlab.com/gnutls/gnutls/merge_requests/400
> 
> I am still not sure that tolerating invalid formatted data is a good
> thing, however, in case of infrastructure already deployed based on
> openssl tools, there is not much an administrator/user can do. What
> I'm thinking to do is set a cut-off date after which the original
> strict behavior will be re-instated, though I cannot see how would
> that help eliminating that issue.
> 
> regards,
> Nikos
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From tim.ruehsen at gmx.de  Wed May 31 09:37:14 2017
From: tim.ruehsen at gmx.de (=?UTF-8?Q?Tim_R=c3=bchsen?=)
Date: Wed, 31 May 2017 09:37:14 +0200
Subject: [gnutls-devel] DER decoding errors due to time format
In-Reply-To: <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
References: <CAJU7zaJ-uF9sWGLjMnwjT54ojO4od0Th1nYAVqbsP-BY0bxiig@mail.gmail.com>
 <20170509184709.idwqqb3nmccrclmb@roeckx.be>
 <CAJU7zaJDPgw9no=GUo91nyTNCwX_MjptCt2wQKXshVr=9CqJ4A@mail.gmail.com>
 <CAJU7zaJFAR1PW0=NzSosJr=dejJ2yWBS1nUiE9BLLtdrUTMvtQ@mail.gmail.com>
 <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be>
 <CAJU7zaJAsvLMF051jm3kgqDBNB_QC9m-eP0rzdZ8VSLtY_p+PQ@mail.gmail.com>
Message-ID: <b481212a-e482-cdda-f47f-f8443e791497@gmx.de>

On 05/29/2017 09:53 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
>>> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>>>> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>>>>>> Hi,
>>>>>>  gnutls 3.5.x is more strict in certificate decoding and performs
>>>>>> various checks in the Time fields to ensure they are properly DER
>>>>>> formatted. However, it is seems that this caused regressions with
>>>>>> certain certificates generated by ovirt as seen in [0]. I am not sure
>>>>>> which software was used to generate the problematic ones, however, it
>>>>>> is most likely openssl, or some other open source software. Are you
>>>>>> aware of other or similar decoding issues which were a result of 3.5.x
>>>>>> being more strict in DER rules?
>>>>>>
>>>>>> The options we have are:
>>>>>>  1. Ignore the error and insist on DER correctness in input certificates.
>>>>>>  2. Allow incorrect formatted time fields in certificates
>>>>>> unconditionally, e.g., with a special libtasn1 flag:
>>>>>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>>>>>>
>>>>>> any other option I've missed? While I favor the first for its
>>>>>> simplicity, reality has shown over the years we must yield towards the
>>>>>> 'work' part.
>>>>>
>>>>> NSS is strict in what it accepts. We've recently changed openssl to be
>>>>> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
>>>>> https://github.com/openssl/openssl/issues/2620), but maybe not
>>>>> strict enough yet.
>>>>
>>>> Thank you, that is really helpful. It seems that Kurt
>>>
>>> Sorry, I meant to write Tim here!
>>
>> And today someone filed this in Debian:
>> https://bugs.debian.org/862335
> 
> I have a patch set which will tolerate incorrectly formatted dates to
> work around these issues in openssl:
> https://gitlab.com/gnutls/gnutls/merge_requests/400
> 
> I am still not sure that tolerating invalid formatted data is a good
> thing, however, in case of infrastructure already deployed based on
> openssl tools, there is not much an administrator/user can do. What
> I'm thinking to do is set a cut-off date after which the original
> strict behavior will be re-instated, though I cannot see how would
> that help eliminating that issue.

OpenSSL just 'allows' an invalid format, it's not really buggy (at least
not 1.1.1-dev, maybe older versions !?). The question is how many public
deployments are really affected, e.g. how many of the top 1M sites use
certs with invalid dates ?

Maybe there are just a few broken scripts out there, generating invalid
certs. These should be fixed first to allow for a smooth update to a
'fixed' version of OpenSSL.

With Best Regards, Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170531/0a6fa508/attachment-0001.sig>