From ametzler at bebt.de  Wed Feb  1 19:20:40 2017
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 1 Feb 2017 19:20:40 +0100
Subject: [gnutls-devel] gnutls build fails depending on timezone
Message-ID: <20170201182040.gy6s52yuxiirrqao@argenau.bebt.de>

Hello,

Thorsten Glaser has found the following issue with gnutls 3.5.8,
reported as <http://bugs.debian.org/853732>:

----- Forwarded message from Thorsten Glaser <tg at mirbsd.de> -----
[...]
The build fails in the pkcs7 testsuite because of a wrong date;
the testsuite fudges to 2038-10-12 00:00:00 localtime:

(pbuild22064)root at tglase:/tmp/buildd/gnutls28-3.5.8 # openssl x509 -noout -text -in doc/credentials/x509/ca.pem | fgrep Not
            Not Before: May 28 08:36:30 2011 GMT
            Not After : Oct 12 08:36:33 2038 GMT

The fix is easy:

--- /tmp/buildd/gnutls28-3.5.8/tests/cert-tests/pkcs7~	2017-01-31 10:37:42.041736473 +0000
+++ /tmp/buildd/gnutls28-3.5.8/tests/cert-tests/pkcs7	2017-01-31 10:39:00.490675092 +0000
@@ -74,7 +74,7 @@
 fi
 
 # check validation with date after intermediate cert issuance
-datefudge -s "2038-10-12" \
+datefudge -s "2038-10-12 08:36:34 UTC" \
 ${VALGRIND} "${CERTTOOL}" --inder --p7-verify --load-ca-certificate "${srcdir}/../../doc/credentials/x509/ca.pem" --infile "${srcdir}/data/${FILE}" >"${OUTFILE}"
 rc=$?
[...]
----- End forwarded message -----

For simplicity's sake I'd simply go for datefudge -s "2038-10-13". ;-)

I could not reproduce the build-error on amd64, but the Gnutls bug is
obvious.

On amd64 this correctly succeeds...
datefudge -s "2038-01-19" src/certtool --inder --p7-verify --load-ca-certificate ./doc/credentials/x509/ca.pem --infile ./tests/cert-tests/data/full.p7b
... and this wrongly fails:
datefudge -s "2038-01-20" src/certtool --inder --p7-verify --load-ca-certificate ./doc/credentials/x509/ca.pem --infile ./tests/cert-tests/data/full.p7b

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 tim.ruehsen at gmx.de  Wed Feb  1 20:45:04 2017
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Wed, 01 Feb 2017 20:45:04 +0100
Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for
 Debian/stretch release?
In-Reply-To: <20170128173357.kxra5lkodwcfxxs5@argenau.bebt.de>
References: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de>
 <1485602481.2351.1.camel@gmail.com>
 <20170128173357.kxra5lkodwcfxxs5@argenau.bebt.de>
Message-ID: <12489027.4gvO7lyP4x@debian>

On Samstag, 28. Januar 2017 18:33:57 CET Andreas Metzler wrote:
> On 2017-01-28 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> [...]
> 
> > A bit late, but some more bug fixes you may be interested to are:
> > 
> > IDNA2008 support: https://gitlab.com/gnutls/gnutls/merge_requests/240
> > While it is a feature, on certain occasions sticking to IDNA2003 can be
> > considered a vulnerability because of incompatibilities between the
> > mappings of UTF-8 DNS names to ascii format [0]. That is a quite large
> > bunch of patches, but in the long run  I think it is better to support
> > IDNA2008 rather than sticking to IDNA2003 which may cause potential
> > CVEs later.
> > 
> > A fix on AVX detection to allow gnutls run on certain virtual systems:
> > https://gitlab.com/gnutls/gnutls/commit/ef78a758cb899609d7eb4578017bc75227
> > 2cb423
> [...]
> 
> Thanks for the heads-up. Will definitily pull AVX fix. I will probably
> hold back with IDNA 2008. It is a too big change to try to squeeze in
> quickly.

Just want to mention that
- IDNA2008 is a bug + security fix to IDNA2003 (see https://curl.haxx.se/docs/
adv_20161102K.html)
- libcurl/curl now uses IDNA2008 + TR46 (libidn2 0.14+). Likely in testing 
already.
- libpsl uses IDNA2008 + TR46 (in testing)
- the german registry already uses IDNA2008
- the european registry already uses IDNA2008

AFAIK, firefox uses  IDNA2008, Chromium is still at 2003 (but this might change 
at will).

Moving to IDNA2008 cuts some ropes, some characters are disallowed that have 
been allowed before (not sure if any registry allowed those before at all).

While it is fine not pushing IDNA2008 in a hurry into the coming stable, you 
still have some good arguments on your side if you do ;-)

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170201/1abe9bbe/attachment.sig>

From nmav at gnutls.org  Thu Feb  2 11:30:36 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 2 Feb 2017 11:30:36 +0100
Subject: [gnutls-devel] gnutls build fails depending on timezone
In-Reply-To: <20170201182040.gy6s52yuxiirrqao@argenau.bebt.de>
References: <20170201182040.gy6s52yuxiirrqao@argenau.bebt.de>
Message-ID: <CAJU7za+FSdSfeBjgjAyyEmRjsT+EahPczS+Uw2sHadxu2R08eg@mail.gmail.com>

On Wed, Feb 1, 2017 at 7:20 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> Thorsten Glaser has found the following issue with gnutls 3.5.8,
> reported as <http://bugs.debian.org/853732>:
>
> ----- Forwarded message from Thorsten Glaser <tg at mirbsd.de> -----
> [...]
> The build fails in the pkcs7 testsuite because of a wrong date;
> the testsuite fudges to 2038-10-12 00:00:00 localtime:
>
> (pbuild22064)root at tglase:/tmp/buildd/gnutls28-3.5.8 # openssl x509 -noout -text -in doc/credentials/x509/ca.pem | fgrep Not
>             Not Before: May 28 08:36:30 2011 GMT
>             Not After : Oct 12 08:36:33 2038 GMT
>
> The fix is easy:
>
> --- /tmp/buildd/gnutls28-3.5.8/tests/cert-tests/pkcs7~  2017-01-31 10:37:42.041736473 +0000
> +++ /tmp/buildd/gnutls28-3.5.8/tests/cert-tests/pkcs7   2017-01-31 10:39:00.490675092 +0000
> @@ -74,7 +74,7 @@
>  fi
>
>  # check validation with date after intermediate cert issuance
> -datefudge -s "2038-10-12" \
> +datefudge -s "2038-10-12 08:36:34 UTC" \
>  ${VALGRIND} "${CERTTOOL}" --inder --p7-verify --load-ca-certificate "${srcdir}/../../doc/credentials/x509/ca.pem" --infile "${srcdir}/data/${FILE}" >"${OUTFILE}"
>  rc=$?
> [...]
> ----- End forwarded message -----
>
> For simplicity's sake I'd simply go for datefudge -s "2038-10-13". ;-)
> I could not reproduce the build-error on amd64, but the Gnutls bug is
> obvious.

Thank you for the report. I've submitted to merge request to address that.

regards,
Nikos


From antonio at gnu.org  Thu Feb  2 17:16:14 2017
From: antonio at gnu.org (Antonio Diaz Diaz)
Date: Thu, 02 Feb 2017 17:16:14 +0100
Subject: [gnutls-devel] GnuTLS 3.5.8 testsuite error on test-strverscmp
Message-ID: <58935B4E.9010602@gnu.org>

Hello Nikos et al, :-)

While testing gnutls-3.5.8 on a 32-bit GNU/Linux system with glibc-2.5 
and gcc-4.1.2, I got the following error:

