From nmav at gnutls.org Mon Jan 2 10:41:38 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Jan 2017 10:41:38 +0100 Subject: [gnutls-devel] gnutls_record_send after incomplete gnutls_handshake sends data unencrypted In-Reply-To: <20161231121318.faexsjlb4n5kzamg@argenau.bebt.de> References: <20161231121318.faexsjlb4n5kzamg@argenau.bebt.de> Message-ID: Thank you. That's certainly something to be addressed at least in the new 3.6.x branch. I've created an issue on the gitlab interface: https://gitlab.com/gnutls/gnutls/issues/158 I'm wondering however, whether this could have side-effects, i.e., whether some existing program relied on that behavior to send TLS application data records prior to handshake being complete. regards, Nikos On Sat, Dec 31, 2016 at 1:13 PM, Andreas Metzler wrote: > Hello, > > find attached bug-report http://bugs.debian.org/849807 as reported by > Bernhard R. Link. The related bug against sssd-ldap is > > > cu Andreas > > ----- Forwarded message from "Bernhard R. Link" ----- > Package: libgnutls30 > Version: 3.5.7-3 > Severity: normal > Tags: security > > This bug report is not about wrong behavior if libgnutls is called > correctly but rather about dangerous behaviour if the caller is using > libgnutls incorrectly. > > If a handshake has not yet completed (the caller ignoring > gnutls_handshake return code or the caller having a bug in the handling > of GNUTLS_E_AGAIN) then telling libgnutls to send data causes it to send > it unencrypted. Unless there are cases where might be useful, I think a > security relevelant library like libgnutls should rather catch this > mistake and avoid sending stuff unencrypted. > > Here's an example: > > cat <<'EOF' > example.c > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > #include > > static ssize_t sim_write(gnutls_transport_ptr_t session, const void *data, size_t len) { > bool found = memmem(data, len, "SECRET", 6) != NULL; > printf("Would have written %d bytes%s.\n", (int)len, found?" containing unencrypted plain-text secret":""); > fflush(stdout); > return len; > } > static ssize_t sim_read(gnutls_transport_ptr_t session, void *data, size_t len) { > /* simulate non-blocking io with no incoming data arrived yet */ > gnutls_transport_set_errno(session, EAGAIN); > fflush(stdout); > return -1; > } > > int main() { > gnutls_certificate_credentials_t xcred; > gnutls_session_t session; > int r; > > r = gnutls_global_init(); > assert (r == GNUTLS_E_SUCCESS); > r = gnutls_certificate_allocate_credentials(&xcred); > assert (r == GNUTLS_E_SUCCESS); > r = gnutls_init(&session, GNUTLS_CLIENT); > assert (r == GNUTLS_E_SUCCESS); > r = gnutls_set_default_priority(session); > assert (r == GNUTLS_E_SUCCESS); > r = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, xcred); > assert (r == GNUTLS_E_SUCCESS); > gnutls_session_set_verify_cert(session, "server", 0); > > gnutls_transport_set_ptr(session, session); > gnutls_transport_set_push_function(session, sim_write); > gnutls_transport_set_pull_function(session, sim_read); > > r = gnutls_handshake(session); > assert (r == GNUTLS_E_AGAIN); > /* ignoring the return code and doing the sending: */ > r = gnutls_record_send(session, "SECRET\n", 7); > printf("gnutls_record_send returned %d\n", r); > > return 0; > } > EOF > gcc -Wall -O2 -g example.c -lgnutls && ./a.out > > It outputs: > > Would have written 238 bytes. > Would have written 12 bytes containing unencrypted plain-text secret. > gnutls_record_send returned 7 > > i.e. the data is send unencrypted (looking at the output one sees a > CLIENT_HELO followed by an APPLICATION_DATA packet with unencrypted > content). > > One example where this happens is libldap, which runs into this if > gotten an non-blocking fd (as currently sssd does, see #849756), > causing sssd-ldap to corrently sending passwords unencrypted. > > Bernhard R. Link > -- > ----- End forwarded message ----- > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From n.mavrogiannopoulos at gmail.com Tue Jan 3 08:22:25 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 3 Jan 2017 08:22:25 +0100 Subject: [gnutls-devel] [PATCH] tests: skip tests that requires tools if tools are disabled In-Reply-To: <20161231031417.2213-1-alon.barlev@gmail.com> References: <20161231031417.2213-1-alon.barlev@gmail.com> Message-ID: What I am afraid of such a patch is having a test being skipped when it shouldn't. For which platform do you need this patch? Can it be worked around by not installing the tools instead? On Sat, Dec 31, 2016 at 4:14 AM, Alon Bar-Lev wrote: > building with --disable-tools should not cause test failure. > > Signed-off-by: Alon Bar-Lev > --- > tests/cert-tests/aki | 5 +++++ > tests/cert-tests/certtool | 3 +++ > tests/cert-tests/certtool-long-cn | 4 ++++ > tests/cert-tests/certtool-long-oids | 4 ++++ > tests/cert-tests/crl | 3 +++ > tests/cert-tests/email | 3 +++ > tests/cert-tests/openpgp-cert-parser | 5 +++++ > tests/cert-tests/openpgp-certs | 9 +++++++++ > tests/cert-tests/openpgp-selfsigs | 4 ++++ > tests/cert-tests/pathlen | 3 +++ > tests/cert-tests/pem-decoding | 5 +++++ > tests/cert-tests/pkcs12 | 5 +++++ > tests/cert-tests/pkcs12-utf8 | 5 +++++ > tests/cert-tests/pkcs7-broken-sigs | 3 +++ > tests/cert-tests/privkey-import | 3 +++ > tests/cert-tests/provable-dh | 4 ++++ > tests/cert-tests/provable-dh-default | 4 ++++ > tests/cert-tests/provable-privkey | 4 ++++ > tests/cert-tests/provable-privkey-dsa2048 | 4 ++++ > tests/cert-tests/provable-privkey-gen-default | 4 ++++ > tests/cert-tests/provable-privkey-rsa2048 | 4 ++++ > tests/cert-tests/sha2-dsa-test | 4 ++++ > tests/cert-tests/sha2-test | 4 ++++ > tests/cert-tests/userid | 4 ++++ > tests/fastopen.sh | 8 ++++++++ > tests/key-tests/dsa | 5 +++++ > tests/key-tests/ecdsa | 4 ++++ > tests/key-tests/key-id | 4 ++++ > tests/key-tests/pkcs8 | 4 ++++ > tests/key-tests/pkcs8-decode | 4 ++++ > tests/key-tests/pkcs8-invalid | 4 ++++ > tests/rfc2253-escape-test | 5 +++++ > tests/suite/certtool-pkcs11.sh | 16 ++++++++++++++++ > tests/suite/chain.sh | 4 ++-- > tests/suite/crl-test | 6 ++++++ > tests/suite/eagain.sh | 4 ++++ > tests/suite/invalid-cert.sh | 5 +++++ > tests/suite/pkcs7-cat | 4 ++++ > tests/suite/testdane.sh | 4 ++++ > tests/suite/testpkcs11.sh | 16 ++++++++++++++++ > tests/suite/testrandom.sh | 5 +++++ > tests/suite/testsrn.sh | 8 ++++++++ > 42 files changed, 208 insertions(+), 2 deletions(-) > > diff --git a/tests/cert-tests/aki b/tests/cert-tests/aki > index 3933161..1c72f0d 100755 > --- a/tests/cert-tests/aki > +++ b/tests/cert-tests/aki > @@ -26,6 +26,11 @@ srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > TMPFILE=aki-$$.tmp > DIFF="${DIFF:-diff -b -B}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/certtool b/tests/cert-tests/certtool > index 6a8bcc8..bc8ac7c 100755 > --- a/tests/cert-tests/certtool > +++ b/tests/cert-tests/certtool > @@ -23,6 +23,9 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/certtool-long-cn b/tests/cert-tests/certtool-long-cn > index df430a2..41e7a97 100755 > --- a/tests/cert-tests/certtool-long-cn > +++ b/tests/cert-tests/certtool-long-cn > @@ -27,6 +27,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > outfile="out.$$.pem" > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=3" > fi > diff --git a/tests/cert-tests/certtool-long-oids b/tests/cert-tests/certtool-long-oids > index 31ea796..c2e9559 100755 > --- a/tests/cert-tests/certtool-long-oids > +++ b/tests/cert-tests/certtool-long-oids > @@ -28,6 +28,10 @@ DIFF="${DIFF:-diff -b -B}" > OUTFILE="out.$$.pem" > TMPFILE1="out1.$$.pem" > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=3" > fi > diff --git a/tests/cert-tests/crl b/tests/cert-tests/crl > index 220c656..37e0ed7 100755 > --- a/tests/cert-tests/crl > +++ b/tests/cert-tests/crl > @@ -25,6 +25,9 @@ export TZ="UTC" > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=15" > fi > diff --git a/tests/cert-tests/email b/tests/cert-tests/email > index 8efe18e..ae737eb 100755 > --- a/tests/cert-tests/email > +++ b/tests/cert-tests/email > @@ -23,6 +23,9 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF=$"{DIFF:-diff}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/openpgp-cert-parser b/tests/cert-tests/openpgp-cert-parser > index c12e1be..3a4ab62 100755 > --- a/tests/cert-tests/openpgp-cert-parser > +++ b/tests/cert-tests/openpgp-cert-parser > @@ -25,6 +25,11 @@ set -e > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > > +if ! test -x "${CERTTOOL}"; then > + > + exit 77 > +fi > + > unset RETCODE || true > > fail() { > diff --git a/tests/cert-tests/openpgp-certs b/tests/cert-tests/openpgp-certs > index 3cee344..dfd38d9 100755 > --- a/tests/cert-tests/openpgp-certs > +++ b/tests/cert-tests/openpgp-certs > @@ -24,6 +24,15 @@ srcdir="${srcdir:-.}" > SERV="${SERV:-../../src/gnutls-serv} -q" > CLI="${CLI:-../../src/gnutls-cli}" > DEBUG="" > + > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > +if ! test -x "${CLI}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=15" > fi > diff --git a/tests/cert-tests/openpgp-selfsigs b/tests/cert-tests/openpgp-selfsigs > index 7929e53..1e7c50d 100755 > --- a/tests/cert-tests/openpgp-selfsigs > +++ b/tests/cert-tests/openpgp-selfsigs > @@ -25,6 +25,10 @@ set -e > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > unset RETCODE || true > > fail() { > diff --git a/tests/cert-tests/pathlen b/tests/cert-tests/pathlen > index 687ebc2..0bae79d 100755 > --- a/tests/cert-tests/pathlen > +++ b/tests/cert-tests/pathlen > @@ -25,6 +25,9 @@ set -e > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/pem-decoding b/tests/cert-tests/pem-decoding > index 2977888..b4c2a44 100755 > --- a/tests/cert-tests/pem-decoding > +++ b/tests/cert-tests/pem-decoding > @@ -25,6 +25,11 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/pkcs12 b/tests/cert-tests/pkcs12 > index bd71ded..3b1d2c2 100755 > --- a/tests/cert-tests/pkcs12 > +++ b/tests/cert-tests/pkcs12 > @@ -24,6 +24,11 @@ > srcdir="${srcdir:-.}" > top_builddir="${top_builddir:-../..}" > CERTTOOL="${CERTTOOL:-${top_builddir}/src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=1" > fi > diff --git a/tests/cert-tests/pkcs12-utf8 b/tests/cert-tests/pkcs12-utf8 > index 154d916..52a52f3 100755 > --- a/tests/cert-tests/pkcs12-utf8 > +++ b/tests/cert-tests/pkcs12-utf8 > @@ -27,6 +27,11 @@ > srcdir="${srcdir:-.}" > top_builddir="${top_builddir:-../..}" > CERTTOOL="${CERTTOOL:-${top_builddir}/src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=1" > fi > diff --git a/tests/cert-tests/pkcs7-broken-sigs b/tests/cert-tests/pkcs7-broken-sigs > index 913b2aa..272c009 100755 > --- a/tests/cert-tests/pkcs7-broken-sigs > +++ b/tests/cert-tests/pkcs7-broken-sigs > @@ -23,6 +23,9 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=15" > fi > diff --git a/tests/cert-tests/privkey-import b/tests/cert-tests/privkey-import > index 084094c..41b2e45 100755 > --- a/tests/cert-tests/privkey-import > +++ b/tests/cert-tests/privkey-import > @@ -23,6 +23,9 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-dh b/tests/cert-tests/provable-dh > index 452a725..0676c0f 100755 > --- a/tests/cert-tests/provable-dh > +++ b/tests/cert-tests/provable-dh > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-dh$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-dh-default b/tests/cert-tests/provable-dh-default > index 517e226..43c2ed5 100755 > --- a/tests/cert-tests/provable-dh-default > +++ b/tests/cert-tests/provable-dh-default > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-dh$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-privkey b/tests/cert-tests/provable-privkey > index 4e11c61..3f94f9e 100755 > --- a/tests/cert-tests/provable-privkey > +++ b/tests/cert-tests/provable-privkey > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-privkey$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-privkey-dsa2048 b/tests/cert-tests/provable-privkey-dsa2048 > index fa65f09..f805ab3 100755 > --- a/tests/cert-tests/provable-privkey-dsa2048 > +++ b/tests/cert-tests/provable-privkey-dsa2048 > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-privkey.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-privkey-gen-default b/tests/cert-tests/provable-privkey-gen-default > index d900c8c..3edf343 100755 > --- a/tests/cert-tests/provable-privkey-gen-default > +++ b/tests/cert-tests/provable-privkey-gen-default > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-privkey$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/provable-privkey-rsa2048 b/tests/cert-tests/provable-privkey-rsa2048 > index 3cd7aab..f846476 100755 > --- a/tests/cert-tests/provable-privkey-rsa2048 > +++ b/tests/cert-tests/provable-privkey-rsa2048 > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff}" > OUTFILE=provable-privkey$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/cert-tests/sha2-dsa-test b/tests/cert-tests/sha2-dsa-test > index 955d5ae..8632aef 100755 > --- a/tests/cert-tests/sha2-dsa-test > +++ b/tests/cert-tests/sha2-dsa-test > @@ -31,6 +31,10 @@ TMPFILE=sha2-dsa.$$.tmp > USERFILE=user-dsa.$$.tmp > VERIFYFILE=verify-dsa.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > echo ca > $TEMPLFILE > echo "cn = SHA 256 CA" >> $TEMPLFILE > > diff --git a/tests/cert-tests/sha2-test b/tests/cert-tests/sha2-test > index 9447518..eca12fd 100755 > --- a/tests/cert-tests/sha2-test > +++ b/tests/cert-tests/sha2-test > @@ -32,6 +32,10 @@ TMPFILE=sha2.$$.tmp > USERFILE=user.$$.tmp > VERIFYFILE=verify.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > echo ca > $TEMPLFILE > echo "cn = SHA 512 CA" >> $TEMPLFILE > > diff --git a/tests/cert-tests/userid b/tests/cert-tests/userid > index 912e0c9..e3cdef1 100755 > --- a/tests/cert-tests/userid > +++ b/tests/cert-tests/userid > @@ -23,6 +23,10 @@ > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > "${CERTTOOL}" --certificate-info --infile "${srcdir}/data/userid.pem" >out 2>&1 > RET=$? > if [ ${RET} != 0 ]; then > diff --git a/tests/fastopen.sh b/tests/fastopen.sh > index 2d0bd86..3f636ad 100755 > --- a/tests/fastopen.sh > +++ b/tests/fastopen.sh > @@ -25,6 +25,14 @@ SERV="${SERV:-../src/gnutls-serv${EXEEXT}} -q" > CLI="${CLI:-../src/gnutls-cli${EXEEXT}}" > unset RETCODE > > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > +if ! test -x "${CLI}"; then > + exit 77 > +fi > + > if test "${WINDIR}" != ""; then > exit 77 > fi > diff --git a/tests/key-tests/dsa b/tests/key-tests/dsa > index 17a4472..5f437da 100755 > --- a/tests/key-tests/dsa > +++ b/tests/key-tests/dsa > @@ -27,6 +27,11 @@ DEBUG="" > unset RETCODE > > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/key-tests/ecdsa b/tests/key-tests/ecdsa > index c6e1bd8..c593351 100755 > --- a/tests/key-tests/ecdsa > +++ b/tests/key-tests/ecdsa > @@ -34,6 +34,10 @@ TMPTEMPL=template.$$.tmp > TMPUSER=user.$$.tmp > VERIFYOUT=verify.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > echo ca > $TMPTEMPL > echo "cn = ECDSA SHA 256 CA" >> $TMPTEMPL > > diff --git a/tests/key-tests/key-id b/tests/key-tests/key-id > index f5408b0..4e60034 100755 > --- a/tests/key-tests/key-id > +++ b/tests/key-tests/key-id > @@ -27,6 +27,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > TMPFILE=key-id.$$.tmp > TEMPLFILE=tmpl.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=1" > fi > diff --git a/tests/key-tests/pkcs8 b/tests/key-tests/pkcs8 > index 0bf51a2..7fee476 100755 > --- a/tests/key-tests/pkcs8 > +++ b/tests/key-tests/pkcs8 > @@ -24,6 +24,10 @@ GREP="${GREP:-grep}" > > TMPFILE=tmp-key-ca.$$.p8 > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=1" > fi > diff --git a/tests/key-tests/pkcs8-decode b/tests/key-tests/pkcs8-decode > index b26ff4c..9159d20 100755 > --- a/tests/key-tests/pkcs8-decode > +++ b/tests/key-tests/pkcs8-decode > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > TMPFILE=pkcs8-decode.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/key-tests/pkcs8-invalid b/tests/key-tests/pkcs8-invalid > index bf2cb96..5251f1e 100755 > --- a/tests/key-tests/pkcs8-invalid > +++ b/tests/key-tests/pkcs8-invalid > @@ -25,6 +25,10 @@ CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > DIFF="${DIFF:-diff -b -B}" > TMPFILE=pkcs8-invalid.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/rfc2253-escape-test b/tests/rfc2253-escape-test > index a2c6472..71a4250 100755 > --- a/tests/rfc2253-escape-test > +++ b/tests/rfc2253-escape-test > @@ -23,6 +23,11 @@ > set -e > > CERTTOOL="${CERTTOOL:-../src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=1" > fi > diff --git a/tests/suite/certtool-pkcs11.sh b/tests/suite/certtool-pkcs11.sh > index 7bc0784..20030a8 100755 > --- a/tests/suite/certtool-pkcs11.sh > +++ b/tests/suite/certtool-pkcs11.sh > @@ -26,6 +26,22 @@ SERV="${SERV:-../../src/gnutls-serv${EXEEXT}} -q" > CLI="${CLI:-../../src/gnutls-cli${EXEEXT}}" > RETCODE=0 > > +if ! test -x "${P11TOOL}"; then > + exit 77 > +fi > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > +if ! test -x "${CLI}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute valgrind --leak-check=full" > fi > diff --git a/tests/suite/chain.sh b/tests/suite/chain.sh > index 10868f9..0ec5e2d 100755 > --- a/tests/suite/chain.sh > +++ b/tests/suite/chain.sh > @@ -22,8 +22,8 @@ > > CERTTOOL="${CERTTOOL:-../../../src/certtool${EXEEXT}}" > > -if ! test -z "${VALGRIND}"; then > - VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND} --error-exitcode=15" > +if ! test -x "${CERTTOOL}"; then > + exit 77 > fi > > SUCCESS=" 1 4 7 12 15 16 17 18 24 26 27 30 33 56 57 62 63 " > diff --git a/tests/suite/crl-test b/tests/suite/crl-test > index a2b544c..85c40e5 100755 > --- a/tests/suite/crl-test > +++ b/tests/suite/crl-test > @@ -23,9 +23,15 @@ > srcdir="${srcdir:-.}" > DIFF="${DIFF:-diff}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > + > TMPFILE=long.$$.pem.tmp > > rm -f $TMPFILE > diff --git a/tests/suite/eagain.sh b/tests/suite/eagain.sh > index 1663e7e..bcbaa64 100755 > --- a/tests/suite/eagain.sh > +++ b/tests/suite/eagain.sh > @@ -23,6 +23,10 @@ > srcdir="${srcdir:-.}" > SERV="${SERV:-../../src/gnutls-serv${EXEEXT}} -q" > > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > . "${srcdir}/../scripts/common.sh" > > eval "${GETPORT}" > diff --git a/tests/suite/invalid-cert.sh b/tests/suite/invalid-cert.sh > index 00bf1e4..a13bf88 100755 > --- a/tests/suite/invalid-cert.sh > +++ b/tests/suite/invalid-cert.sh > @@ -22,6 +22,11 @@ > > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/suite/pkcs7-cat b/tests/suite/pkcs7-cat > index a034b0c..1ddfd6b 100755 > --- a/tests/suite/pkcs7-cat > +++ b/tests/suite/pkcs7-cat > @@ -28,6 +28,10 @@ if ! test -z "${VALGRIND}"; then > fi > OUTFILE=out-pkcs7.$$.tmp > > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > . ${srcdir}/../scripts/common.sh > > check_for_datefudge > diff --git a/tests/suite/testdane.sh b/tests/suite/testdane.sh > index 1dd2d90..5bef05d 100755 > --- a/tests/suite/testdane.sh > +++ b/tests/suite/testdane.sh > @@ -22,6 +22,10 @@ srcdir="${srcdir:-.}" > DANETOOL="${DANETOOL:-../../src/danetool${EXEEXT}}" > unset RETCODE > > +if ! test -x "${DANETOOL}"; then > + exit 77 > +fi > + > # Unfortunately it is extremely fragile and fails 99% of the > # time. > if test "${WINDIR}" != ""; then > diff --git a/tests/suite/testpkcs11.sh b/tests/suite/testpkcs11.sh > index f416957..0e0460a 100755 > --- a/tests/suite/testpkcs11.sh > +++ b/tests/suite/testpkcs11.sh > @@ -26,6 +26,22 @@ SERV="${SERV:-../../src/gnutls-serv${EXEEXT}} -q" > CLI="${CLI:-../../src/gnutls-cli${EXEEXT}}" > RETCODE=0 > > +if ! test -x "${P11TOOL}"; then > + exit 77 > +fi > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > +if ! test -x "${CLI}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute valgrind --leak-check=full" > fi > diff --git a/tests/suite/testrandom.sh b/tests/suite/testrandom.sh > index 75e4a40..7e68a71 100755 > --- a/tests/suite/testrandom.sh > +++ b/tests/suite/testrandom.sh > @@ -22,6 +22,11 @@ > > srcdir="${srcdir:-.}" > CERTTOOL="${CERTTOOL:-../../src/certtool${EXEEXT}}" > + > +if ! test -x "${CERTTOOL}"; then > + exit 77 > +fi > + > if ! test -z "${VALGRIND}"; then > VALGRIND="${LIBTOOL:-libtool} --mode=execute ${VALGRIND}" > fi > diff --git a/tests/suite/testsrn.sh b/tests/suite/testsrn.sh > index 446a988..a2b10f4 100755 > --- a/tests/suite/testsrn.sh > +++ b/tests/suite/testsrn.sh > @@ -25,6 +25,14 @@ SERV="${SERV:-../../src/gnutls-serv${EXEEXT}} -q" > CLI="${CLI:-../../src/gnutls-cli${EXEEXT}}" > unset RETCODE > > +if ! test -x "${SERV}"; then > + exit 77 > +fi > + > +if ! test -x "${CLI}"; then > + exit 77 > +fi > + > if test "${WINDIR}" != ""; then > exit 77 > fi > -- > 2.10.2 > From alon.barlev at gmail.com Tue Jan 3 08:51:30 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 3 Jan 2017 09:51:30 +0200 Subject: [gnutls-devel] [PATCH] tests: skip tests that requires tools if tools are disabled In-Reply-To: References: <20161231031417.2213-1-alon.barlev@gmail.com> Message-ID: On 3 January 2017 at 09:22, Nikos Mavrogiannopoulos wrote: > > What I am afraid of such a patch is having a test being skipped when > it shouldn't. For which platform do you need this patch? Can it be > worked around by not installing the tools instead? Hi, I considered several alternatives... 1. Force --enable-tools if --enable-tests in autoconf We skip important tests that can be done for minimal installation. 2. Always build tools but modify automake to conditionally install them based on --enable-tools We have this huge dependency graph of autogen, guile and libxml with their own dependencies. 3. Skip tests that requires tools Test whatever we can without introducing more dependencies for minimal installation. 4. Clone at least certtool which is common to all tests to certtool-test that has no extra dependencies with simpler usage. I chose #3 as it seems to balance between having minimal build with minimal tests and full build and test suites. However, #4 is the best but more than I can contribute right now. I do not see that tests that are being skipped when explicit disabling an option suggests that they should not be skipped... :) Recently, in Gentoo we removed the --enable-tools by default, but people expects that tests will succeed while these currently fails. Maintainers will continue to run tests with tools enabled. Regards, Alon From n.mavrogiannopoulos at gmail.com Tue Jan 3 09:51:45 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 3 Jan 2017 09:51:45 +0100 Subject: [gnutls-devel] [PATCH] tests: skip tests that requires tools if tools are disabled In-Reply-To: References: <20161231031417.2213-1-alon.barlev@gmail.com> Message-ID: On Tue, Jan 3, 2017 at 8:51 AM, Alon Bar-Lev wrote: > I considered several alternatives... > > 1. Force --enable-tools if --enable-tests in autoconf > > We skip important tests that can be done for minimal installation. > > 2. Always build tools but modify automake to conditionally install > them based on --enable-tools > > We have this huge dependency graph of autogen, guile and libxml with > their own dependencies. > > 3. Skip tests that requires tools > > Test whatever we can without introducing more dependencies for minimal > installation. > > 4. Clone at least certtool which is common to all tests to > certtool-test that has no extra dependencies with simpler usage. > > I chose #3 as it seems to balance between having minimal build with > minimal tests and full build and test suites. > However, #4 is the best but more than I can contribute right now. Ok, let's test it. Would you like to submit it as a merge request in gitlab? That will make it run through the CI and we can verify that no test cases are skipped unintentionally. regards, Nikos From alon.barlev at gmail.com Tue Jan 3 16:41:14 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 3 Jan 2017 17:41:14 +0200 Subject: [gnutls-devel] [PATCH] tests: skip tests that requires tools if tools are disabled In-Reply-To: References: <20161231031417.2213-1-alon.barlev@gmail.com> Message-ID: On 3 January 2017 at 10:51, Nikos Mavrogiannopoulos wrote: > > On Tue, Jan 3, 2017 at 8:51 AM, Alon Bar-Lev wrote: > > I considered several alternatives... > > > > 1. Force --enable-tools if --enable-tests in autoconf > > > > We skip important tests that can be done for minimal installation. > > > > 2. Always build tools but modify automake to conditionally install > > them based on --enable-tools > > > > We have this huge dependency graph of autogen, guile and libxml with > > their own dependencies. > > > > 3. Skip tests that requires tools > > > > Test whatever we can without introducing more dependencies for minimal > > installation. > > > > 4. Clone at least certtool which is common to all tests to > > certtool-test that has no extra dependencies with simpler usage. > > > > I chose #3 as it seems to balance between having minimal build with > > minimal tests and full build and test suites. > > However, #4 is the best but more than I can contribute right now. > > Ok, let's test it. Would you like to submit it as a merge request in > gitlab? That will make it run through the CI and we can verify that no > test cases are skipped unintentionally. > > regards, > Nikos Done[1] [1] https://gitlab.com/gnutls/gnutls/merge_requests/216 From msuraev at sysmocom.de Fri Jan 6 12:05:31 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 6 Jan 2017 12:05:31 +0100 Subject: [gnutls-devel] gnutls_rnd_level_t clarification Message-ID: Hi. Could you help me to clarify the meaning of gnutls_rnd_level_t? There's brief description available over at https://www.gnu.org/software/gnutls/reference/gnutls-crypto.html#gnutls-rnd-level-t but as it's a sensitive topic (misunderstanding might have detrimental consequences for security) I'd rather double-check that my understanding is correct. GNUTLS_RND_KEY is the "best quality random" from cryptography point of view while GNUTLS_RND_NONCE is worst. Am I correct in this? Are there any downsides to always using GNUTLS_RND_KEY aside from the risk of depleting OS entropy pool (which would be reported by gnutls_rnd() anyway)? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nmav at gnutls.org Fri Jan 6 17:00:26 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Jan 2017 17:00:26 +0100 Subject: [gnutls-devel] gnutls_rnd_level_t clarification In-Reply-To: References: Message-ID: On Fri, Jan 6, 2017 at 12:05 PM, Max wrote: > Hi. > Could you help me to clarify the meaning of gnutls_rnd_level_t? There's > brief description available over at > https://www.gnu.org/software/gnutls/reference/gnutls-crypto.html#gnutls-rnd-level-t > but as it's a sensitive topic (misunderstanding might have detrimental > consequences for security) I'd rather double-check that my understanding is > correct. > GNUTLS_RND_KEY is the "best quality random" from cryptography point of view > while GNUTLS_RND_NONCE is worst. Yes. In practice GNUTLS_RND_KEY is a generator based on Yarrow, while GNUTLS_RND_NONCE is a fast stream cipher (salsa20 if I remember well). > Am I correct in this? Are there any downsides to always using GNUTLS_RND_KEY > aside from the risk of depleting OS entropy pool (which > would be reported by gnutls_rnd() anyway)? None of them deplete the Linux entropy pool. The nonce generator is much faster than the key one. regards, Nikos From ametzler at bebt.de Sat Jan 7 17:33:24 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 7 Jan 2017 17:33:24 +0100 Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release? Message-ID: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> Hello, Debian/stretch will soon be frozen. Starting February 5 automatic migration from debian/unstable to sid is stopped and updates of packages require approval by release managers. i.e. to enter jessie before this deadline I will need to upload before about January 25. We currently have 3.5.7 plus PKCS#8-encrypted key decoding bugfix (e62aaf4bfaf1a4280db23d9729c2d7fa0fdf97e5 and 441d87cdd5548dc03765cc40c3ffc15eb722b474). Are there other severe issues already fixed in GIT that I should cherrypick? the 3.5.x branch has loads of changes after 3.5.7 and afact only one of these is a feature addition (-with-default-priority-string) but I would rather not ship a GIT snapshot in Debian/stable. ;-) thanks for your assistance, 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 Sun Jan 8 10:28:43 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 8 Jan 2017 10:28:43 +0100 Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release? In-Reply-To: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> References: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> Message-ID: On Sat, Jan 7, 2017 at 5:33 PM, Andreas Metzler wrote: > Hello, > > Debian/stretch will soon be frozen. Starting February 5 automatic > migration from debian/unstable to sid is stopped and updates of packages > require approval by release managers. i.e. to enter jessie before this > deadline I will need to upload before about January 25. > > We currently have 3.5.7 plus PKCS#8-encrypted key decoding bugfix > (e62aaf4bfaf1a4280db23d9729c2d7fa0fdf97e5 and > 441d87cdd5548dc03765cc40c3ffc15eb722b474). Are there other severe issues > already fixed in GIT that I should cherrypick? the 3.5.x branch has > loads of changes after 3.5.7 and afact only one of these is a feature > addition (-with-default-priority-string) but I would rather not ship a > GIT snapshot in Debian/stable. ;-) Hi, My goal is to make a 3.5.x release the next few days, which will be the first marked as stable 3.5.x release. I'd suggest to go with it (or if not possible to get all changes from gnutls_3_5_x branch). regards, Nikos From ametzler at bebt.de Sun Jan 8 18:31:41 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 8 Jan 2017 18:31:41 +0100 Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release? In-Reply-To: References: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> Message-ID: <20170108173141.p7dhtvpocosyos7c@argenau.bebt.de> On 2017-01-08 Nikos Mavrogiannopoulos wrote: > On Sat, Jan 7, 2017 at 5:33 PM, Andreas Metzler wrote: >> Debian/stretch will soon be frozen. Starting February 5 automatic >> migration from debian/unstable to sid is stopped and updates of packages >> require approval by release managers. i.e. to enter jessie before this >> deadline I will need to upload before about January 25. >> We currently have 3.5.7 plus PKCS#8-encrypted key decoding bugfix >> (e62aaf4bfaf1a4280db23d9729c2d7fa0fdf97e5 and >> 441d87cdd5548dc03765cc40c3ffc15eb722b474). Are there other severe issues >> already fixed in GIT that I should cherrypick? the 3.5.x branch has >> loads of changes after 3.5.7 and afact only one of these is a feature >> addition (-with-default-priority-string) but I would rather not ship a >> GIT snapshot in Debian/stable. ;-) > Hi, > My goal is to make a 3.5.x release the next few days, which will be > the first marked as stable 3.5.x release. I'd suggest to go with it > (or if not possible to get all changes from gnutls_3_5_x branch). Splendid. I have just uploaded gnutls_3_5_x GIT HEAD to experimental to get some more testbuilds. Find attached a fix for make dist and a typo fix. 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-make-dist.patch Type: text/x-diff Size: 988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-typo-fix.patch Type: text/x-diff Size: 858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nmav at gnutls.org Mon Jan 9 09:01:02 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 09 Jan 2017 09:01:02 +0100 Subject: [gnutls-devel] gnutls 3.3.26 Message-ID: <1483948862.3495.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.3.26. This is a bug-fix release on the previous stable branch which addresses GNUTLS-SA-2017-1, and GNUTLS-SA-2017-2, while backports some functionality to enable certain PKCS#11 smart card use-cases. * Version 3.3.26 (released 2016-01-09) ** libgnutls: Handle status request responses as optional (following RFC6066). This improves compatibility with implementations not sending these messages (including specific versions of the GnuTLS 3.5.x branch). ** libgnutls: Set limits on the maximum number of alerts handled. That is, applications using gnutls could be tricked into an busy loop if the peer sends continuously alert messages. Applications which set a maximum handshake time (via gnutls_handshake_set_timeout) will eventually recover but others may remain in a busy loops indefinitely. This is related but not identical to CVE-2016-8610, due to the difference in alert handling of the libraries (gnutls delegates that handling to applications). ** libgnutls: Fixed issue in PKCS#12 password encoding, which truncated passwords over 32-characters. Reported by Mario Klebsch. ** libgnutls: Backported functionality allowing to manipulate the IDs of PKCS#11 objects. ** libgnutls: Link to trousers (TPM library) dynamically. Backported TPM key handling improvements from master branch. ** libgnutls: Backported several fixes in PKCS#8 decryption (related to gitlab issue #148). ** libgnutls: Fix double free in certificate information printing. If the PKIX extension proxy was set with a policy language set but no policy specified, that could lead to a double free. [GNUTLS-SA-2017-1] ** libgnutls: Addressed memory leak in server side error path (issue found using oss-fuzz project) ** libgnutls: Addressed memory leaks and an infinite loop in OpenPGP certificate parsing. Fixes by Alex Gaynor. (issues found using oss-fuzz project) ** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing. (issues found using oss-fuzz project) [GNUTLS-SA-2017-2] ** tpmtool: backported the --test-sign option. ** API and ABI modifications: gnutls_pkcs11_obj_set_info: Added gnutls_pkcs11_privkey_generate3: Added gnutls_pkcs11_copy_x509_privkey2: Added gnutls_pkcs11_copy_x509_crt2: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.26.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.26.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 gnutls.org> uid??????????????????Nikos Mavrogiannopoulos 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 nmav at gnutls.org Mon Jan 9 09:17:16 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 09 Jan 2017 09:17:16 +0100 Subject: [gnutls-devel] gnutls 3.5.8 Message-ID: <1483949836.3495.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.8. This is a bug fix release, and is also the release in the 3.5.x marked as stable. As such the 3.5.x fully replaces the (ABI-compatible) 3.4.x branch which will no longer receive updates. Several issues fixed at this release were found using the oss-fuzz project. I'd like to thank Alex Gaynor for bringing gnutls to OSS-FUZZ and fixing issues. The existing fuzzers for gnutls/ are available on the devel/fuzz directory in the master branch. * Version 3.5.8 (released 2016-01-09) ** libgnutls: Ensure that multiple calls to the gnutls_set_priority_* ???functions will not leave the verification profiles field to an ???undefined state. The last call will take precedence. ** libgnutls: Ensure that GNUTLS_E_DECRYPTION_FAIL will be returned ???by PKCS#8 decryption functions when an invalid key is provided. This ???addresses regression on decrypting certain PKCS#8 keys. ** libgnutls: Introduced option to override the default priority string ???used by the library. The intention is to allow support of system-wide ???priority strings (as set with --with-system-priority-file). The ???configure option is --with-default-priority-string. ** libgnutls: Require a valid IV size on all ciphers for PKCS#8 decryption. ???This prevents crashes when decrypting malformed PKCS#8 keys. (issue found using oss-fuzz project) ** libgnutls: Fix crash on the loading of malformed private keys with certain ???parameters set to zero. (issue found using oss-fuzz project) ** libgnutls: Fix double free in certificate information printing. If the PKIX ???extension proxy was set with a policy language set but no policy specified, ???that could lead to a double free. (issue found using oss-fuzz project) ** libgnutls: Addressed memory leaks in client and server side error paths ???(issues found using oss-fuzz project) ** libgnutls: Addressed memory leaks in X.509 certificate printing error paths ???(issues found using oss-fuzz project) ** libgnutls: Addressed memory leaks and an infinite loop in OpenPGP certificate ???parsing. Fixes by Alex Gaynor. (issues found using oss-fuzz project) ** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing. ???(issues found using oss-fuzz project) ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.8.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.8.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 gnutls.org> uid??????????????????Nikos Mavrogiannopoulos 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 nmav at gnutls.org Mon Jan 9 09:25:10 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Jan 2017 09:25:10 +0100 Subject: [gnutls-devel] gnutls 3.5.8 In-Reply-To: <1483949836.3495.3.camel@gnutls.org> References: <1483949836.3495.3.camel@gnutls.org> Message-ID: On Mon, Jan 9, 2017 at 9:17 AM, Nikos Mavrogiannopoulos wrote: > ** libgnutls: Fix double free in certificate information printing. If the PKIX > extension proxy was set with a policy language set but no policy specified, > that could lead to a double free. (issue found using oss-fuzz project) > > ** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing. > (issues found using oss-fuzz project) Note that I forgot to refer to GNUTLS-SA-2017-1 and GNUTLS-SA-2017-2 for these two issues. regards, Nikos From n.mavrogiannopoulos at gmail.com Tue Jan 10 16:47:50 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 10 Jan 2017 16:47:50 +0100 Subject: [gnutls-devel] openpgp removal Message-ID: Hi Ludo, After considering the quality of the OpenPGP support in gnutls, I've decided to speed up the OpenPGP deprecation originally planned in [0]. I've marked all functions as deprecated and modified the manual to list the reasons the openpgp certificate support should not be used in [1]. However, there are some references to OpenPGP in the Guile manual as well. Is it ok to remove them? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/102 [1]. https://gitlab.com/gnutls/gnutls/merge_requests/224 From ludo at gnu.org Sat Jan 14 18:14:46 2017 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sat, 14 Jan 2017 18:14:46 +0100 Subject: [gnutls-devel] openpgp removal In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 10 Jan 2017 16:47:50 +0100") References: Message-ID: <871sw5o96h.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > After considering the quality of the OpenPGP support in gnutls, I've > decided to speed up the OpenPGP deprecation originally planned in [0]. > I've marked all functions as deprecated and modified the manual to > list the reasons the openpgp certificate support should not be used in > [1]. However, there are some references to OpenPGP in the Guile manual > as well. Is it ok to remove them? Yes, sure. I?m disappointed to see OpenPGP support go away, because that?s one of the things that brought me into GnuTLS back in the day, but I can understand your concerns as a maintainer. Thanks, Ludo?. From n.mavrogiannopoulos at gmail.com Sun Jan 15 11:10:30 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 15 Jan 2017 11:10:30 +0100 Subject: [gnutls-devel] openpgp removal In-Reply-To: <871sw5o96h.fsf@gnu.org> References: <871sw5o96h.fsf@gnu.org> Message-ID: On Sat, Jan 14, 2017 at 6:14 PM, Ludovic Court?s wrote: >> After considering the quality of the OpenPGP support in gnutls, I've >> decided to speed up the OpenPGP deprecation originally planned in [0]. >> I've marked all functions as deprecated and modified the manual to >> list the reasons the openpgp certificate support should not be used in >> [1]. However, there are some references to OpenPGP in the Guile manual >> as well. Is it ok to remove them? > Yes, sure. > > I?m disappointed to see OpenPGP support go away, because that?s one of > the things that brought me into GnuTLS back in the day, but I can > understand your concerns as a maintainer. I think it is time to admit that OpenPGP authentication for TLS led nowhere. Although I initially expected to improve web applications, and even more custom applications by providing a simpler verification of trust, neither of these categories benefited in practice. The web of trust push by pgp/gpg, proved to be too complex to deploy on the scale of Internet. When OpenPGP certificates were used with gnutls they were used only as an alternative format for certificates, which was neither simpler nor better than X.509. regards, Nikos From ludo at gnu.org Sun Jan 15 21:41:03 2017 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sun, 15 Jan 2017 21:41:03 +0100 Subject: [gnutls-devel] openpgp removal In-Reply-To: (Nikos Mavrogiannopoulos's message of "Sun, 15 Jan 2017 11:10:30 +0100") References: <871sw5o96h.fsf@gnu.org> Message-ID: <87mvesf44g.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Sat, Jan 14, 2017 at 6:14 PM, Ludovic Court?s wrote: >>> After considering the quality of the OpenPGP support in gnutls, I've >>> decided to speed up the OpenPGP deprecation originally planned in [0]. >>> I've marked all functions as deprecated and modified the manual to >>> list the reasons the openpgp certificate support should not be used in >>> [1]. However, there are some references to OpenPGP in the Guile manual >>> as well. Is it ok to remove them? >> Yes, sure. >> >> I?m disappointed to see OpenPGP support go away, because that?s one of >> the things that brought me into GnuTLS back in the day, but I can >> understand your concerns as a maintainer. > > I think it is time to admit that OpenPGP authentication for TLS led > nowhere. Although I initially expected to improve web applications, > and even more custom applications by providing a simpler verification > of trust, neither of these categories benefited in practice. The web > of trust push by pgp/gpg, proved to be too complex to deploy on the > scale of Internet. When OpenPGP certificates were used with gnutls > they were used only as an alternative format for certificates, which > was neither simpler nor better than X.509. IMO it was ?better? than X.509 in that it did not impose a centralized model with its ?authorities?, which to me is fundamentally flawed. I never thought OpenPGP authentication would displace X.509 on ?the Web? but I thought it was a nice model to build upon for peer-to-peer-style applications (what I looked at in my PhD thesis at the time). That said, over time I?ve also become more skeptical of stretching OpenPGP to such use cases, which are not what it was designed for. Anyway, thank you for launching this experiment quite a few years ago! :-) Ludo?. From nmav at gnutls.org Wed Jan 18 13:53:15 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Jan 2017 13:53:15 +0100 Subject: [gnutls-devel] gnutls_record_send after incomplete gnutls_handshake sends data unencrypted In-Reply-To: References: <20161231121318.faexsjlb4n5kzamg@argenau.bebt.de> Message-ID: On Mon, Jan 2, 2017 at 10:41 AM, Nikos Mavrogiannopoulos wrote: > Thank you. That's certainly something to be addressed at least in the > new 3.6.x branch. I've created an issue on the gitlab interface: > https://gitlab.com/gnutls/gnutls/issues/158 > > I'm wondering however, whether this could have side-effects, i.e., > whether some existing program relied on that behavior to send TLS > application data records prior to handshake being complete. A fix is available at: https://gitlab.com/gnutls/gnutls/merge_requests/228 regards, Nikos From alon.barlev at gmail.com Fri Jan 20 11:07:55 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 20 Jan 2017 12:07:55 +0200 Subject: [gnutls-devel] [PATCH] tests: skip tests that requires tools if tools are disabled In-Reply-To: References: <20161231031417.2213-1-alon.barlev@gmail.com> Message-ID: Hi Nikos, Will these patches be able to make it to 3.5 branch? Will it help if I rebase? Thanks, Alon https://gitlab.com/gnutls/gnutls/commit/276a6ee44d80d4d3b144a78794020c177be8f0ea https://gitlab.com/gnutls/gnutls/commit/9f75df64d3a53e1cbad3eabf266acec7b426869a https://gitlab.com/gnutls/gnutls/commit/9a38264f2065ae97ef3307f47c67bbee2313cb1c https://gitlab.com/gnutls/gnutls/commit/98e49e9d0727d93a58b336dac0a78ce74558e8c8 https://gitlab.com/gnutls/gnutls/commit/41da7be67e0e0f30ea274a6f2d5af700be064b61 https://gitlab.com/gnutls/gnutls/commit/22da6ba5d5d719b125f28718861ad136fa7207af On 3 January 2017 at 17:41, Alon Bar-Lev wrote: > > On 3 January 2017 at 10:51, Nikos Mavrogiannopoulos > wrote: > > > > On Tue, Jan 3, 2017 at 8:51 AM, Alon Bar-Lev wrote: > > > I considered several alternatives... > > > > > > 1. Force --enable-tools if --enable-tests in autoconf > > > > > > We skip important tests that can be done for minimal installation. > > > > > > 2. Always build tools but modify automake to conditionally install > > > them based on --enable-tools > > > > > > We have this huge dependency graph of autogen, guile and libxml with > > > their own dependencies. > > > > > > 3. Skip tests that requires tools > > > > > > Test whatever we can without introducing more dependencies for minimal > > > installation. > > > > > > 4. Clone at least certtool which is common to all tests to > > > certtool-test that has no extra dependencies with simpler usage. > > > > > > I chose #3 as it seems to balance between having minimal build with > > > minimal tests and full build and test suites. > > > However, #4 is the best but more than I can contribute right now. > > > > Ok, let's test it. Would you like to submit it as a merge request in > > gitlab? That will make it run through the CI and we can verify that no > > test cases are skipped unintentionally. > > > > regards, > > Nikos > > Done[1] > > [1] https://gitlab.com/gnutls/gnutls/merge_requests/216 From ametzler at bebt.de Sun Jan 22 16:47:36 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 22 Jan 2017 16:47:36 +0100 Subject: [gnutls-devel] GnuTLS 3.5.8 testsuite error against p11-kit GIT Message-ID: <20170122154736.lunrda2wna67j4jl@argenau.bebt.de> Hello, adding cbf1e42e39c030edb3e2c72ae9b4d7dd7ccf3eea, 726c08847c263af9c9fd8c74aea738612795dbb6 and a126365a49547da6b532210a886bb5d5fc531b77 to p11-kit 0.23.3 causes testsuite errors in gnutls 3.5.8: 8X---------------------------------------------------------------- PASS: pkcs11/pkcs11-privkey FAIL: pkcs11/pkcs11-pubkey-import-rsa FAIL: pkcs11/pkcs11-pubkey-import-ecdsa PASS: pkcs11-import-url-privkey PASS: pkcs11-privkey-fork FAIL: pkcs11/pkcs11-ec-privkey-test PASS: pkcs11-privkey-always-auth [...] FAIL: pkcs11/pkcs11-pubkey-import-rsa ===================================== Testing RSA key The token has been initialized. error in 185: The requested PKCS #11 object is not available FAIL pkcs11/pkcs11-pubkey-import-rsa (exit status: 1) FAIL: pkcs11/pkcs11-pubkey-import-ecdsa ======================================= Testing ECDSA key The token has been initialized. error in 185: The requested PKCS #11 object is not available FAIL pkcs11/pkcs11-pubkey-import-ecdsa (exit status: 1) FAIL: pkcs11/pkcs11-ec-privkey-test =================================== The token has been initialized. error in 191: The requested PKCS #11 object is not available FAIL pkcs11/pkcs11-ec-privkey-test (exit status: 1) 8X---------------------------------------------------------------- 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 dereks at lifeofadishwasher.com Mon Jan 23 02:13:38 2017 From: dereks at lifeofadishwasher.com (Derek Schrock) Date: Sun, 22 Jan 2017 20:13:38 -0500 Subject: [gnutls-devel] gnutls 3.5.8 In-Reply-To: References: <1483949836.3495.3.camel@gnutls.org> Message-ID: <20170123011338.GA75261@ircbsd.lifeofadishwasher.com> On Mon, Jan 09, 2017 at 03:25:10AM EST, Nikos Mavrogiannopoulos wrote: > On Mon, Jan 9, 2017 at 9:17 AM, Nikos Mavrogiannopoulos wrote: > > > ** libgnutls: Fix double free in certificate information printing. If the PKIX > > extension proxy was set with a policy language set but no policy specified, > > that could lead to a double free. (issue found using oss-fuzz project) > > > > ** libgnutls: Addressed invalid memory accesses in OpenPGP certificate parsing. > > (issues found using oss-fuzz project) > > Note that I forgot to refer to GNUTLS-SA-2017-1 and GNUTLS-SA-2017-2 for these > two issues. > > regards, > Nikos > Was there a 3.4.x release for SA 2017-1/2? I see 3.3.x and 3.5.x however no 3.4.x. Is 3.4.x not effected by the two SAs? From nmav at gnutls.org Mon Jan 23 08:55:21 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Jan 2017 08:55:21 +0100 Subject: [gnutls-devel] GnuTLS 3.5.8 testsuite error against p11-kit GIT In-Reply-To: <20170122154736.lunrda2wna67j4jl@argenau.bebt.de> References: <20170122154736.lunrda2wna67j4jl@argenau.bebt.de> Message-ID: On Sun, Jan 22, 2017 at 4:47 PM, Andreas Metzler wrote: > Hello, > > adding cbf1e42e39c030edb3e2c72ae9b4d7dd7ccf3eea, > 726c08847c263af9c9fd8c74aea738612795dbb6 and > a126365a49547da6b532210a886bb5d5fc531b77 to p11-kit 0.23.3 causes > testsuite errors in gnutls 3.5.8: Would reverting cbf1e42e39c030edb3e2c72ae9b4d7dd7ccf3eea address that? My guess is that the moving of the pin-value to query component broke the gnutls test suite. Although that's easily fixable, it may have impact on existing setups, preventing an out-of-the-box upgrade of p11-kit. Checking the pkcs11uri draft's history it seems that the query attributes came quite late in its definition and at least myself didn't realize that until now. Maybe we should introduce a compatibility for attributes like pin-value which have no security repercussions like the ones mentioned in the commit message. https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-13.txt regards, Nikos From nmav at gnutls.org Mon Jan 23 20:01:52 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Jan 2017 20:01:52 +0100 Subject: [gnutls-devel] gnutls 3.5.8 In-Reply-To: <20170123011338.GA75261@ircbsd.lifeofadishwasher.com> References: <1483949836.3495.3.camel@gnutls.org> <20170123011338.GA75261@ircbsd.lifeofadishwasher.com> Message-ID: <1485198112.2203.1.camel@gnutls.org> On Sun, 2017-01-22 at 20:13 -0500, Derek Schrock wrote: > On Mon, Jan 09, 2017 at 03:25:10AM EST, Nikos Mavrogiannopoulos > wrote: > > On Mon, Jan 9, 2017 at 9:17 AM, Nikos Mavrogiannopoulos > gnutls.org> wrote: > > > > > ** libgnutls: Fix double free in certificate information > > > printing. If the PKIX > > > ???extension proxy was set with a policy language set but no > > > policy specified, > > > ???that could lead to a double free. (issue found using oss-fuzz > > > project) > > > > > > ** libgnutls: Addressed invalid memory accesses in OpenPGP > > > certificate parsing. > > > ???(issues found using oss-fuzz project) > > > > Note that I forgot to refer to GNUTLS-SA-2017-1 and GNUTLS-SA-2017- > > 2 for these > > two issues. > > > > regards, > > Nikos > > > > Was there a 3.4.x release for SA 2017-1/2???I see 3.3.x and 3.5.x > however no 3.4.x.??Is 3.4.x not effected by the two SAs? Hi, The 3.4.x releases are indeed affected, however 3.5.8 is a drop in replacement and you can use that release instead. My goal with that is to reduce the cost of maintaining overlapping/fully compatible release branches. regards, Nikos From n.mavrogiannopoulos at gmail.com Sat Jan 28 12:21:21 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 28 Jan 2017 12:21:21 +0100 Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release? In-Reply-To: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> References: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> Message-ID: <1485602481.2351.1.camel@gmail.com> On Sat, 2017-01-07 at 17:33 +0100, Andreas Metzler wrote: > Hello, > > Debian/stretch will soon be frozen. Starting February 5 automatic > migration from debian/unstable to sid is stopped and updates of > packages > require approval by release managers. i.e. to enter jessie before > this > deadline I will need to upload before about January 25. 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/ef78a758cb899609d7eb4578017bc752272cb423 regards, Nikos [0]. https://www.plesk.com/blog/what-is-the-problem-with-s/ From ametzler at bebt.de Sat Jan 28 18:33:57 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 28 Jan 2017 18:33:57 +0100 Subject: [gnutls-devel] GnuTLS 3.5.7 - any patches should I pick for Debian/stretch release? In-Reply-To: <1485602481.2351.1.camel@gmail.com> References: <20170107163324.jkx6fsqg56djp22t@argenau.bebt.de> <1485602481.2351.1.camel@gmail.com> Message-ID: <20170128173357.kxra5lkodwcfxxs5@argenau.bebt.de> On 2017-01-28 Nikos Mavrogiannopoulos 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/ef78a758cb899609d7eb4578017bc752272cb423 [...] 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. 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'