--------------------------------------------------------------------
../../build-aux/test-driver: line 107: 17413 Aborted "$@" >$log_file 2>&1
FAIL: test-strverscmp
--------------------------------------------------------------------

I think this error is caused by a bug in glibc, but as gnutls checks 
libc functions, it would be nice to mention in INSTALL or README the 
oldest version of glibc known to work.

(Latest versions of both libnettle and gmplib compiled and passed all 
the tests on this same system).

I also got a lot of warnings. I attach the full logs for 'make' and 
'make -k check', but I list here some of the most interesting warnings:

--------------------------------------------------------------------
cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but 
not for C
cc1: warning: command line option "-Wdeprecated" is valid for 
C++/Java/ObjC++ but not for C

In file included from ./../str.h:30,
                  from ./../gnutls_int.h:251,
                  from common.c:24:
./../../gl/c-ctype.h:170: warning: no previous prototype for 'c_isalnum' 
[-Wmissing-prototypes]

In file included from common.c:34:
./../extras/hex.h: In function 'hex_data_size':
./../extras/hex.h:69: warning: declaration of 'strlen' shadows a global 
declaration [-Wshadow]
/usr/include/string.h:243: warning: shadowed declaration is here [-Wshadow]

decoding.c: In function 'asn1_get_length_der':
decoding.c:121: warning: comparison of unsigned expression < 0 is always 
false

keydb.c: In function 'keydb_find_byusage':
keydb.c:795: warning: comparison between signed and unsigned
keydb.c:804: warning: comparison between signed and unsigned

read-packet.c: In function 'read_attribute':
read-packet.c:479: warning: comparison between signed and unsigned
read-packet.c:479: warning: signed and unsigned type in conditional 
expression

sysrng-linux.c: In function 'have_getrandom':
sysrng-linux.c:68: warning: unused variable 'c' [-Wunused-variable]

system/fastopen.c: In function 'tfo_writev':
system/fastopen.c:112: warning: label 'connect_only' defined but not used
system/fastopen.c:79: warning: unused variable 'on' [-Wunused-variable]

mktime.c: In function 'mktime_internal':
mktime.c:355: warning: comparison is always false due to limited range 
of data type
mktime.c:355: warning: comparison is always false due to limited range 
of data type

certtool-cfg.c:61:1: warning: macro "__STDC_FORMAT_MACROS" is not used
danetool-args.c:42:1: warning: macro "OPTION_CODE_COMPILE" is not used
systemkey-args.c:42:1: warning: macro "OPTION_CODE_COMPILE" is not used

--------------------------------------------------------------------
test-intprops.c: In function 'main':
test-intprops.c:323: warning: integer overflow in expression
test-intprops.c:325: warning: integer overflow in expression

mini-record-retvals.c:424:1: warning: macro "AES_CBC" is not used

tlsext-decoding.c:37: warning: function declaration isn't a prototype 
[-Wstrict-prototypes]
tlsext-decoding.c: In function 'main':
tlsext-decoding.c:37: warning: old-style function definition 
[-Wold-style-definition]

ocsp.c: In function 'req_parse':
ocsp.c:903: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]
ocsp.c: In function 'req_addcert_id':
ocsp.c:1097: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]
ocsp.c: In function 'req_addcert':
ocsp.c:1210: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]
ocsp.c: In function 'resp_import':
ocsp.c:1312: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]
ocsp.c:1338: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]
ocsp.c:1373: warning: format '%ld' expects type 'long int', but argument 
2 has type 'unsigned int' [-Wformat]

cng-windows.c:37: warning: function declaration isn't a prototype 
[-Wstrict-prototypes]
cng-windows.c: In function 'doit':
cng-windows.c:37: warning: old-style function definition 
[-Wold-style-definition]


Thanks,
Antonio.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-suite.log
URL: </pipermail/attachments/20170202/6880dee4/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-3.5.8_make.log.bz2
Type: application/octet-stream
Size: 7208 bytes
Desc: not available
URL: </pipermail/attachments/20170202/6880dee4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-3.5.8_make_check.log.bz2
Type: application/octet-stream
Size: 7995 bytes
Desc: not available
URL: </pipermail/attachments/20170202/6880dee4/attachment-0003.obj>

From nmav at gnutls.org  Fri Feb  3 23:33:18 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 3 Feb 2017 23:33:18 +0100
Subject: [gnutls-devel] GnuTLS 3.5.8 testsuite error on test-strverscmp
In-Reply-To: <58935B4E.9010602@gnu.org>
References: <58935B4E.9010602@gnu.org>
Message-ID: <CAJU7zaLHoAZ01Y3bWSaLYSjyW3xwnvF1mSWKfiHc2HNnv5gkCA@mail.gmail.com>

On Thu, Feb 2, 2017 at 5:16 PM, Antonio Diaz Diaz <antonio at gnu.org> wrote:
> Hello Nikos et al, :-)
>
> While testing gnutls-3.5.8 on a 32-bit GNU/Linux system with glibc-2.5 and
> gcc-4.1.2, I got the following error:
>
> --------------------------------------------------------------------
> ../../build-aux/test-driver: line 107: 17413 Aborted "$@" >$log_file 2>&1
> FAIL: test-strverscmp
> --------------------------------------------------------------------
>
> I think this error is caused by a bug in glibc, but as gnutls checks libc
> functions, it would be nice to mention in INSTALL or README the oldest
> version of glibc known to work.

Hi Antonio,
 That seems like an issue in the gnulib test suite rather than (the
actual) gnutls'. As this function is not used by gnutls, you can
ignore this test. Not sure if we can disable it in the included
gnulib, but if you know a way I'd appreciate a patch, I'm not an avid
gnulib user.

> I also got a lot of warnings. I attach the full logs for 'make' and 'make -k
> check', but I list here some of the most interesting warnings:
>
> --------------------------------------------------------------------
> cc1: warning: command line option "-Wabi" is valid for C++/ObjC++ but not
> for C
> cc1: warning: command line option "-Wdeprecated" is valid for
> C++/Java/ObjC++ but not for C
>
> In file included from ./../str.h:30,
>                  from ./../gnutls_int.h:251,
>                  from common.c:24:
> ./../../gl/c-ctype.h:170: warning: no previous prototype for 'c_isalnum'
> [-Wmissing-prototypes]

That seems like a gnulib issue again. That function is provided by gnulib.


> In file included from common.c:34:
> ./../extras/hex.h: In function 'hex_data_size':
> ./../extras/hex.h:69: warning: declaration of 'strlen' shadows a global
> declaration [-Wshadow]
> /usr/include/string.h:243: warning: shadowed declaration is here [-Wshadow]

Thanks, fixed.

> decoding.c: In function 'asn1_get_length_der':
> decoding.c:121: warning: comparison of unsigned expression < 0 is always
> false

Again a gnulib thing, but in that case more hard to fix. As this is a
macro supposed to be used with signed and unsigned expressions, I'm
not sure we can avoid that.

> keydb.c: In function 'keydb_find_byusage':
> keydb.c:795: warning: comparison between signed and unsigned
> keydb.c:804: warning: comparison between signed and unsigned
>
> read-packet.c: In function 'read_attribute':
> read-packet.c:479: warning: comparison between signed and unsigned
> read-packet.c:479: warning: signed and unsigned type in conditional
> expression

OpenPGP related code. To be removed rather than fixed.

> sysrng-linux.c: In function 'have_getrandom':
> sysrng-linux.c:68: warning: unused variable 'c' [-Wunused-variable]
>
> system/fastopen.c: In function 'tfo_writev':
> system/fastopen.c:112: warning: label 'connect_only' defined but not used
> system/fastopen.c:79: warning: unused variable 'on' [-Wunused-variable]

On certain code for old systems I optimized readability of code as
opposed to making sure that variables are always used.

> mktime.c: In function 'mktime_internal':
> mktime.c:355: warning: comparison is always false due to limited range of
> data type
> mktime.c:355: warning: comparison is always false due to limited range of
> data type

Again, gnulib issue, related to macros that work for multiple variables.


regards,
Nikos


From alon.barlev at gmail.com  Sat Feb  4 02:47:04 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 4 Feb 2017 03:47:04 +0200
Subject: [gnutls-devel] doc/Makefile.am::imagesdir = $(infodir)
Message-ID: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>

Hi,
Any reason why this is not htmldir?
As far as I understand these are used in the htmls.
Thanks!
Alon


From nmav at gnutls.org  Sat Feb  4 23:06:46 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 4 Feb 2017 23:06:46 +0100
Subject: [gnutls-devel] [gnutls-help] crash in
 gnutls_x509_trust_list_add_trust_file()
In-Reply-To: <72251938-3758-b2a9-5082-a0fe44a66acd@wizmail.org>
References: <207b22d0-21c0-d39d-e93e-c3dee86de0dc@wizmail.org>
 <CAJU7za+ND2+y+gH-6hTgDXvh0-tbcS5+gyNp59WaqNExTrFspw@mail.gmail.com>
 <9e4b8168-1201-024a-97a5-5cf8d5c374d6@wizmail.org>
 <CAJU7zaKMAOX1EbZP6Vur2JMc1cjmp=Puh2vg0QQrM24zmEXvXg@mail.gmail.com>
 <0146a700-2b13-0823-6848-813d3ef9e1f4@wizmail.org>
 <CAJU7za+x2p0=MinBeOyF3_2fJarzZkn=KAXd25za95yBcGr__A@mail.gmail.com>
 <72251938-3758-b2a9-5082-a0fe44a66acd@wizmail.org>
Message-ID: <CAJU7zaLsShfcn41Cp8bQjL9iAwMmv9JKk4biYEKBueX7O54h6g@mail.gmail.com>

On Sat, Feb 4, 2017 at 4:01 PM, Jeremy Harris <jgh at wizmail.org> wrote:
> On 04/02/17 13:41, Nikos Mavrogiannopoulos wrote:
>> Could you try this build after it compiles?
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17591753
>
> OK:
>
> [jgh at lap test]$ sudo dnf provides */libgnutls.so
> Last metadata expiration check: 4:08:45 ago on Sat Feb  4 10:46:29 2017.
> gnutls-devel-3.5.8-2.fc25.x86_64 : Development files for the gnutls package
> Repo        : @System
>
>
> ... and no crash from the GnuTLS-related portions of the Exim testsuite,
> which did crash with gnutls-devel-3.5.8-1.fc25.x86_64.
>
> Can you say if all library versions identifying at runtime as 3.5.8
> should be regarded as suspect?  Some other known versions too?
> Only Fedora ones?

This affects Fedora only because it is using the p11-kit trust store
which goes through PKCS#11. As a bug it affects all released versions
I guess.

regards,
Nikos


From nmav at gnutls.org  Sun Feb 12 11:23:15 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 12 Feb 2017 11:23:15 +0100
Subject: [gnutls-devel] gnutls 3.5.9
Message-ID: <1486894995.2137.3.camel@gnutls.org>

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


* Version 3.5.9 (released 2017-02-12)

** libgnutls: Removed any references to OpenPGP functionality in documentation,
???and marked all functions in openpgp.h as deprecated. That functionality
???is considered deprecated and should not be used for other reason than
???backwards compatibility.

** libgnutls: Improve detection of AVX support. In certain cases when
???when the instruction was available on the host, but not on a VM running
???gnutls, detection could fail causing illegal instruction usage.

** libgnutls: Added support for IDNA2008 for internationalized DNS names.
???If gnutls is compiled using libidn2 (the latest version is recommended),
???it will support IDNA2008 instead of the now obsolete IDNA2003 standard.
???Resolves gitlab issue #150. Based on patch by Tim Ruehsen.

** p11tool: re-use ID from corresponding objects when writing certificates.
???That is, when writing a certificate which has a corresponding public key,
???or private key in the token, ensure that we use the same ID for the
???certificate.

** API and ABI modifications:
gnutls_idna_map: Added
gnutls_idna_reverse_map: Added


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.9.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.9.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 n.mavrogiannopoulos at gmail.com  Sun Feb 12 12:29:31 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 12 Feb 2017 12:29:31 +0100
Subject: [gnutls-devel] doc/Makefile.am::imagesdir = $(infodir)
In-Reply-To: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>
References: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>
Message-ID: <1486898971.2137.5.camel@gmail.com>

On Sat, 2017-02-04 at 03:47 +0200, Alon Bar-Lev wrote:
> Hi,
> Any reason why this is not htmldir?
> As far as I understand these are used in the htmls.

No idea. Does that cause an issue with the html output?

regards,
Nikos



From alon.barlev at gmail.com  Sun Feb 12 14:01:12 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 12 Feb 2017 15:01:12 +0200
Subject: [gnutls-devel] doc/Makefile.am::imagesdir = $(infodir)
In-Reply-To: <1486898971.2137.5.camel@gmail.com>
References: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>
 <1486898971.2137.5.camel@gmail.com>
Message-ID: <CAOazyz1xCmFE8AN9cvGC1+i_-eaKa1wJ8YhKPdaMWq+HcZQbMQ@mail.gmail.com>

On 12 February 2017 at 13:29, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
>
> On Sat, 2017-02-04 at 03:47 +0200, Alon Bar-Lev wrote:
> > Hi,
> > Any reason why this is not htmldir?
> > As far as I understand these are used in the htmls.
>
> No idea. Does that cause an issue with the html output?

I do not think so, we patch this for long time in gentoo, thought of
removing that as well if there is no reason to do that otherwise.


From alon.barlev at gmail.com  Sun Feb 12 21:36:46 2017
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 12 Feb 2017 22:36:46 +0200
Subject: [gnutls-devel] doc/Makefile.am::imagesdir = $(infodir)
In-Reply-To: <CAOazyz1xCmFE8AN9cvGC1+i_-eaKa1wJ8YhKPdaMWq+HcZQbMQ@mail.gmail.com>
References: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>
 <1486898971.2137.5.camel@gmail.com>
 <CAOazyz1xCmFE8AN9cvGC1+i_-eaKa1wJ8YhKPdaMWq+HcZQbMQ@mail.gmail.com>
Message-ID: <CAOazyz1+_bqjWQa8-PAR++0QjpHfEaOEfUVeTEgBo690UzjdLA@mail.gmail.com>

On 12 February 2017 at 15:01, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 12 February 2017 at 13:29, Nikos Mavrogiannopoulos
> <n.mavrogiannopoulos at gmail.com> wrote:
>>
>> On Sat, 2017-02-04 at 03:47 +0200, Alon Bar-Lev wrote:
>> > Hi,
>> > Any reason why this is not htmldir?
>> > As far as I understand these are used in the htmls.
>>
>> No idea. Does that cause an issue with the html output?
>
> I do not think so, we patch this for long time in gentoo, thought of
> removing that as well if there is no reason to do that otherwise.

Created this[1], thanks!

[1] https://gitlab.com/gnutls/gnutls/merge_requests/255


From ludo at gnu.org  Sat Feb 11 00:28:54 2017
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Sat, 11 Feb 2017 00:28:54 +0100
Subject: [gnutls-devel] doc/Makefile.am::imagesdir = $(infodir)
References: <CAOazyz3U3gJcRYP0pz0j=vH4mA-kAAHxwZX_JEHSN=ULr1w1PQ@mail.gmail.com>
Message-ID: <87shnl4ocp.fsf@gnu.org>

Hi,

Alon Bar-Lev <alon.barlev at gmail.com> skribis:

> Any reason why this is not htmldir?
> As far as I understand these are used in the htmls.

But these are also used in the Info files.

I guess there could be a local target to symlink one place to the other
upon install.

Ludo?.


From n.mavrogiannopoulos at gmail.com  Sun Feb 19 10:55:49 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 19 Feb 2017 10:55:49 +0100
Subject: [gnutls-devel] lock-free random generator
Message-ID: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>

Hi,
 One of the items that have been on my todo-list after discussing with
application writers of multi-threaded applications (mainly servers),
is addressing the issue of synchronization for the random generator.
Currently gnutls provides a "central" random generator based on yarrow
(for keys) and salsa20 (for nonces) primitives, and it is thread safe
by utilizing mutexes over it. An application that has more than
100-200 threads is most likely to spend more time in synchronization
rather than the random generator itself. A solution to that would be
to provide a thread-local random generator which will work lock-free,
at the cost of additional memory per-thread -around 600-700 bytes for
the current generator-.

I have an experimental patch set, implementing this idea at:
https://gitlab.com/gnutls/gnutls/merge_requests/259

On the patch above, the additional cost per thread will only be for
threads actually utilizing gnutls, and in particular the random
generator, as the required memory will be allocated after the first
call to gnutls_rnd() by the thread.

Are there any objections on such an enhancement to gnutls, or
suggestions on how such a lock-free random generator could be improved
(in terms of memory utilization for example)?

regards,
Nikos


From nisse at lysator.liu.se  Sun Feb 19 19:17:14 2017
From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=)
Date: Sun, 19 Feb 2017 19:17:14 +0100
Subject: [gnutls-devel] lock-free random generator
In-Reply-To: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Sun, 19 Feb 2017 10:55:49
 +0100")
References: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
Message-ID: <nnvas6qc45.fsf@armitage.lysator.liu.se>

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

> Currently gnutls provides a "central" random generator based on yarrow
> (for keys) and salsa20 (for nonces) primitives, and it is thread safe
> by utilizing mutexes over it. An application that has more than
> 100-200 threads is most likely to spend more time in synchronization
> rather than the random generator itself. A solution to that would be
> to provide a thread-local random generator which will work lock-free,
> at the cost of additional memory per-thread -around 600-700 bytes for
> the current generator-.

Would it make sense to handle the two cases differently, with a
thread-local nonce-generator, but stick to a global key-generator
protected by a mutex?

I imagine there are a lot more calls for nonces than for keys?

For the yarrow reseed logic, I think it may be preferable with a global
instance.

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.


From n.mavrogiannopoulos at gmail.com  Mon Feb 20 08:14:40 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 20 Feb 2017 08:14:40 +0100
Subject: [gnutls-devel] lock-free random generator
In-Reply-To: <nnvas6qc45.fsf@armitage.lysator.liu.se>
References: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
 <nnvas6qc45.fsf@armitage.lysator.liu.se>
Message-ID: <CAJU7zaLLNvsF04qpPbtXN9bags+M4_poKrDogXOFs17L-bsiYA@mail.gmail.com>

On Sun, Feb 19, 2017 at 7:17 PM, Niels M?ller <nisse at lysator.liu.se> wrote:
>> Currently gnutls provides a "central" random generator based on yarrow
>> (for keys) and salsa20 (for nonces) primitives, and it is thread safe
>> by utilizing mutexes over it. An application that has more than
>> 100-200 threads is most likely to spend more time in synchronization
>> rather than the random generator itself. A solution to that would be
>> to provide a thread-local random generator which will work lock-free,
>> at the cost of additional memory per-thread -around 600-700 bytes for
>> the current generator-.
>
> Would it make sense to handle the two cases differently, with a
> thread-local nonce-generator, but stick to a global key-generator
> protected by a mutex?
>
> I imagine there are a lot more calls for nonces than for keys?

Certainly. Currently, there is at least a single call for key
generation on each established TLS session, meaning that the
bottleneck will remain, for the case where multiple threads are used
to host multiple sessions - it will be reduced to a single place
however -.

> For the yarrow reseed logic, I think it may be preferable with a global instance.

If we need yarrow, your recommendation seems to be the right approach.
However, another thought it has been bugging me lately, is whether we
need yarrow in gnutls. It looks quite suited for something central
like /dev/urandom which has several maybe untrusted inputs, but for
gnutls which seeds from /dev/urandom (or the equivalent system calls),
having a PRNG which concerns itself with manipulation of input may not
be adding the security it is perceived to add.

regards,
Nikos


From tim.ruehsen at gmx.de  Mon Feb 20 11:05:21 2017
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 20 Feb 2017 11:05:21 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP header
 ?
Message-ID: <6388246.YgqTiBJVue@blitz-lx>

Hi,

is there a tool (certtool ?) or script to generate the base64 encoded sha256 
sums of a cert's pubkey?

Primary for usage in the Public-Key-Pins HTTP header.

Thanks, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170220/c5e05384/attachment.sig>

From nmav at gnutls.org  Mon Feb 20 12:47:05 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 20 Feb 2017 12:47:05 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <6388246.YgqTiBJVue@blitz-lx>
References: <6388246.YgqTiBJVue@blitz-lx>
Message-ID: <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>

On Mon, Feb 20, 2017 at 11:05 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi,
>
> is there a tool (certtool ?) or script to generate the base64 encoded sha256
> sums of a cert's pubkey?

I do not think there is a direct option to get it in base64, but you
can get it in hex as:
certtool --key-id --hash sha256 --infile cert.pem
or (for older releases which didn't have --key-id)
certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' ' -f 1

Then you can go to base64 as:
certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' '
-f 1|xxd -r -p|base64

regards,
Nikos


From tim.ruehsen at gmx.de  Mon Feb 20 12:58:12 2017
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 20 Feb 2017 12:58:12 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
Message-ID: <1579007.7BUzXPq6CS@blitz-lx>

On Monday, February 20, 2017 12:47:05 PM CET Nikos Mavrogiannopoulos wrote:
> On Mon, Feb 20, 2017 at 11:05 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi,
> > 
> > is there a tool (certtool ?) or script to generate the base64 encoded
> > sha256 sums of a cert's pubkey?
> 
> I do not think there is a direct option to get it in base64, but you
> can get it in hex as:
> certtool --key-id --hash sha256 --infile cert.pem
> or (for older releases which didn't have --key-id)
> certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' ' -f 1
> 
> Then you can go to base64 as:
> certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' '
> -f 1|xxd -r -p|base64

Great !
This last one I was looking for :-)

Many Thanks, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170220/a5911fb4/attachment.sig>

From dkg at fifthhorseman.net  Mon Feb 20 20:43:01 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 20 Feb 2017 14:43:01 -0500
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
Message-ID: <8737f8eji2.fsf@alice.fifthhorseman.net>

On Mon 2017-02-20 06:47:05 -0500, Nikos Mavrogiannopoulos wrote:
> On Mon, Feb 20, 2017 at 11:05 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> Hi,
>>
>> is there a tool (certtool ?) or script to generate the base64 encoded sha256
>> sums of a cert's pubkey?
>
> I do not think there is a direct option to get it in base64, but you
> can get it in hex as:
> certtool --key-id --hash sha256 --infile cert.pem
> or (for older releases which didn't have --key-id)
> certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' ' -f 1
>
> Then you can go to base64 as:
> certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' '
> -f 1|xxd -r -p|base64

If you want it in C, please take a look at daemon/tls.c from
https://gitlab.labs.nic.cz/knot/resolver.git, which has a
get_oob_key_pin() function that uses gnutls primitives (except for the
b64 encoding).

It would be nice see that particular digest caluclation be included in
the output of certtool -i, fwiw.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170220/cf0247c6/attachment.sig>

From tim.ruehsen at gmx.de  Tue Feb 21 09:18:47 2017
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Tue, 21 Feb 2017 09:18:47 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <8737f8eji2.fsf@alice.fifthhorseman.net>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
 <8737f8eji2.fsf@alice.fifthhorseman.net>
Message-ID: <1524322.zUfcYkciEy@blitz-lx>

On Monday, February 20, 2017 2:43:01 PM CET Daniel Kahn Gillmor wrote:
> On Mon 2017-02-20 06:47:05 -0500, Nikos Mavrogiannopoulos wrote:
> > On Mon, Feb 20, 2017 at 11:05 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> Hi,
> >> 
> >> is there a tool (certtool ?) or script to generate the base64 encoded
> >> sha256 sums of a cert's pubkey?
> > 
> > I do not think there is a direct option to get it in base64, but you
> > can get it in hex as:
> > certtool --key-id --hash sha256 --infile cert.pem
> > or (for older releases which didn't have --key-id)
> > certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' ' -f
> > 1
> > 
> > Then you can go to base64 as:
> > certtool --pubkey-info --outder --infile cert.pem|sha256sum|cut -d ' '
> > -f 1|xxd -r -p|base64
> 
> If you want it in C, please take a look at daemon/tls.c from
> https://gitlab.labs.nic.cz/knot/resolver.git, which has a
> get_oob_key_pin() function that uses gnutls primitives (except for the
> b64 encoding).
> 
> It would be nice see that particular digest caluclation be included in
> the output of certtool -i, fwiw.

FYI, the C code is also in wget and now in wget2 (for HPKP).

And I agree to Daniel, having that in certtool makes it available to the 
public quicker, since xxd, cut, base64 and sha256sum are not easily available 
on any platform.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170221/8ac4d642/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Tue Feb 21 13:38:45 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 21 Feb 2017 13:38:45 +0100
Subject: [gnutls-devel] handling security issues
Message-ID: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>

Hi,
 I've tried to make the current ad-hoc handling of security issues
with something more formally defined at:
https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md

My goal is to establish some more objective criteria than my opinion
on when an issue will be handled as a security issue and an advisory
will be issued. In the text above I've used the CVSS scoring which
seems to be generic and objective enough. Any comments or suggestions
on the above text?

regards,
Nikos


From berrange at redhat.com  Tue Feb 21 14:06:09 2017
From: berrange at redhat.com (Daniel P. Berrange)
Date: Tue, 21 Feb 2017 13:06:09 +0000
Subject: [gnutls-devel] handling security issues
In-Reply-To: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
References: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
Message-ID: <20170221130609.GF17041@redhat.com>

On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
> Hi,
>  I've tried to make the current ad-hoc handling of security issues
> with something more formally defined at:
> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
> 
> My goal is to establish some more objective criteria than my opinion
> on when an issue will be handled as a security issue and an advisory
> will be issued. In the text above I've used the CVSS scoring which
> seems to be generic and objective enough. Any comments or suggestions
> on the above text?

The text indicates a permissible 3 month window between bug report
and comitting of a fix. Can you clarify that further, in particular
does that mean you'd accept requests for many month long embargo
periods on non-public bug reports ?

As an app dev using gnutls, I'd like to think the time between security
bugs being reported & info + fix being made public, would be measured
in days, or weeks, and certainly no more than 1 month at a maximum.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


From nmav at gnutls.org  Wed Feb 22 10:54:14 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 22 Feb 2017 10:54:14 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <1524322.zUfcYkciEy@blitz-lx>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
 <8737f8eji2.fsf@alice.fifthhorseman.net> <1524322.zUfcYkciEy@blitz-lx>
Message-ID: <CAJU7za+h0Wc-d9R26bAJhwY+dJAx0vd2Hbj+aH-7cw40ko7nwA@mail.gmail.com>

On Tue, Feb 21, 2017 at 9:18 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> If you want it in C, please take a look at daemon/tls.c from
>> https://gitlab.labs.nic.cz/knot/resolver.git, which has a
>> get_oob_key_pin() function that uses gnutls primitives (except for the
>> b64 encoding).
>>
>> It would be nice see that particular digest caluclation be included in
>> the output of certtool -i, fwiw.
>
> FYI, the C code is also in wget and now in wget2 (for HPKP).
>
> And I agree to Daniel, having that in certtool makes it available to the
> public quicker, since xxd, cut, base64 and sha256sum are not easily available
> on any platform.

Well adding something is easy, but the output of certificate
information seems already quite bloated with Fingerprint
(sha1/sha256), Public Key ID (sha1/sha256) and random art. Any ideas
on what we could remove?

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Wed Feb 22 13:16:00 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 22 Feb 2017 13:16:00 +0100
Subject: [gnutls-devel] handling security issues
In-Reply-To: <20170221130609.GF17041@redhat.com>
References: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
 <20170221130609.GF17041@redhat.com>
Message-ID: <CAJU7zaLHRG8hkR1XJE7cd4mu1VD=rMwq0YBFygQbBgziY=8upA@mail.gmail.com>

On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  I've tried to make the current ad-hoc handling of security issues
>> with something more formally defined at:
>> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
>>
>> My goal is to establish some more objective criteria than my opinion
>> on when an issue will be handled as a security issue and an advisory
>> will be issued. In the text above I've used the CVSS scoring which
>> seems to be generic and objective enough. Any comments or suggestions
>> on the above text?
> The text indicates a permissible 3 month window between bug report
> and comitting of a fix. Can you clarify that further, in particular
> does that mean you'd accept requests for many month long embargo
> periods on non-public bug reports ?

I meant it to be as an upper bound on the time between report and fix.
Do you suggest that we make a distinction between that time and the
acceptable embargo time imposed by reporters?

> As an app dev using gnutls, I'd like to think the time between security
> bugs being reported & info + fix being made public, would be measured
> in days, or weeks, and certainly no more than 1 month at a maximum.

Certainly and I believe the average time of fixes is typically counted
in days (though fixes get bundled in the monthly based release).
However, there cannot be strict SLAs, but more like recommended
guidelines/principles.

regards,
Nikos


From berrange at redhat.com  Wed Feb 22 13:19:31 2017
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 22 Feb 2017 12:19:31 +0000
Subject: [gnutls-devel] handling security issues
In-Reply-To: <CAJU7zaLHRG8hkR1XJE7cd4mu1VD=rMwq0YBFygQbBgziY=8upA@mail.gmail.com>
References: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
 <20170221130609.GF17041@redhat.com>
 <CAJU7zaLHRG8hkR1XJE7cd4mu1VD=rMwq0YBFygQbBgziY=8upA@mail.gmail.com>
Message-ID: <20170222121931.GM28937@redhat.com>

On Wed, Feb 22, 2017 at 01:16:00PM +0100, Nikos Mavrogiannopoulos wrote:
> On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
> >> Hi,
> >>  I've tried to make the current ad-hoc handling of security issues
> >> with something more formally defined at:
> >> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
> >>
> >> My goal is to establish some more objective criteria than my opinion
> >> on when an issue will be handled as a security issue and an advisory
> >> will be issued. In the text above I've used the CVSS scoring which
> >> seems to be generic and objective enough. Any comments or suggestions
> >> on the above text?
> > The text indicates a permissible 3 month window between bug report
> > and comitting of a fix. Can you clarify that further, in particular
> > does that mean you'd accept requests for many month long embargo
> > periods on non-public bug reports ?
> 
> I meant it to be as an upper bound on the time between report and fix.
> Do you suggest that we make a distinction between that time and the
> acceptable embargo time imposed by reporters?

Yeah, if you consider acceptable embargo times to be different/less than
this 3 month upper bound for code fix, then I think it'd be worth making
that explicit so people don't mis-interpret it as I did.

> > As an app dev using gnutls, I'd like to think the time between security
> > bugs being reported & info + fix being made public, would be measured
> > in days, or weeks, and certainly no more than 1 month at a maximum.
> 
> Certainly and I believe the average time of fixes is typically counted
> in days (though fixes get bundled in the monthly based release).
> However, there cannot be strict SLAs, but more like recommended
> guidelines/principles.

Yep, understood.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


From n.mavrogiannopoulos at gmail.com  Wed Feb 22 16:42:46 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 22 Feb 2017 16:42:46 +0100
Subject: [gnutls-devel] handling security issues
In-Reply-To: <20170222121931.GM28937@redhat.com>
References: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
 <20170221130609.GF17041@redhat.com>
 <CAJU7zaLHRG8hkR1XJE7cd4mu1VD=rMwq0YBFygQbBgziY=8upA@mail.gmail.com>
 <20170222121931.GM28937@redhat.com>
Message-ID: <CAJU7zaLSeq8nevqohcFBJcRqOGeD56ez1BjYv_tQW8CoHvyZTg@mail.gmail.com>

On Wed, Feb 22, 2017 at 1:19 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Wed, Feb 22, 2017 at 01:16:00PM +0100, Nikos Mavrogiannopoulos wrote:
>> On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> > On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
>> >> Hi,
>> >>  I've tried to make the current ad-hoc handling of security issues
>> >> with something more formally defined at:
>> >> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
>> >>
>> >> My goal is to establish some more objective criteria than my opinion
>> >> on when an issue will be handled as a security issue and an advisory
>> >> will be issued. In the text above I've used the CVSS scoring which
>> >> seems to be generic and objective enough. Any comments or suggestions
>> >> on the above text?
>> > The text indicates a permissible 3 month window between bug report
>> > and comitting of a fix. Can you clarify that further, in particular
>> > does that mean you'd accept requests for many month long embargo
>> > periods on non-public bug reports ?
>>
>> I meant it to be as an upper bound on the time between report and fix.
>> Do you suggest that we make a distinction between that time and the
>> acceptable embargo time imposed by reporters?
>
> Yeah, if you consider acceptable embargo times to be different/less than
> this 3 month upper bound for code fix, then I think it'd be worth making
> that explicit so people don't mis-interpret it as I did.

Do you mean something like amending with:
"Issues reported by third parties which request an embargo time of less than
two weeks are granted. Otherwise the issue is handled as soon as possible
and committed at two weeks time, or when available."


regards,
Nikos


From berrange at redhat.com  Wed Feb 22 16:54:06 2017
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 22 Feb 2017 15:54:06 +0000
Subject: [gnutls-devel] handling security issues
In-Reply-To: <CAJU7zaLSeq8nevqohcFBJcRqOGeD56ez1BjYv_tQW8CoHvyZTg@mail.gmail.com>
References: <CAJU7zaJ+-k8SXEPW3gjR+0fcp4+5yycmrtPTrsBpqyLEAUMNsA@mail.gmail.com>
 <20170221130609.GF17041@redhat.com>
 <CAJU7zaLHRG8hkR1XJE7cd4mu1VD=rMwq0YBFygQbBgziY=8upA@mail.gmail.com>
 <20170222121931.GM28937@redhat.com>
 <CAJU7zaLSeq8nevqohcFBJcRqOGeD56ez1BjYv_tQW8CoHvyZTg@mail.gmail.com>
Message-ID: <20170222155406.GU28937@redhat.com>

On Wed, Feb 22, 2017 at 04:42:46PM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Feb 22, 2017 at 1:19 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Wed, Feb 22, 2017 at 01:16:00PM +0100, Nikos Mavrogiannopoulos wrote:
> >> On Tue, Feb 21, 2017 at 2:06 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> >> > On Tue, Feb 21, 2017 at 01:38:45PM +0100, Nikos Mavrogiannopoulos wrote:
> >> >> Hi,
> >> >>  I've tried to make the current ad-hoc handling of security issues
> >> >> with something more formally defined at:
> >> >> https://gitlab.com/gnutls/gnutls/blob/master/SECURITY.md
> >> >>
> >> >> My goal is to establish some more objective criteria than my opinion
> >> >> on when an issue will be handled as a security issue and an advisory
> >> >> will be issued. In the text above I've used the CVSS scoring which
> >> >> seems to be generic and objective enough. Any comments or suggestions
> >> >> on the above text?
> >> > The text indicates a permissible 3 month window between bug report
> >> > and comitting of a fix. Can you clarify that further, in particular
> >> > does that mean you'd accept requests for many month long embargo
> >> > periods on non-public bug reports ?
> >>
> >> I meant it to be as an upper bound on the time between report and fix.
> >> Do you suggest that we make a distinction between that time and the
> >> acceptable embargo time imposed by reporters?
> >
> > Yeah, if you consider acceptable embargo times to be different/less than
> > this 3 month upper bound for code fix, then I think it'd be worth making
> > that explicit so people don't mis-interpret it as I did.
> 
> Do you mean something like amending with:
> "Issues reported by third parties which request an embargo time of less than
> two weeks are granted. Otherwise the issue is handled as soon as possible
> and committed at two weeks time, or when available."

Yeah, something like that is reasonable.

FWIW, as a point of reference, for libvirt we wrote[1]

 "The general aim of the team is to have embargo dates which are two 
  weeks or less in duration. If a problem is identified with a proposed
  patch for a security issue, requiring further investigation and bug 
  fixing, the embargo clock may be restarted. In exceptional circumstances
  longer initial embargoes may be negotiated by mutual agreement between
  members of the security team and other relevant parties to the problem.
  Any such extended embargoes will aim to be at most one month in duration." 

Regards,
Daniel

[1] http://libvirt.org/securityprocess.html
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|


From dkg at fifthhorseman.net  Wed Feb 22 23:51:58 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 22 Feb 2017 17:51:58 -0500
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <CAJU7za+h0Wc-d9R26bAJhwY+dJAx0vd2Hbj+aH-7cw40ko7nwA@mail.gmail.com>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
 <8737f8eji2.fsf@alice.fifthhorseman.net> <1524322.zUfcYkciEy@blitz-lx>
 <CAJU7za+h0Wc-d9R26bAJhwY+dJAx0vd2Hbj+aH-7cw40ko7nwA@mail.gmail.com>
Message-ID: <87efyp96up.fsf@alice.fifthhorseman.net>

On Wed 2017-02-22 04:54:14 -0500, Nikos Mavrogiannopoulos wrote:
> Well adding something is easy, but the output of certificate
> information seems already quite bloated with Fingerprint
> (sha1/sha256), Public Key ID (sha1/sha256) and random art. Any ideas
> on what we could remove?

I've always been dubious about the utility of random art.  it seems
*more* difficult for humans to do an exact match on than fingerprints,
and it takes up a lot of space.  I'm not sure what its advantages are,
but if space is at a premium, it looks like the obvious choice to cut
to me.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170222/0d94cc0a/attachment.sig>

From nmav at gnutls.org  Thu Feb 23 13:21:06 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 23 Feb 2017 13:21:06 +0100
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <87efyp96up.fsf@alice.fifthhorseman.net>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
 <8737f8eji2.fsf@alice.fifthhorseman.net> <1524322.zUfcYkciEy@blitz-lx>
 <CAJU7za+h0Wc-d9R26bAJhwY+dJAx0vd2Hbj+aH-7cw40ko7nwA@mail.gmail.com>
 <87efyp96up.fsf@alice.fifthhorseman.net>
Message-ID: <CAJU7za+X2yqu+q1wbdSMU_x3eTX5NTWFkJ9uEw8ky5_gK0HHAg@mail.gmail.com>

On Wed, Feb 22, 2017 at 11:51 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Wed 2017-02-22 04:54:14 -0500, Nikos Mavrogiannopoulos wrote:
>> Well adding something is easy, but the output of certificate
>> information seems already quite bloated with Fingerprint
>> (sha1/sha256), Public Key ID (sha1/sha256) and random art. Any ideas
>> on what we could remove?
>
> I've always been dubious about the utility of random art.  it seems
> *more* difficult for humans to do an exact match on than fingerprints,
> and it takes up a lot of space.  I'm not sure what its advantages are,
> but if space is at a premium, it looks like the obvious choice to cut
> to me.

I kind of agree. Space is not really a premium but I'm of the opinion
that very long output qualifies more as noise rather than something
useful. I've added the ability for certtool to print the key pins in
both 3.5.x and master, and I have removed the random art printing in
master only.

regards,
Nikos


From dkg at fifthhorseman.net  Thu Feb 23 22:21:05 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 23 Feb 2017 16:21:05 -0500
Subject: [gnutls-devel] How to generate sums for Public-Key-Pins HTTP
 header ?
In-Reply-To: <CAJU7za+X2yqu+q1wbdSMU_x3eTX5NTWFkJ9uEw8ky5_gK0HHAg@mail.gmail.com>
References: <6388246.YgqTiBJVue@blitz-lx>
 <CAJU7za+Zx0qaBGkAEWCJNDuE8dATB+mjSRJsChOxm-0+2My5ow@mail.gmail.com>
 <8737f8eji2.fsf@alice.fifthhorseman.net> <1524322.zUfcYkciEy@blitz-lx>
 <CAJU7za+h0Wc-d9R26bAJhwY+dJAx0vd2Hbj+aH-7cw40ko7nwA@mail.gmail.com>
 <87efyp96up.fsf@alice.fifthhorseman.net>
 <CAJU7za+X2yqu+q1wbdSMU_x3eTX5NTWFkJ9uEw8ky5_gK0HHAg@mail.gmail.com>
Message-ID: <87o9xsli2m.fsf@alice.fifthhorseman.net>

On Thu 2017-02-23 07:21:06 -0500, Nikos Mavrogiannopoulos wrote:
> I kind of agree. Space is not really a premium but I'm of the opinion
> that very long output qualifies more as noise rather than something
> useful. I've added the ability for certtool to print the key pins in
> both 3.5.x and master, and I have removed the random art printing in
> master only.

Thanks, Nikos!

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170223/69e1e074/attachment-0001.sig>

From n.mavrogiannopoulos at gmail.com  Fri Feb 24 10:23:31 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 24 Feb 2017 10:23:31 +0100
Subject: [gnutls-devel] moving out from SHA1
Message-ID: <CAJU7zaLfFuwpS5+TcEEZ5FnM_q8g9wUVnd8af4TE_XN=RZNUJA@mail.gmail.com>

Hi,
 Given the first found collision for SHA1, I think it is time to plan
removing it from the trusted set. I do not believe we can do that
today in existing releases, as there is simply too much stuff relying
SHA1. Even for the web PKI which the transition from SHA1 was already
in place, major sites like amazon.com today provide an OCSP response
signed with RSA-SHA1.

So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0
(to be released the second half of this year). That release will
forbid SHA1 from any operation unless special flags to indicate that
broken algorithms are allowed are set. My intention is not to
introduce a new flag to allow SHA1, but utilize the catch-all allow
broken algorithms flag.

In 3.5.x we forbid SHA1 for certificate verification in TLS, for the
NORMAL and above levels, in one of the next few releases (3.5.10 or
3.5.11), but still allow it for TLS handshake signatures. That is, we
take advantage of the verifcation PROFILEs associated with a priority
string keyword, and even though SHA1 is in general acceptable, it will
be refused for certificate verification. At the same time it will
allow applications which rely on SHA1 to continue function, as well as
connection to old servers which use TLS signatures with SHA1 (maybe
even treat OCSP differently to avoid breaking examples with amazon as
above).

6 months to a year later port that to the 3.3.x branch.

What do you think?

regards,
Nikos


From tim.ruehsen at gmx.de  Fri Feb 24 11:17:40 2017
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Fri, 24 Feb 2017 11:17:40 +0100
Subject: [gnutls-devel] moving out from SHA1
In-Reply-To: <CAJU7zaLfFuwpS5+TcEEZ5FnM_q8g9wUVnd8af4TE_XN=RZNUJA@mail.gmail.com>
References: <CAJU7zaLfFuwpS5+TcEEZ5FnM_q8g9wUVnd8af4TE_XN=RZNUJA@mail.gmail.com>
Message-ID: <3362187.SYUDQUnW1s@blitz-lx>

On Friday, February 24, 2017 10:23:31 AM CET Nikos Mavrogiannopoulos wrote:
> Hi,
>  Given the first found collision for SHA1, I think it is time to plan
> removing it from the trusted set. I do not believe we can do that
> today in existing releases, as there is simply too much stuff relying
> SHA1. Even for the web PKI which the transition from SHA1 was already
> in place, major sites like amazon.com today provide an OCSP response
> signed with RSA-SHA1.
> 
> So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0
> (to be released the second half of this year). That release will
> forbid SHA1 from any operation unless special flags to indicate that
> broken algorithms are allowed are set. My intention is not to
> introduce a new flag to allow SHA1, but utilize the catch-all allow
> broken algorithms flag.
> 
> In 3.5.x we forbid SHA1 for certificate verification in TLS, for the
> NORMAL and above levels, in one of the next few releases (3.5.10 or
> 3.5.11), but still allow it for TLS handshake signatures. That is, we
> take advantage of the verifcation PROFILEs associated with a priority
> string keyword, and even though SHA1 is in general acceptable, it will
> be refused for certificate verification. At the same time it will
> allow applications which rely on SHA1 to continue function, as well as
> connection to old servers which use TLS signatures with SHA1 (maybe
> even treat OCSP differently to avoid breaking examples with amazon as
> above).
> 
> 6 months to a year later port that to the 3.3.x branch.
> 
> What do you think?

Thanks, that sounds like a reasonable plan :-)

After reading about the collision yesterday, I already though about impacts 
onto the hopefully-soon-to-be-released wget2.

Just from what read / understood, there is no need to hurry (?):
They said it needed "thousands of CPU years" to generate the collision.
A very rough calculation of the costs:
- $0.01 per GFLOPShour from [1]
- 8760 hours per year
- 3000 CPU years
- assuming 50 GFLOPS per CPU
- 3000 * 8760 * 50 GFLOPShours
- 3000 * 8760 * 50 * $0.01 = 13.140.000$ !!!

Even when assuming 10x less costs per GFLOPShour, it's pretty expensive to 
generate one collision. Or did I misunderstand/misread something basic ?

[1] http://aiimpacts.org/current-flops-prices/

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170224/73b34423/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Fri Feb 24 17:50:48 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 24 Feb 2017 17:50:48 +0100
Subject: [gnutls-devel] moving out from SHA1
In-Reply-To: <3362187.SYUDQUnW1s@blitz-lx>
References: <CAJU7zaLfFuwpS5+TcEEZ5FnM_q8g9wUVnd8af4TE_XN=RZNUJA@mail.gmail.com>
 <3362187.SYUDQUnW1s@blitz-lx>
Message-ID: <1487955048.2088.1.camel@gmail.com>

On Fri, 2017-02-24 at 11:17 +0100, Tim Ruehsen wrote:

> > In 3.5.x we forbid SHA1 for certificate verification in TLS, for
> > the
> > NORMAL and above levels, in one of the next few releases (3.5.10 or
> > 3.5.11), but still allow it for TLS handshake signatures. That is,
> > we
> > take advantage of the verifcation PROFILEs associated with a
> > priority
> > string keyword, and even though SHA1 is in general acceptable, it
> > will
> > be refused for certificate verification. At the same time it will
> > allow applications which rely on SHA1 to continue function, as well
> > as
> > connection to old servers which use TLS signatures with SHA1 (maybe
> > even treat OCSP differently to avoid breaking examples with amazon
> > as
> > above).
> > 
> > 6 months to a year later port that to the 3.3.x branch.
> > 
> > What do you think?
> 
> Thanks, that sounds like a reasonable plan :-)
> 
> After reading about the collision yesterday, I already though about
> impacts?
> onto the hopefully-soon-to-be-released wget2.
> 
> Just from what read / understood, there is no need to hurry (?):
> They said it needed "thousands of CPU years" to generate the
> collision.
> A very rough calculation of the costs:
> - $0.01 per GFLOPShour from [1]
> - 8760 hours per year
> - 3000 CPU years
> - assuming 50 GFLOPS per CPU
> - 3000 * 8760 * 50 GFLOPShours
> - 3000 * 8760 * 50 * $0.01 = 13.140.000$ !!!
> Even when assuming 10x less costs per GFLOPShour, it's pretty
> expensive to?
> generate one collision. Or did I misunderstand/misread something
> basic ?

My understanding is the same; the cost for a collision is quite high.
Note that a collision itself is not catastrophic for signatures and
practical attacks are quite complex, but may still be feasible as with
md5 [0]. These attacks on MD5 showed that short time after the first
collision practical attacks could be mounted by academics.

regards,
Nikos

[0].?https://www.win.tue.nl/hashclash/rogue-ca/



From n.mavrogiannopoulos at gmail.com  Mon Feb 27 12:00:29 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 27 Feb 2017 12:00:29 +0100
Subject: [gnutls-devel] lock-free random generator
In-Reply-To: <CAJU7zaLLNvsF04qpPbtXN9bags+M4_poKrDogXOFs17L-bsiYA@mail.gmail.com>
References: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
 <nnvas6qc45.fsf@armitage.lysator.liu.se>
 <CAJU7zaLLNvsF04qpPbtXN9bags+M4_poKrDogXOFs17L-bsiYA@mail.gmail.com>
Message-ID: <CAJU7zaLsGB-9CgHgms7xCvFHs7CPsgsKLnUjfN8X7mXZMZ0E9g@mail.gmail.com>

On Mon, Feb 20, 2017 at 8:14 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:

>> For the yarrow reseed logic, I think it may be preferable with a global instance.
> If we need yarrow, your recommendation seems to be the right approach.
> However, another thought it has been bugging me lately, is whether we
> need yarrow in gnutls. It looks quite suited for something central
> like /dev/urandom which has several maybe untrusted inputs, but for
> gnutls which seeds from /dev/urandom (or the equivalent system calls),
> having a PRNG which concerns itself with manipulation of input may not
> be adding the security it is perceived to add.

And to answer myself, I do not think we need something complex as
yarrow in gnutls. Older systems may have needed it, but today we can
rely on /dev/urandom and getentropy() interfaces, and as such I no
longer it is necessary to bring that complexity to gnutls.

I've redesigned the whole random generator and provided a high level
description at:
https://gitlab.com/gnutls/gnutls/blob/c6a01ff6c5a44a19b5f6dba9280da96cc28f92d8/doc/cha-crypto.texi#L111

The corresponding code is at:
https://gitlab.com/gnutls/gnutls/merge_requests/259

regards,
Nikos


From nisse at lysator.liu.se  Tue Feb 28 07:57:29 2017
From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=)
Date: Tue, 28 Feb 2017 07:57:29 +0100
Subject: [gnutls-devel] lock-free random generator
In-Reply-To: <CAJU7zaLsGB-9CgHgms7xCvFHs7CPsgsKLnUjfN8X7mXZMZ0E9g@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Mon, 27 Feb 2017 12:00:29
 +0100")
References: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
 <nnvas6qc45.fsf@armitage.lysator.liu.se>
 <CAJU7zaLLNvsF04qpPbtXN9bags+M4_poKrDogXOFs17L-bsiYA@mail.gmail.com>
 <CAJU7zaLsGB-9CgHgms7xCvFHs7CPsgsKLnUjfN8X7mXZMZ0E9g@mail.gmail.com>
Message-ID: <nnd1e2reee.fsf@armitage.lysator.liu.se>

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

> And to answer myself, I do not think we need something complex as
> yarrow in gnutls. Older systems may have needed it, but today we can
> rely on /dev/urandom and getentropy() interfaces, and as such I no
> longer it is necessary to bring that complexity to gnutls.

Makes sense to me too. But do you plan any fallback for other systems? I
guess one could require the use of some separate randomness gathering
daemon.

What about MacOS and Microsoft Windows, do they have something
comparable to /dev/random these days?

Then I'd expect that there are quite some systems out there, where
getting adequate randomness isn't easy. Like small embedded systems, and
it's also unclear to me how /dev/random works on virtual machines. But
just using a mixer like yarrow or fortuna isn't enough, since the tricky
problem is the sourcing of the mixer.

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.


From n.mavrogiannopoulos at gmail.com  Tue Feb 28 09:32:56 2017
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 28 Feb 2017 09:32:56 +0100
Subject: [gnutls-devel] lock-free random generator
In-Reply-To: <nnd1e2reee.fsf@armitage.lysator.liu.se>
References: <CAJU7zaLYKkdaRORjd9dHDgXm2uc53oTp6uxiEL5RAm6S5nUP6A@mail.gmail.com>
 <nnvas6qc45.fsf@armitage.lysator.liu.se>
 <CAJU7zaLLNvsF04qpPbtXN9bags+M4_poKrDogXOFs17L-bsiYA@mail.gmail.com>
 <CAJU7zaLsGB-9CgHgms7xCvFHs7CPsgsKLnUjfN8X7mXZMZ0E9g@mail.gmail.com>
 <nnd1e2reee.fsf@armitage.lysator.liu.se>
Message-ID: <CAJU7zaLg8zea3yMJvbOe02rwQDho3frC_TQgJtXLjSvdRZ5kZA@mail.gmail.com>

On Tue, Feb 28, 2017 at 7:57 AM, Niels M?ller <nisse at lysator.liu.se> wrote:
> Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:
>
>> And to answer myself, I do not think we need something complex as
>> yarrow in gnutls. Older systems may have needed it, but today we can
>> rely on /dev/urandom and getentropy() interfaces, and as such I no
>> longer it is necessary to bring that complexity to gnutls.
>
> Makes sense to me too. But do you plan any fallback for other systems? I
> guess one could require the use of some separate randomness gathering
> daemon.

No. Few releases ago I've dropped support for EGD (entropy gathering
daemon). No-one has complained so I guess such special systems most
likely use specialized libraries rather than "OS" libraries like
gnutls.

> What about MacOS and Microsoft Windows, do they have something
> comparable to /dev/random these days?

Both are supported via their native interfaces. Newer versions of
MacOS have getentropy() and older ones have /dev/urandom. Windows has
CryptGenRandom() for quite some time.

> Then I'd expect that there are quite some systems out there, where
> getting adequate randomness isn't easy. Like small embedded systems, and
> it's also unclear to me how /dev/random works on virtual machines. But
> just using a mixer like yarrow or fortuna isn't enough, since the tricky
> problem is the sourcing of the mixer.

In such small systems, even something like the (now-legacy) EGD would
be insufficient. Each of them would require some custom code, which
could be abstracted as a system call like getentropy() - especially if
that gets into posix. I don't think it makes sense to add code for
such systems without ensuring that it handles a large class of it, or
that at least it is a very common system to ignore.

regards,
Nikos