From nmav at gnutls.org  Tue Dec  1 10:39:34 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Dec 2015 10:39:34 +0100
Subject: [gnutls-devel] pkcs11_common(NULL) issue in 3.4.6
In-Reply-To: <565CD1F4.1010808@oracle.com>
References: <565CD1F4.1010808@oracle.com>
Message-ID: <CAJU7za+oM3OOnXS236MKx4jiGKGhuTj44JLHFvq=O3ouh9qCAg@mail.gmail.com>

On Mon, Nov 30, 2015 at 11:47 PM, Jenny Yung <jenny.yung at oracle.com> wrote:
> Hi,
> This issue is found in 3.4.6.
> Currently in src/tpmtool.c, pkcs11_common(NULL) is being called when PKCS11
> is not enabled. We have p11 disabled in our configure options, so it was
> unable to build.

Hi,
 What is your use case? Most likely tpmtool will not operate properly
if PKCS 11 is disabled as it utilizes its PIN callbacks. I think I'll
disable its build entirely in that case.

regards,
Nikos


From jan.vcelak at nic.cz  Fri Dec  4 18:42:35 2015
From: jan.vcelak at nic.cz (Jan =?utf-8?B?VsSNZWzDoWs=?=)
Date: Fri, 04 Dec 2015 18:42:35 +0100
Subject: [gnutls-devel] memory leak,
	gnutls_pubkey_import_privkey() with PKCS 11
Message-ID: <2334794.tS9xeWYg2r@pc-cznic4>

Hello everyone.

I'm working on the HSM support in Knot DNS using the PKCS #11 interface of
GnuTLS. And I believe I found a memory leak in the library:

==8406== 2,048 bytes in 1 blocks are definitely lost in loss record 16 of 21
==8406==    at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8406==    by 0x4E98AEF: pkcs11_read_pubkey (pkcs11.c:1526)
==8406==    by 0x4E9FE83: _pkcs11_privkey_get_pubkey (pkcs11_privkey.c:1025)
==8406==    by 0x4E89D67: _gnutls_privkey_get_mpis (gnutls_privkey.c:213)
==8406==    by 0x4E89EB6: _gnutls_privkey_get_public_mpis (gnutls_privkey.c:240)
==8406==    by 0x400D36: main (main.c:37)
==8406== 
==8406== 2,048 bytes in 1 blocks are definitely lost in loss record 17 of 21
==8406==    at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8406==    by 0x4E98B03: pkcs11_read_pubkey (pkcs11.c:1530)
==8406==    by 0x4E9FE83: _pkcs11_privkey_get_pubkey (pkcs11_privkey.c:1025)
==8406==    by 0x4E89D67: _gnutls_privkey_get_mpis (gnutls_privkey.c:213)
==8406==    by 0x4E89EB6: _gnutls_privkey_get_public_mpis (gnutls_privkey.c:240)
==8406==    by 0x400D36: main (main.c:37)

This is the reproducer. It's just a private key import into the abstract
public key structure, and then construction of a maching public key:

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>

#include <gnutls/abstract.h>
#include <gnutls/pkcs11.h>

int main(int argc, char *argv[])
{
	if (argc != 2) {
		fprintf(stderr, "usage: %s <key-url>\n", argv[0]);
		return 1;
	}

	const char *url = argv[1];

	int r;

	r = gnutls_pkcs11_init(GNUTLS_PKCS11_FLAG_MANUAL, NULL);
	assert(r == 0);
	gnutls_global_init();

	r = gnutls_pkcs11_add_provider("libsofthsm2.so", NULL);
	assert(r == 0);

	gnutls_privkey_t key;
	r = gnutls_privkey_init(&key);
	assert(r == 0);

	gnutls_privkey_import_pkcs11_url(key, url);
	assert(r == 0);

	gnutls_pubkey_t pubkey;
	r = gnutls_pubkey_init(&pubkey);
	assert(r == 0);

	r = gnutls_pubkey_import_privkey(pubkey, key, 0, 0);  // <-- LEAK
	assert(r == 0);

	gnutls_pubkey_deinit(pubkey);
	gnutls_privkey_deinit(key);

	gnutls_pkcs11_deinit();
	gnutls_global_deinit();

	return 0;
}

I'm using SoftHSM 2 for testing. You can use to following commands to
setup the token:

% mkdir -p /tmp/softhsm
% cat > /tmp/softhsm/softhsm.conf << EOF
directories.tokendir = /tmp/softhsm
directories.backend = db
log.debug = INFO
EOF
% export SOFTHSM2_CONF=/tmp/softhsm/softhsm.conf
% softhsm2-util --init --slot 0 --label foo --pin 1234 --so-pin 123456
% p11tool --generate-rsa --label bar --login "pkcs11:token=foo;pin-value=1234"

Then just run the reproducer:

% gcc -std=gnu99 -Wall -g $(pkg-config --cflags --libs gnutls) ./reproducer.c
% valgrind --leak-check=full \
  ./a.out "pkcs11:token=foo;object=bar;pin-value=1234"

And some more details about my enviroment:

% rpm -q gnutls softhsm valgrind
gnutls-3.4.7-1.fc23.x86_64
softhsm-2.0.0rc1-3.fc23.x86_64
valgrind-3.11.0-1.fc23.x86_64

Please, can you take a look at it?

Thank you.

Cheers,

Jan


From ametzler at bebt.de  Sat Dec  5 09:03:14 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 5 Dec 2015 09:03:14 +0100
Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults
In-Reply-To: <20151126183439.GA2736@downhill.g.la>
References: <20151124184945.GB4525@downhill.g.la> <87k2p5yp96.fsf@gnu.org>
 <20151126183439.GA2736@downhill.g.la>
Message-ID: <20151205080314.GA1142@argenau.bebt.de>

On 2015-11-26 Andreas Metzler <ametzler at bebt.de> wrote:
> On 2015-11-26 Ludovic Court?s <ludo at gnu.org> wrote:
> > Andreas Metzler <ametzler at bebt.de> skribis:
> >> on amd64 there are segfaults in the guile testsuite:

> >> (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.19/guile/tests$ while make  t
> >> est-suite.log TEST_LOGS=openpgp-auth.scm.log ; do sleep .3 ; rm  openpgp-auth.scm.log openpgp-auth.scm.trs  test-suite.log ; done
> >> PASS: openpgp-auth.scm
> >> [...]
> >> ../../build-aux/test-driver: line 107: 16038 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
> >> FAIL: openpgp-auth.scm

> > So this test does not fail systematically, right?

> It does not fail on every invocation, but when I uploaded 3.3.19 and
> 3.4.7 on Sunday both autobuilds failed.
[...]

Hello,

I have now switched to another (faster) machine.

1.
(sid)ametzler at argenau:/dev/shm/GNUTLS/gnutls-3.3.19/guile/tests$ j=0 ; rm openpgp-auth.scm.log openpgp-auth.scm.trs  test-suite.log ; while make  test-suite.log TEST_LOGS=openpgp-auth.scm.log ; do j=$(($j+1)) ; sleep .1 ; rm openpgp-auth.scm.log openpgp-auth.scm.trs  test-suite.log ; done ; echo xxx $j

usually fails on the first invocation.

2.
(sid)ametzler at argenau:/dev/shm/GNUTLS/gnutls-3.3.19/guile/tests$ j=0 ; while env GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ./openpgp-auth.scm ; do sleep .01 ; j=$(($j+1)); done ; echo $j

takes 1 to 60 runs to fail.

3.
(sid)ametzler at argenau:/dev/shm/GNUTLS/gnutls-3.3.19/guile/tests$ j=0 ; while env GUILE_AUTO_COMPILE=0 GUILE_LOAD_PATH="/dev/shm/GNUTLS/gnutls-3.3.19/guile/modules" GNUTLS_GUILE_EXTENSION_DIR="/dev/shm/GNUTLS/gnutls-3.3.19/guile/src" guile -L . ./openpgp-auth.scm ; do sleep .01 ; j=$(($j+1)); done ; echo $j

takes over a 100 runs to fail

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 jan.vcelak at nic.cz  Sun Dec  6 00:46:38 2015
From: jan.vcelak at nic.cz (Jan Vcelak)
Date: Sun,  6 Dec 2015 00:46:38 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
Message-ID: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>

Hello everyone.

I've encountered a problem when constructing a public key from a private key
stored in a PKCS #11 token.

This is a snippet of the code I'm using:

  gnutls_privkey_t key;
  gnutls_privkey_init(&key);
  gnutls_privkey_import_pkcs11_url(key, url);
  
  gnutls_pubkey_t pubkey;
  gnutls_pubkey_init(&pubkey);
  gnutls_pubkey_import_privkey(pubkey, key, 0, 0);

Actually, there are two problems with this code.

First, there is a bug in the _pkcs11_privkey_get_pubkey() code. An invalid
variable is passed as a function argument for pkcs11_read_pubkey(). By chance,
the values of these variables match for RSA keys. The execution path is just
wrong for any other algorithm. The following patch fixes this problem.

Second, the patch doesn't really solve the problem. This cannot work for
anything else than RSA:

The RSA is special that the public key parameters are a subset of it's private
key parameters. So we can read the public attributes from a private key object
in the token and get the public key.

For ECDSA (and probably DSA), the private key object doesn't contain the
public attributes. So the gnutls_pubkey_import_privkey() call will fail.

I'm not sure what is the correct solution. I have three possible ones:

 1. Don't support gnutls_pubkey_import_privkey() for PKCS #11 non-RSA keys.

 2. Check if the private key object contains optional CKA_PUBLIC_KEY_INFO
    and try to construct the key from it's content.

 3. Use the private key object URL, replace type=private with type=public
    (if it's there), and use the new URL to retrieve the public key from
    the token.

Any ideas?

Cheers,

Jan


From jan.vcelak at nic.cz  Sun Dec  6 00:46:39 2015
From: jan.vcelak at nic.cz (Jan Vcelak)
Date: Sun,  6 Dec 2015 00:46:39 +0100
Subject: [gnutls-devel] [PATCH] pkcs11: fix passing of incorrect variable in
	privkey_get_pubkey
In-Reply-To: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
Message-ID: <1449359199-15823-2-git-send-email-jan.vcelak@nic.cz>

The code worked for RSA because the content of the variables matched.
But it doesn't match for ECC.

CKM_RSA_PKCS_KEY_PAIR_GEN (0x0) == CKK_RSA (0x0)
CKM_ECDSA_KEY_PAIR_GEN (0x1040) != CKK_ECDSA (0x3)

Signed-off-by: Jan Vcelak <jan.vcelak at nic.cz>
---
 lib/pkcs11_privkey.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/pkcs11_privkey.c b/lib/pkcs11_privkey.c
index 935ee8a..c1ab560 100644
--- a/lib/pkcs11_privkey.c
+++ b/lib/pkcs11_privkey.c
@@ -1022,7 +1022,7 @@ _pkcs11_privkey_get_pubkey (gnutls_pkcs11_privkey_t pkey, gnutls_pubkey_t *pub,
 	obj->pk_algorithm = gnutls_pkcs11_privkey_get_pk_algorithm(pkey, 0);
 	obj->type = GNUTLS_PKCS11_OBJ_PUBKEY;
 	mech.mechanism = pk_to_genmech(obj->pk_algorithm, &key_type);
-	ret = pkcs11_read_pubkey(pkey->sinfo.module, pkey->sinfo.pks, pkey->ref, mech.mechanism, obj->pubkey);
+	ret = pkcs11_read_pubkey(pkey->sinfo.module, pkey->sinfo.pks, pkey->ref, key_type, obj->pubkey);
 	if (ret < 0) {
 		gnutls_assert();
 		goto cleanup;
-- 
2.5.0



From n.mavrogiannopoulos at gmail.com  Sun Dec  6 10:40:09 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 06 Dec 2015 10:40:09 +0100
Subject: [gnutls-devel] [PATCH] pkcs11: fix passing of incorrect
 variable in privkey_get_pubkey
In-Reply-To: <1449359199-15823-2-git-send-email-jan.vcelak@nic.cz>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <1449359199-15823-2-git-send-email-jan.vcelak@nic.cz>
Message-ID: <1449394809.842.1.camel@gmail.com>

On Sun, 2015-12-06 at 00:46 +0100, Jan Vcelak wrote:
> The code worked for RSA because the content of the variables matched.
> But it doesn't match for ECC.
> 
> CKM_RSA_PKCS_KEY_PAIR_GEN (0x0) == CKK_RSA (0x0)
> CKM_ECDSA_KEY_PAIR_GEN (0x1040) != CKK_ECDSA (0x3)

Thank you, Applied.




From n.mavrogiannopoulos at gmail.com  Sun Dec  6 11:25:57 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 06 Dec 2015 11:25:57 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
Message-ID: <1449397557.842.7.camel@gmail.com>

On Sun, 2015-12-06 at 00:46 +0100, Jan Vcelak wrote:
> Hello everyone.

> I've encountered a problem when constructing a public key from a 
> private key
> stored in a PKCS #11 token.
> This is a snippet of the code I'm using:
>   gnutls_privkey_t key;
>   gnutls_privkey_init(&key);
>   gnutls_privkey_import_pkcs11_url(key, url);
>   
>   gnutls_pubkey_t pubkey;
>   gnutls_pubkey_init(&pubkey);
>   gnutls_pubkey_import_privkey(pubkey, key, 0, 0);

> 
> [...]
> Second, the patch doesn't really solve the problem. This cannot work 
> for anything else than RSA:

> The RSA is special that the public key parameters are a subset of 
> it's private key parameters. So we can read the public attributes 
> from a private key object in the token and get the public key.
> 
> For ECDSA (and probably DSA), the private key object doesn't contain 
> the public attributes. So the gnutls_pubkey_import_privkey() call 
> will fail.

Interesting. As I understand you are referring to the CKA_EC_POINT
attribute which does not need to be included in private key objects. 

> I'm not sure what is the correct solution. I have three possible 
> ones:
>  1. Don't support gnutls_pubkey_import_privkey() for PKCS #11 non-RSA 
> keys.

For now, indeed you cannot use this function to get public keys out of
PKCS #11 private keys. You'll have to rely on the equivalent
CKO_PUBLIC_KEY object (if it is present).

For a fix to make gnutls_pubkey_import_privkey() available with all
keys, an alternative is for the import function to reconstruct the
public key from the private key. I'll check how feasible is that.

regards,
Nikos



From jan.vcelak at nic.cz  Sun Dec  6 22:23:31 2015
From: jan.vcelak at nic.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=)
Date: Sun, 6 Dec 2015 22:23:31 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <1449397557.842.7.camel@gmail.com>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <1449397557.842.7.camel@gmail.com>
Message-ID: <5664A753.700@nic.cz>

On 6.12.2015 11:25, Nikos Mavrogiannopoulos wrote:
> Interesting. As I understand you are referring to the CKA_EC_POINT
> attribute which does not need to be included in private key objects. 

Exactly.

> For a fix to make gnutls_pubkey_import_privkey() available with all
> keys, an alternative is for the import function to reconstruct the
> public key from the private key. I'll check how feasible is that.

I don't think this will be possible. The private key material is present
in the token, so the token would have to do the reconstruction.

Cheers,

Jan



From n.mavrogiannopoulos at gmail.com  Mon Dec  7 09:24:23 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 7 Dec 2015 09:24:23 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <5664A753.700@nic.cz>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <1449397557.842.7.camel@gmail.com> <5664A753.700@nic.cz>
Message-ID: <CAJU7zaLe-APZLiLQLZPmFaTHWQob7vqVZZocrNfhbQzm8fVFzw@mail.gmail.com>

On Sun, Dec 6, 2015 at 10:23 PM, Jan V?el?k <jan.vcelak at nic.cz> wrote:
> On 6.12.2015 11:25, Nikos Mavrogiannopoulos wrote:
>> Interesting. As I understand you are referring to the CKA_EC_POINT
>> attribute which does not need to be included in private key objects.
>> For a fix to make gnutls_pubkey_import_privkey() available with all
>> keys, an alternative is for the import function to reconstruct the
>> public key from the private key. I'll check how feasible is that.
> I don't think this will be possible. The private key material is present
> in the token, so the token would have to do the reconstruction.

Indeed, so importing from the CKO_PUBLIC_KEY object seems the only
reasonable option. Typically when loading from a URL it should have
the same URL as the private key, but different object type.

regards,
Nikos


From kurt at roeckx.be  Wed Dec  9 23:29:21 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 9 Dec 2015 23:29:21 +0100
Subject: [gnutls-devel] Incorrect implementation of path length constraints?
Message-ID: <20151209222921.GA23871@roeckx.be>

Hi,

When trying to connect to a website that has a pathlength
constraint I'm getting an error message while it works with
OpenSSL and NSS.  I think there might be a misinterpretation of
the pathlength contraint.  From rfc5280:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)  A pathLenConstraint of zero indicates that no non-
   self-issued intermediate CA certificates may follow in a valid
   certification path.  Where it appears, the pathLenConstraint field
   MUST be greater than or equal to zero.  Where pathLenConstraint does
   not appear, no limit is imposed.

I think GnuTLS currently doesn't allow the intermediate CA to sign
the end entity certificte when the length is set to 0.

A test site it www.abb.com.


Kurt



From ametzler at bebt.de  Sat Dec 12 16:09:23 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 12 Dec 2015 16:09:23 +0100
Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults
In-Reply-To: <20151205080314.GA1142@argenau.bebt.de>
References: <20151124184945.GB4525@downhill.g.la> <87k2p5yp96.fsf@gnu.org>
 <20151126183439.GA2736@downhill.g.la>
 <20151205080314.GA1142@argenau.bebt.de>
Message-ID: <20151212150923.GB1213@argenau.bebt.de>

On 2015-12-05 Andreas Metzler <ametzler at bebt.de> wrote:
[...]
> 3.
> (sid)ametzler at argenau:/dev/shm/GNUTLS/gnutls-3.3.19/guile/tests$ j=0 ; while env GUILE_AUTO_COMPILE=0 GUILE_LOAD_PATH="/dev/shm/GNUTLS/gnutls-3.3.19/guile/modules" GNUTLS_GUILE_EXTENSION_DIR="/dev/shm/GNUTLS/gnutls-3.3.19/guile/src" guile -L . ./openpgp-auth.scm ; do sleep .01 ; j=$(($j+1)); done ; echo $j

> takes over a 100 runs to fail

I have also managed to get a crash in gdb using a loop and a
hand-built guile with debugging symbols.

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: gdb.log.gz
Type: application/gzip
Size: 11906 bytes
Desc: not available
URL: </pipermail/attachments/20151212/facbfb77/attachment-0001.bin>

From n.mavrogiannopoulos at gmail.com  Sun Dec 13 17:42:24 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 13 Dec 2015 17:42:24 +0100
Subject: [gnutls-devel] Incorrect implementation of path length
 constraints?
In-Reply-To: <20151209222921.GA23871@roeckx.be>
References: <20151209222921.GA23871@roeckx.be>
Message-ID: <1450024944.31642.4.camel@gmail.com>

On Wed, 2015-12-09 at 23:29 +0100, Kurt Roeckx wrote:
> Hi,
> 
> When trying to connect to a website that has a pathlength
> constraint I'm getting an error message while it works with
> OpenSSL and NSS.  I think there might be a misinterpretation of
> the pathlength contraint.  From rfc5280:

> A test site it www.abb.com.

Hi Kurt,
 I haven't checked the details by trying this website with a recent
gnutls version it works. Which version of gnutls do you test with?

regards,
Nikos



From kurt at roeckx.be  Sun Dec 13 17:58:33 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 13 Dec 2015 17:58:33 +0100
Subject: [gnutls-devel] Incorrect implementation of path length
 constraints?
In-Reply-To: <1450024944.31642.4.camel@gmail.com>
References: <20151209222921.GA23871@roeckx.be>
 <1450024944.31642.4.camel@gmail.com>
Message-ID: <20151213165833.GA21361@roeckx.be>

On Sun, Dec 13, 2015 at 05:42:24PM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2015-12-09 at 23:29 +0100, Kurt Roeckx wrote:
> > Hi,
> > 
> > When trying to connect to a website that has a pathlength
> > constraint I'm getting an error message while it works with
> > OpenSSL and NSS.  I think there might be a misinterpretation of
> > the pathlength contraint.  From rfc5280:
> 
> > A test site it www.abb.com.
> 
> Hi Kurt,
>  I haven't checked the details by trying this website with a recent
> gnutls version it works. Which version of gnutls do you test with?

I'm using 3.3.15.


Kurt



From ametzler at bebt.de  Sun Dec 13 19:31:03 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 13 Dec 2015 19:31:03 +0100
Subject: [gnutls-devel] Incorrect implementation of path length
 constraints?
In-Reply-To: <20151213165833.GA21361@roeckx.be>
References: <20151209222921.GA23871@roeckx.be>
 <1450024944.31642.4.camel@gmail.com>
 <20151213165833.GA21361@roeckx.be>
Message-ID: <20151213183103.GC1239@argenau.bebt.de>

On 2015-12-13 Kurt Roeckx <kurt at roeckx.be> wrote:
> On Sun, Dec 13, 2015 at 05:42:24PM +0100, Nikos Mavrogiannopoulos wrote:
>> On Wed, 2015-12-09 at 23:29 +0100, Kurt Roeckx wrote:
[...]
>>> A test site it www.abb.com.
[...]
>>  I haven't checked the details by trying this website with a recent
>> gnutls version it works. Which version of gnutls do you test with?

> I'm using 3.3.15.

Hello,

does this show up as a connection error? gnutls-cli from both 3.4.6
and 3.3.18 connect successfully.

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 kurt at roeckx.be  Sun Dec 13 20:16:15 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 13 Dec 2015 20:16:15 +0100
Subject: [gnutls-devel] Incorrect implementation of path length
 constraints?
In-Reply-To: <20151213183103.GC1239@argenau.bebt.de>
References: <20151209222921.GA23871@roeckx.be>
 <1450024944.31642.4.camel@gmail.com>
 <20151213165833.GA21361@roeckx.be>
 <20151213183103.GC1239@argenau.bebt.de>
Message-ID: <20151213191615.GA25331@roeckx.be>

On Sun, Dec 13, 2015 at 07:31:03PM +0100, Andreas Metzler wrote:
> On 2015-12-13 Kurt Roeckx <kurt at roeckx.be> wrote:
> > On Sun, Dec 13, 2015 at 05:42:24PM +0100, Nikos Mavrogiannopoulos wrote:
> >> On Wed, 2015-12-09 at 23:29 +0100, Kurt Roeckx wrote:
> [...]
> >>> A test site it www.abb.com.
> [...]
> >>  I haven't checked the details by trying this website with a recent
> >> gnutls version it works. Which version of gnutls do you test with?
> 
> > I'm using 3.3.15.
> 
> Hello,
> 
> does this show up as a connection error? gnutls-cli from both 3.4.6
> and 3.3.18 connect successfully.

So I just tried the 3.3.18 version instead, and that does work
properly.  This is what I see with 3.3.15 (and 3.3.8):
$ gnutls-cli www.abb.com
Processed 180 CA certificate(s).
Resolving 'www.abb.com'...
Connecting to '138.224.0.100:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `C=CH,L=Baden,O=ABB Information Systems Ltd.,CN=www.abb.com', issuer `C=CH,L=Zurich,O=ABB,CN=ABB Issuing CA 6', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-04-22 07:26:29 UTC', expires `2017-10-08 07:26:29 UTC', SHA-1 fingerprint `55107158d3f572284408cef640dd214954ef0467'
        Public Key ID:
                1a71541a0dbe7f2b027a916024dc9693e57014f6
        Public key's random art:
                +--[ RSA 2048]----+
                | . ..=*.++.      |
                |  o B= + o.      |
                |   + .o E        |
                |    o  o .       |
                |   . ...S        |
                |      +o .       |
                |     ..o  . .    |
                |    . . . .. .   |
                |     .   . ..    |
                +-----------------+

- Certificate[1] info:
 - subject `C=CH,L=Zurich,O=ABB,CN=ABB Issuing CA 6', issuer `C=CH,L=Zurich,O=ABB,CN=ABB Intermediate CA 3', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-03-04 09:46:43 UTC', expires `2020-03-04 09:56:43 UTC', SHA-1 fingerprint `b9a59051ca53f6577223c43eec2493839343fe4d'
- Certificate[2] info:
 - subject `C=CH,L=Zurich,O=ABB,CN=ABB Intermediate CA 3', issuer `C=IE,O=Baltimore,OU=CyberTrust,CN=Baltimore CyberTrust Root', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-05-21 18:52:53 UTC', expires `2022-05-21 18:52:20 UTC', SHA-1 fingerprint `e12ba5aeb7613a72cc9652f1673017a5d8fc7479'
- Status: The certificate is NOT trusted. The certificate chain violates the signer's constraints.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.



Kurt



From gustavo at zacarias.com.ar  Mon Dec 14 19:20:25 2015
From: gustavo at zacarias.com.ar (Gustavo Zacarias)
Date: Mon, 14 Dec 2015 15:20:25 -0300
Subject: [gnutls-devel] [PATCH] configure: really make --disable-crywrap work
Message-ID: <1450117225-3910-1-git-send-email-gustavo@zacarias.com.ar>

The crywrap variable is set regardless of the state of enable_crywrap,
hence --disable-crywrap never works.
Just put the tests for crywrap deps inside the enable_crywrap
conditional.

Signed-off-by: Gustavo Zacarias <gustavo at zacarias.com.ar>
---
 configure.ac | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index e1d1df0..efacc30 100644
--- a/configure.ac
+++ b/configure.ac
@@ -836,11 +836,10 @@ AC_ARG_ENABLE(crywrap,
 
 
  if test "x$enable_crywrap" != "xno" ; then
-	AC_CHECK_FUNCS([argp_usage],[ac_argp=yes],[ac_argp=no])
- fi
-
- if test "$ac_cv_func_daemon" != "no" && test "$ac_argp" != "no" && test "$with_libidn" != "no";then
-  crywrap=yes
+   AC_CHECK_FUNCS([argp_usage],[ac_argp=yes],[ac_argp=no])
+   if test "$ac_cv_func_daemon" != "no" && test "$ac_argp" != "no" && test "$with_libidn" != "no";then
+     crywrap=yes
+   fi
  fi
 
 fi
-- 
2.4.10



From nmav at gnutls.org  Tue Dec 15 12:10:28 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Dec 2015 12:10:28 +0100
Subject: [gnutls-devel] [PATCH] configure: really make --disable-crywrap
	work
In-Reply-To: <1450117225-3910-1-git-send-email-gustavo@zacarias.com.ar>
References: <1450117225-3910-1-git-send-email-gustavo@zacarias.com.ar>
Message-ID: <CAJU7zaLsnQWsGhtF3LPui2MqHmrrPHcK44u0BdinMDPPdi-8Ag@mail.gmail.com>

On Mon, Dec 14, 2015 at 7:20 PM, Gustavo Zacarias
<gustavo at zacarias.com.ar> wrote:
> The crywrap variable is set regardless of the state of enable_crywrap,
> hence --disable-crywrap never works.
> Just put the tests for crywrap deps inside the enable_crywrap
> conditional.

Thank you. Applied.


From ludo at gnu.org  Wed Dec 16 11:26:30 2015
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 16 Dec 2015 11:26:30 +0100
Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults
In-Reply-To: <20151205080314.GA1142@argenau.bebt.de> (Andreas Metzler's
 message of "Sat, 5 Dec 2015 09:03:14 +0100")
References: <20151124184945.GB4525@downhill.g.la> <87k2p5yp96.fsf@gnu.org>
 <20151126183439.GA2736@downhill.g.la>
 <20151205080314.GA1142@argenau.bebt.de>
Message-ID: <8737v2bsfd.fsf@gnu.org>

Hi Andreas,

I have been able to reproduce the bug by running this from guile/tests:

  while ../pre-inst-guile -L . --no-auto-compile openpgp-auth.scm ; do : ; done

and to get a backtrace:

--8<---------------cut here---------------start------------->8---
(gdb) bt
#0  iprin1 (
    exp=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    port=#<port file 1dd2ff0>, pstate=0x1e71320) at print.c:589
#1  0x00007f8a7822e167 in scm_iprlist (hdr=hdr at entry=0x7f8a782a8e49 "(", 
    exp=exp at entry=<error reading variable: ERROR: Cannot access memory at address 0x0>, tlr=tlr at entry=41, port=port at entry=#<port file 1dd2ff0>, 
    pstate=pstate at entry=0x1e71320) at print.c:1336
#2  0x00007f8a7822ee24 in iprin1 (
    exp=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    port=#<port file 1dd2ff0>, pstate=0x1e71320) at print.c:614
#3  0x00007f8a7822e22b in scm_iprlist (hdr=hdr at entry=0x7f8a782a8e49 "(", 
    exp=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    exp at entry=<error reading variable: ERROR: Cannot access memory at address 0x0>, tlr=tlr at entry=41, port=port at entry=#<port file 1dd2ff0>, 
    pstate=pstate at entry=0x1e71320) at print.c:1347
#4  0x00007f8a7822ee24 in iprin1 (
    exp=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    port=#<port file 1dd2ff0>, pstate=0x1e71320) at print.c:614
#5  0x00007f8a7822dfa9 in scm_prin1 (
    exp=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    port=#<port file 1dd2ff0>, writingp=1) at print.c:845
#6  0x00007f8a7822f4f6 in scm_simple_format (
    destination=#<port file 1dd2ff0>, 
    message="~%throw to `~a' with args ~s~%", 
    args=<error reading variable: ERROR: Cannot access memory at address 0x0>)
    at print.c:1528
#7  0x00007f8a78278d56 in vm_regular_engine (
    vm=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    program=#<port file 1dd2ff0>, argv=0x1d505e0, nargs=2015556272)
    at vm-i-system.c:861
#8  0x00007f8a78279438 in scm_call_with_vm (vm=#<vm 1d4d070>, 
    proc=#<program 1d1c620>, args=<optimized out>) at vm.c:1060
#9  0x00007f8a781e6ac1 in scm_apply (proc=<optimized out>, 
    arg1=<optimized out>, args=<optimized out>, args at entry=()) at eval.c:755
#10 0x00007f8a781e8700 in scm_apply_1 (proc=<optimized out>, 
    arg1=arg1 at entry=wrong-type-arg, args=<optimized out>) at eval.c:588
#11 0x00007f8a7825e4fc in scm_throw (key=key at entry=wrong-type-arg, 
    args=<optimized out>) at throw.c:98
#12 0x00007f8a7825e925 in scm_ithrow (key=key at entry=wrong-type-arg, 
    args=<optimized out>, no_return=no_return at entry=1) at throw.c:435
#13 0x00007f8a781e5665 in scm_error_scm (key=key at entry=wrong-type-arg, 
    subr=<optimized out>, message=message at entry="Wrong type: ~S", 
    args=args at entry=<error reading variable: ERROR: Cannot access memory at address 0x0>, 
    data=data at entry=<error reading variable: ERROR: Cannot access memory at address 0x0>) at error.c:94
#14 0x00007f8a781e571f in scm_error (key=wrong-type-arg, subr=subr at entry=0x0, 
    message=<optimized out>, 
    args=<error reading variable: ERROR: Cannot access memory at address 0x0>, rest=rest at entry=<error reading variable: ERROR: Cannot access memory at address 0x0>) at error.c:59
#15 0x00007f8a781e59a8 in scm_wrong_type_arg (subr=subr at entry=0x0, 
    pos=pos at entry=0, 
    bad_value=<error reading variable: ERROR: Cannot access memory at address 0x0>) at error.c:248
#16 0x00007f8a781d4d80 in scm_to_bool (x=<optimized out>) at boolean.c:83
#17 0x00007f8a748dd7be in fill_session_record_port_input (
    port=<optimized out>) at core.c:896
#18 0x00007f8a78229598 in scm_slow_get_byte_or_eof (
    port=port at entry=#<port gnutls-session-port 200aae0>) at ports.c:1535
--8<---------------cut here---------------end--------------->8---

Here ?fill_session_record_port_input? attempts to access the SCM object
stored via ?gnutls_session_set_ptr? in the session object.  But it turns
out that this SCM object is garbage (maybe because it has been GC?d),
leading to a Scheme wrong-type-arg error and eventually a crash.

I can think of two options: either a GC bug (where the SMOB mark
procedure for the session SMOB would not be called, or its result would
be ignored, leading to the session data being GC?d too early), or some
random C level corruption.

I?ll keep investigating and report back.

Thanks,
Ludo?.

PS: Please keep me Cc?d.


From n.mavrogiannopoulos at gmail.com  Thu Dec 17 09:06:51 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 17 Dec 2015 09:06:51 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <5664A753.700@nic.cz>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <1449397557.842.7.camel@gmail.com> <5664A753.700@nic.cz>
Message-ID: <CAJU7za+ZDrdu6MOoMJV4+qdwrwXr9F+0H3vgoc9uMf6KiDmk-A@mail.gmail.com>

On Sun, Dec 6, 2015 at 10:23 PM, Jan V?el?k <jan.vcelak at nic.cz> wrote:
> On 6.12.2015 11:25, Nikos Mavrogiannopoulos wrote:
>> Interesting. As I understand you are referring to the CKA_EC_POINT
>> attribute which does not need to be included in private key objects.
> Exactly.
>> For a fix to make gnutls_pubkey_import_privkey() available with all
>> keys, an alternative is for the import function to reconstruct the
>> public key from the private key. I'll check how feasible is that.
> I don't think this will be possible. The private key material is present
> in the token, so the token would have to do the reconstruction.

Hi Jan,
 I'm still thinking whether gnutls_pubkey_import_privkey() should work
with these keys or we simply return an error. How did you solve that?

regards,
Nikos


From alon.barlev at gmail.com  Thu Dec 17 18:57:52 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 17 Dec 2015 19:57:52 +0200
Subject: [gnutls-devel] [PATCH 1/3] .gitignore: add m4/extern-inline.m4
Message-ID: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>

---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index a56bd12..2c84b0e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -399,6 +399,7 @@ lib/x509/x509-api.texi
 libopts/libopts.la
 libtool
 m4/codeset.m4
+m4/extern-inline.m4
 m4/fcntl-o.m4
 m4/gettext.m4
 m4/glibc2.m4
-- 
2.4.10



From alon.barlev at gmail.com  Thu Dec 17 18:57:53 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 17 Dec 2015 19:57:53 +0200
Subject: [gnutls-devel] [PATCH 2/3] doc: manpages: remove generated
	tpmtool.1 page
In-Reply-To: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <1450375074-22549-2-git-send-email-alon.barlev@gmail.com>

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 doc/manpages/tpmtool.1 | 201 -------------------------------------------------
 1 file changed, 201 deletions(-)
 delete mode 100644 doc/manpages/tpmtool.1

diff --git a/doc/manpages/tpmtool.1 b/doc/manpages/tpmtool.1
deleted file mode 100644
index 3b34351..0000000
--- a/doc/manpages/tpmtool.1
+++ /dev/null
@@ -1,201 +0,0 @@
-.TH tpmtool 1 "09 Nov 2013" "@VERSION@" "User Commands"
-.\"
-.\"  DO NOT EDIT THIS FILE   (tpmtool-args.man)
-.\"
-.\"  It has been AutoGen-ed  November  9, 2013 at 01:03:34 PM by AutoGen 5.18
-.\"  From the definitions    ../../src/tpmtool-args.def.tmp
-.\"  and the template file   agman-cmd.tpl
-.\"
-.SH NAME
-tpmtool \- GnuTLS TPM tool
-.SH SYNOPSIS
-.B tpmtool
-.\" Mixture of short (flag) options and long options
-.RB [ \-\fIflag\fP " [\fIvalue\fP]]... [" \-\-\fIopt\-name\fP "[[=| ]\fIvalue\fP]]..."
-.PP
-All arguments must be options.
-.PP
-.SH "DESCRIPTION"
-Program that allows handling cryptographic data from the TPM chip.
-.SH "OPTIONS"
-.TP
-.BR  \-d " \fInumber\fP, " \-\-debug "=" \fInumber\fP
-Enable debugging.
-This option takes an integer number as its argument.
-The value of \fInumber\fP is constrained to being:
-.in +4
-.nf
-.na
-in the range  0 through 9999
-.fi
-.in -4
-.sp
-Specifies the debug level.
-.TP
-.BR  \-\-infile "=\fIfile\fP"
-Input file.
-.sp
-.TP
-.BR  \-\-outfile "=\fIstring\fP"
-Output file.
-.sp
-.TP
-.BR  \-\-generate\-rsa
-Generate an RSA private-public key pair.
-.sp
-Generates an RSA private-public key pair in the TPM chip. 
-The key may be stored in filesystem and protected by a PIN, or stored (registered)
-in the TPM chip flash.
-.TP
-.BR  \-\-register
-Any generated key will be registered in the TPM.
-This option must appear in combination with the following options:
-generate-rsa.
-.sp
-.TP
-.BR  \-\-signing
-Any generated key will be a signing key.
-This option must appear in combination with the following options:
-generate-rsa.
-This option must not appear in combination with any of the following options:
-legacy.
-.sp
-.TP
-.BR  \-\-legacy
-Any generated key will be a legacy key.
-This option must appear in combination with the following options:
-generate-rsa.
-This option must not appear in combination with any of the following options:
-signing.
-.sp
-.TP
-.BR  \-\-user
-Any registered key will be a user key.
-This option must appear in combination with the following options:
-register.
-This option must not appear in combination with any of the following options:
-system.
-.sp
-The generated key will be stored in a user specific persistent storage.
-.TP
-.BR  \-\-system
-Any registred key will be a system key.
-This option must appear in combination with the following options:
-register.
-This option must not appear in combination with any of the following options:
-user.
-.sp
-The generated key will be stored in system persistent storage.
-.TP
-.BR  \-\-pubkey "=\fIurl\fP"
-Prints the public key of the provided key.
-.sp
-.TP
-.BR  \-\-list
-Lists all stored keys in the TPM.
-.sp
-.TP
-.BR  \-\-delete "=\fIurl\fP"
-Delete the key identified by the given URL (UUID)..
-.sp
-.TP
-.BR  \-\-sec\-param "=\fIsecurity parameter\fP"
-Specify the security level [low, legacy, normal, high, ultra]..
-.sp
-This is alternative to the bits option. Note however that the
-values allowed by the TPM chip are quantized and given values may be rounded up.
-.TP
-.BR  \-\-bits "=\fInumber\fP"
-Specify the number of bits for key generate.
-This option takes an integer number as its argument.
-.sp
-.TP
-.BR  \-\-inder, " \fB\-\-no\-inder\fP"
-Use the DER format for keys..
-The \fIno\-inder\fP form will disable the option.
-.sp
-The input files will be assumed to be in the portable
-DER format of TPM. The default format is a custom format used by various
-TPM tools
-.TP
-.BR  \-\-outder, " \fB\-\-no\-outder\fP"
-Use DER format for output keys.
-The \fIno\-outder\fP form will disable the option.
-.sp
-The output will be in the TPM portable DER format.
-.TP
-.BR \-h , " \-\-help"
-Display usage information and exit.
-.TP
-.BR \-! , " \-\-more-help"
-Pass the extended usage information through a pager.
-.TP
-.BR \-v " [{\fIv|c|n\fP}]," " \-\-version" "[={\fIv|c|n\fP}]"
-Output version of program and exit.  The default mode is `v', a simple
-version.  The `c' mode will print copyright information and `n' will
-print the full copyright notice.
-.SH EXAMPLES
-To generate a key that is to be stored in filesystem use:
-.br
-.in +4
-.nf
-$ tpmtool \-\-generate\-rsa \-\-bits 2048 \-\-outfile tpmkey.pem
-.in -4
-.fi
-.sp
-To generate a key that is to be stored in TPM's flash use:
-.br
-.in +4
-.nf
-$ tpmtool \-\-generate\-rsa \-\-bits 2048 \-\-register \-\-user
-.in -4
-.fi
-.sp
-To get the public key of a TPM key use:
-.br
-.in +4
-.nf
-$ tpmtool \-\-pubkey tpmkey:uuid=58ad734b\-bde6\-45c7\-89d8\-756a55ad1891;storage=user \
-          \-\-outfile pubkey.pem
-.in -4
-.fi
-.sp
-or if the key is stored in the filesystem:
-.br
-.in +4
-.nf
-$ tpmtool \-\-pubkey tpmkey:file=tmpkey.pem \-\-outfile pubkey.pem
-.in -4
-.fi
-.sp
-To list all keys stored in TPM use:
-.br
-.in +4
-.nf
-$ tpmtool \-\-list
-.in -4
-.fi
-.SH "EXIT STATUS"
-One of the following exit values will be returned:
-.TP
-.BR 0 " (EXIT_SUCCESS)"
-Successful program execution.
-.TP
-.BR 1 " (EXIT_FAILURE)"
-The operation failed or the command syntax was not valid.
-.TP
-.BR 70 " (EX_SOFTWARE)"
-libopts had an internal operational error.  Please report
-it to autogen-users at lists.sourceforge.net.  Thank you.
-.SH "SEE ALSO"
-    p11tool (1), certtool (1)
-.SH "AUTHORS"
-Nikos Mavrogiannopoulos, Simon Josefsson and others; see /usr/share/doc/gnutls-bin/AUTHORS for a complete list.
-.SH "COPYRIGHT"
-Copyright (C) 2000-2012 Free Software Foundation all rights reserved.
-This program is released under the terms of the GNU General Public License, version 3 or later.
-.SH "BUGS"
-Please send bug reports to: bug-gnutls at gnu.org
-.SH "NOTES"
-This manual page was \fIAutoGen\fP-erated from the \fBtpmtool\fP
-option definitions.
-- 
2.4.10



From alon.barlev at gmail.com  Thu Dec 17 18:57:54 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 17 Dec 2015 19:57:54 +0200
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>

currently these man pages are installed only if --enable-doc
is provided, while these are not actually docs, do not require any
special dependency, nor consume large space.

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 .gitignore               | 21 +++++++-----
 Makefile.am              |  2 +-
 configure.ac             |  1 +
 doc/manpages/Makefile.am | 67 ------------------------------------
 manpages/Makefile.am     | 89 ++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 103 insertions(+), 77 deletions(-)
 create mode 100644 manpages/Makefile.am

diff --git a/.gitignore b/.gitignore
index 2c84b0e..8c41b62 100644
--- a/.gitignore
+++ b/.gitignore
@@ -123,18 +123,9 @@ doc/latex/gnutls.lof
 doc/latex/gnutls.lot
 doc/manpages/Makefile
 doc/manpages/Makefile.in
-doc/manpages/certtool.1
-doc/manpages/danetool.1
-doc/manpages/gnutls-cli-debug.1
-doc/manpages/gnutls-cli.1
-doc/manpages/gnutls-serv.1
 doc/manpages/gnutls_*.3
 doc/manpages/dane_*.3
 doc/manpages/xssl_*.3
-doc/manpages/ocsptool.1
-doc/manpages/p11tool.1
-doc/manpages/psktool.1
-doc/manpages/srptool.1
 doc/ocsp-api.texi
 doc/pgp-api.texi
 doc/pkcs11-api.texi
@@ -440,6 +431,18 @@ m4/visibility.m4
 m4/wchar_t.m4
 m4/wint_t.m4
 m4/xsize.m4
+manpages/Makefile
+manpages/Makefile.in
+manpages/certtool.1
+manpages/danetool.1
+manpages/gnutls-cli-debug.1
+manpages/gnutls-cli.1
+manpages/gnutls-serv.1
+manpages/ocsptool.1
+manpages/p11tool.1
+manpages/psktool.1
+manpages/srptool.1
+manpages/tpmtool.1
 po/*.gmo
 po/*.po
 po/Makefile
diff --git a/Makefile.am b/Makefile.am
index d61fded..a37642d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,7 +21,7 @@
 
 DISTCHECK_CONFIGURE_FLAGS = --enable-gtk-doc --disable-valgrind-tests
 
-SUBDIRS = gl lib extra
+SUBDIRS = gl lib extra manpages
 
 if ENABLE_DANE
 SUBDIRS += libdane
diff --git a/configure.ac b/configure.ac
index efacc30..61c0c71 100644
--- a/configure.ac
+++ b/configure.ac
@@ -894,6 +894,7 @@ AC_CONFIG_FILES([
   lib/opencdk/Makefile
   lib/openpgp/Makefile
   lib/x509/Makefile
+  manpages/Makefile
   po/Makefile.in
   src/Makefile
   src/crywrap/Makefile
diff --git a/doc/manpages/Makefile.am b/doc/manpages/Makefile.am
index db1f71b..9436c4c 100644
--- a/doc/manpages/Makefile.am
+++ b/doc/manpages/Makefile.am
@@ -25,73 +25,6 @@ dist_man_MANS =
 
 -include $(top_srcdir)/doc/doc.mk
 
-if ENABLE_TOOLS
-dist_man_MANS += gnutls-cli.1 gnutls-cli-debug.1 gnutls-serv.1	\
-	certtool.1 psktool.1 p11tool.1 ocsptool.1 tpmtool.1
-if ENABLE_SRP
-dist_man_MANS += srptool.1
-endif
-if ENABLE_DANE
-dist_man_MANS += danetool.1
-endif
-endif
-
-# Note that our .def files depend on autogen
-# supporting the @subheading texi keyword. This
-# is not currently the case so we do remove it
-# before processing. Once the new version of autogen
-# is out, replace the sed and tmp files with a simple
-# autogen -DMAN_SECTION=1 -Tagman-cmd.tpl $<
-certtool.1: ../../src/certtool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-ocsptool.1: ../../src/ocsptool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-danetool.1: ../../src/danetool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-cli.1: ../../src/cli-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-serv.1: ../../src/serv-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-cli-debug.1: ../../src/cli-debug-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-srptool.1: ../../src/srptool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-p11tool.1: ../../src/p11tool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-tpmtool.1: ../../src/tpmtool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-psktool.1: ../../src/psktool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
 APIMANS =
 APIMANS += gnutls_aead_cipher_decrypt.3
 APIMANS += gnutls_aead_cipher_deinit.3
diff --git a/manpages/Makefile.am b/manpages/Makefile.am
new file mode 100644
index 0000000..c95510b
--- /dev/null
+++ b/manpages/Makefile.am
@@ -0,0 +1,89 @@
+## Process this file with automake to produce Makefile.in
+# Copyright (C) 2003-2012 Free Software Foundation, Inc.
+#
+# Author: Nikos Mavroyanopoulos, Simon Josefsson
+#
+# This file is part of GnuTLS.
+#
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This file is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this file; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+dist_man_MANS =
+
+if ENABLE_TOOLS
+dist_man_MANS += gnutls-cli.1 gnutls-cli-debug.1 gnutls-serv.1	\
+	certtool.1 psktool.1 p11tool.1 ocsptool.1 tpmtool.1
+if ENABLE_SRP
+dist_man_MANS += srptool.1
+endif
+if ENABLE_DANE
+dist_man_MANS += danetool.1
+endif
+endif
+
+# Note that our .def files depend on autogen
+# supporting the @subheading texi keyword. This
+# is not currently the case so we do remove it
+# before processing. Once the new version of autogen
+# is out, replace the sed and tmp files with a simple
+# autogen -DMAN_SECTION=1 -Tagman-cmd.tpl $<
+certtool.1: ../src/certtool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+ocsptool.1: ../src/ocsptool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+danetool.1: ../src/danetool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-cli.1: ../src/cli-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-serv.1: ../src/serv-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-cli-debug.1: ../src/cli-debug-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+srptool.1: ../src/srptool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+p11tool.1: ../src/p11tool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+tpmtool.1: ../src/tpmtool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+psktool.1: ../src/psktool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
-- 
2.4.10



From nmav at gnutls.org  Fri Dec 18 10:05:00 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 10:05:00 +0100
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
Message-ID: <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>

On Thu, Dec 17, 2015 at 6:57 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> currently these man pages are installed only if --enable-doc
> is provided, while these are not actually docs, do not require any
> special dependency, nor consume large space.

Hi Alon,
 I've applied the first two but not this one. The disable-doc is used
by systems which want no documentation at all and this commit changes
that. I'd prefer to keep things simple and have a single flag for
documentation irrespective of its type.

regards,
Nikos


From alon.barlev at gmail.com  Fri Dec 18 10:05:59 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 11:05:59 +0200
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
Message-ID: <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>

On 18 December 2015 at 11:05, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>
> On Thu, Dec 17, 2015 at 6:57 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> > currently these man pages are installed only if --enable-doc
> > is provided, while these are not actually docs, do not require any
> > special dependency, nor consume large space.
>
> Hi Alon,
>  I've applied the first two but not this one. The disable-doc is used
> by systems which want no documentation at all and this commit changes
> that. I'd prefer to keep things simple and have a single flag for
> documentation irrespective of its type.

OK, what about I add --enable-man ?


From nmav at gnutls.org  Fri Dec 18 10:09:53 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 10:09:53 +0100
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
 <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
Message-ID: <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>

On Fri, Dec 18, 2015 at 10:05 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> On Thu, Dec 17, 2015 at 6:57 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> > currently these man pages are installed only if --enable-doc
>> > is provided, while these are not actually docs, do not require any
>> > special dependency, nor consume large space.
>> Hi Alon,
>>  I've applied the first two but not this one. The disable-doc is used
>> by systems which want no documentation at all and this commit changes
>> that. I'd prefer to keep things simple and have a single flag for
>> documentation irrespective of its type.
> OK, what about I add --enable-man ?

No problem with that. Can it be done by keeping the manpages to their
current location?


From alon.barlev at gmail.com  Fri Dec 18 10:14:27 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 11:14:27 +0200
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
 <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
 <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>
Message-ID: <CAOazyz23U_LFJKac8rj4krVZp_4itnmcaoGbq=ZB0oXSJHjoeQ@mail.gmail.com>

On 18 December 2015 at 11:09, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Fri, Dec 18, 2015 at 10:05 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>> On Thu, Dec 17, 2015 at 6:57 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>> > currently these man pages are installed only if --enable-doc
>>> > is provided, while these are not actually docs, do not require any
>>> > special dependency, nor consume large space.
>>> Hi Alon,
>>>  I've applied the first two but not this one. The disable-doc is used
>>> by systems which want no documentation at all and this commit changes
>>> that. I'd prefer to keep things simple and have a single flag for
>>> documentation irrespective of its type.
>> OK, what about I add --enable-man ?
>
> No problem with that. Can it be done by keeping the manpages to their
> current location?

it is difficult as you have:

if ENABLE_DOC
SUBDIRS += doc
endif

and doc/Makefile.am is quite complex, I will have to condition it entirely.

I believe it will be simpler to split the doc (api) ones from the
other, but I can create two alternatives.

Let's begin with the simpler one.

Alon


From nmav at gnutls.org  Fri Dec 18 10:36:50 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 10:36:50 +0100
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAOazyz23U_LFJKac8rj4krVZp_4itnmcaoGbq=ZB0oXSJHjoeQ@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
 <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
 <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>
 <CAOazyz23U_LFJKac8rj4krVZp_4itnmcaoGbq=ZB0oXSJHjoeQ@mail.gmail.com>
Message-ID: <CAJU7zaL1qOr=RgAUQGsqNkw-Cfu2QB=8N6GRRQHiFtKcSzvr5w@mail.gmail.com>

On Fri, Dec 18, 2015 at 10:14 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> No problem with that. Can it be done by keeping the manpages to their
>> current location?
>
> it is difficult as you have:
>
> if ENABLE_DOC
> SUBDIRS += doc
> endif
>
> and doc/Makefile.am is quite complex, I will have to condition it entirely.
>
> I believe it will be simpler to split the doc (api) ones from the
> other, but I can create two alternatives.
>
> Let's begin with the simpler one.

What if we have:
doc/texinfo doc/manpages and doc/app-manpages

Then we can do at SUBDIRS:
+= doc/xxx with xxx being replaced with what is needed.

That would need to move the texinfo stuff in a subdir though.

regards,
Nikos


From alon.barlev at gmail.com  Fri Dec 18 11:13:09 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 12:13:09 +0200
Subject: [gnutls-devel] [PATCH] build: always install man(1)
In-Reply-To: <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
References: <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
Message-ID: <1450433589-21200-1-git-send-email-alon.barlev@gmail.com>

currently these man pages are installed only if --enable-doc
is provided, while these are not actually docs, do not require any
special dependency, nor consume large space.

add --disable-manpages to enable/disable manpages installation, install
the man(1) regardless of --enable-doc.

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 .gitignore               | 21 +++++++-----
 Makefile.am              |  6 +++-
 configure.ac             |  6 ++++
 doc/Makefile.am          |  7 +++-
 doc/manpages/Makefile.am | 67 ------------------------------------
 manpages/Makefile.am     | 89 ++++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 118 insertions(+), 78 deletions(-)
 create mode 100644 manpages/Makefile.am

diff --git a/.gitignore b/.gitignore
index 2c84b0e..8c41b62 100644
--- a/.gitignore
+++ b/.gitignore
@@ -123,18 +123,9 @@ doc/latex/gnutls.lof
 doc/latex/gnutls.lot
 doc/manpages/Makefile
 doc/manpages/Makefile.in
-doc/manpages/certtool.1
-doc/manpages/danetool.1
-doc/manpages/gnutls-cli-debug.1
-doc/manpages/gnutls-cli.1
-doc/manpages/gnutls-serv.1
 doc/manpages/gnutls_*.3
 doc/manpages/dane_*.3
 doc/manpages/xssl_*.3
-doc/manpages/ocsptool.1
-doc/manpages/p11tool.1
-doc/manpages/psktool.1
-doc/manpages/srptool.1
 doc/ocsp-api.texi
 doc/pgp-api.texi
 doc/pkcs11-api.texi
@@ -440,6 +431,18 @@ m4/visibility.m4
 m4/wchar_t.m4
 m4/wint_t.m4
 m4/xsize.m4
+manpages/Makefile
+manpages/Makefile.in
+manpages/certtool.1
+manpages/danetool.1
+manpages/gnutls-cli-debug.1
+manpages/gnutls-cli.1
+manpages/gnutls-serv.1
+manpages/ocsptool.1
+manpages/p11tool.1
+manpages/psktool.1
+manpages/srptool.1
+manpages/tpmtool.1
 po/*.gmo
 po/*.po
 po/Makefile
diff --git a/Makefile.am b/Makefile.am
index d61fded..bda5f26 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -42,6 +42,10 @@ if HAVE_GUILE
 SUBDIRS += guile
 endif
 
+if ENABLE_MANPAGES
+SUBDIRS += manpages
+endif
+
 if ENABLE_DOC
 SUBDIRS += doc
 endif
@@ -80,7 +84,7 @@ dist-hook:
 		$(SED) -i 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $$i.tmp; \
 		autogen -Tagman-cmd.tpl $$i.tmp; \
 		rm -f $$i.tmp; \
-		mv -f *.1 ../doc/manpages/; \
+		mv -f *.1 ../manpages/; \
 	done
 	cd $(distdir)/src/ && for i in *-args.c *-args.h;do \
 		mv $$i $$i.bak; \
diff --git a/configure.ac b/configure.ac
index efacc30..57ab8a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,6 +46,11 @@ AM_PROG_CC_C_O
 AC_PROG_YACC
 AC_PROG_SED
 
+AC_ARG_ENABLE(manpages,
+  AS_HELP_STRING([--disable-manpages], [don't install manpages]),
+    enable_manpages=$enableval, enable_manpages=yes)
+AM_CONDITIONAL(ENABLE_MANPAGES, test "$enable_manpages" != "no")
+
 AC_ARG_ENABLE(doc,
   AS_HELP_STRING([--disable-doc], [don't generate any documentation]),
     enable_doc=$enableval, enable_doc=yes)
@@ -894,6 +899,7 @@ AC_CONFIG_FILES([
   lib/opencdk/Makefile
   lib/openpgp/Makefile
   lib/x509/Makefile
+  manpages/Makefile
   po/Makefile.in
   src/Makefile
   src/crywrap/Makefile
diff --git a/doc/Makefile.am b/doc/Makefile.am
index da2aecc..61f217b 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -24,7 +24,12 @@ EXTRA_DIST = TODO certtool.cfg gnutls.pdf gnutls.html	\
 	gnutls-guile.pdf gnutls-guile.html stamp_enums stamp_functions \
 	doc.mk
 
-SUBDIRS = examples cyclo scripts manpages credentials latex
+SUBDIRS = examples cyclo scripts credentials latex
+
+if ENABLE_MANPAGES
+SUBDIRS += manpages
+endif
+
 if ENABLE_GTK_DOC
 SUBDIRS += reference
 endif
diff --git a/doc/manpages/Makefile.am b/doc/manpages/Makefile.am
index db1f71b..9436c4c 100644
--- a/doc/manpages/Makefile.am
+++ b/doc/manpages/Makefile.am
@@ -25,73 +25,6 @@ dist_man_MANS =
 
 -include $(top_srcdir)/doc/doc.mk
 
-if ENABLE_TOOLS
-dist_man_MANS += gnutls-cli.1 gnutls-cli-debug.1 gnutls-serv.1	\
-	certtool.1 psktool.1 p11tool.1 ocsptool.1 tpmtool.1
-if ENABLE_SRP
-dist_man_MANS += srptool.1
-endif
-if ENABLE_DANE
-dist_man_MANS += danetool.1
-endif
-endif
-
-# Note that our .def files depend on autogen
-# supporting the @subheading texi keyword. This
-# is not currently the case so we do remove it
-# before processing. Once the new version of autogen
-# is out, replace the sed and tmp files with a simple
-# autogen -DMAN_SECTION=1 -Tagman-cmd.tpl $<
-certtool.1: ../../src/certtool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-ocsptool.1: ../../src/ocsptool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-danetool.1: ../../src/danetool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-cli.1: ../../src/cli-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-serv.1: ../../src/serv-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-gnutls-cli-debug.1: ../../src/cli-debug-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-srptool.1: ../../src/srptool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-p11tool.1: ../../src/p11tool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-tpmtool.1: ../../src/tpmtool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
-psktool.1: ../../src/psktool-args.def
-	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
-	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
-	rm -f "$<".tmp
-
 APIMANS =
 APIMANS += gnutls_aead_cipher_decrypt.3
 APIMANS += gnutls_aead_cipher_deinit.3
diff --git a/manpages/Makefile.am b/manpages/Makefile.am
new file mode 100644
index 0000000..c95510b
--- /dev/null
+++ b/manpages/Makefile.am
@@ -0,0 +1,89 @@
+## Process this file with automake to produce Makefile.in
+# Copyright (C) 2003-2012 Free Software Foundation, Inc.
+#
+# Author: Nikos Mavroyanopoulos, Simon Josefsson
+#
+# This file is part of GnuTLS.
+#
+# This file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This file is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this file; if not, write to the Free Software Foundation,
+# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+dist_man_MANS =
+
+if ENABLE_TOOLS
+dist_man_MANS += gnutls-cli.1 gnutls-cli-debug.1 gnutls-serv.1	\
+	certtool.1 psktool.1 p11tool.1 ocsptool.1 tpmtool.1
+if ENABLE_SRP
+dist_man_MANS += srptool.1
+endif
+if ENABLE_DANE
+dist_man_MANS += danetool.1
+endif
+endif
+
+# Note that our .def files depend on autogen
+# supporting the @subheading texi keyword. This
+# is not currently the case so we do remove it
+# before processing. Once the new version of autogen
+# is out, replace the sed and tmp files with a simple
+# autogen -DMAN_SECTION=1 -Tagman-cmd.tpl $<
+certtool.1: ../src/certtool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+ocsptool.1: ../src/ocsptool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+danetool.1: ../src/danetool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-cli.1: ../src/cli-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-serv.1: ../src/serv-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+gnutls-cli-debug.1: ../src/cli-debug-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+srptool.1: ../src/srptool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+p11tool.1: ../src/p11tool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+tpmtool.1: ../src/tpmtool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
+
+psktool.1: ../src/psktool-args.def
+	-sed 's/@subheading \(.*\)/@*\n at var{\1}\n@*/' $< > "$<".tmp && \
+	autogen -DMAN_SECTION=1 -Tagman-cmd.tpl "$<".tmp && \
+	rm -f "$<".tmp
-- 
2.4.10



From alon.barlev at gmail.com  Fri Dec 18 11:14:08 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 12:14:08 +0200
Subject: [gnutls-devel] [PATCH 1/2] build: always install man(1)
In-Reply-To: <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
References: <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
Message-ID: <1450433649-21321-1-git-send-email-alon.barlev@gmail.com>

currently these man pages are installed only if --enable-doc
is provided, while these are not actually docs, do not require any
special dependency, nor consume large space.

add --disable-manpages to enable/disable manpages installation, install
the man(1) regardless of --enable-doc.

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 .gitignore               | 1 +
 Makefile.am              | 4 ++++
 configure.ac             | 5 +++++
 doc/Makefile.am          | 2 +-
 doc/manpages/Makefile.am | 2 ++
 5 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 2c84b0e..b50a6fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -135,6 +135,7 @@ doc/manpages/ocsptool.1
 doc/manpages/p11tool.1
 doc/manpages/psktool.1
 doc/manpages/srptool.1
+doc/manpages/tpmtool.1
 doc/ocsp-api.texi
 doc/pgp-api.texi
 doc/pkcs11-api.texi
diff --git a/Makefile.am b/Makefile.am
index d61fded..f39916f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -42,6 +42,10 @@ if HAVE_GUILE
 SUBDIRS += guile
 endif
 
+if ENABLE_MANPAGES
+SUBDIRS += doc/manpages
+endif
+
 if ENABLE_DOC
 SUBDIRS += doc
 endif
diff --git a/configure.ac b/configure.ac
index efacc30..4c928ef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,6 +46,11 @@ AM_PROG_CC_C_O
 AC_PROG_YACC
 AC_PROG_SED
 
+AC_ARG_ENABLE(manpages,
+  AS_HELP_STRING([--disable-manpages], [don't install manpages]),
+    enable_manpages=$enableval, enable_manpages=yes)
+AM_CONDITIONAL(ENABLE_MANPAGES, test "$enable_manpages" != "no")
+
 AC_ARG_ENABLE(doc,
   AS_HELP_STRING([--disable-doc], [don't generate any documentation]),
     enable_doc=$enableval, enable_doc=yes)
diff --git a/doc/Makefile.am b/doc/Makefile.am
index da2aecc..d81d220 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -24,7 +24,7 @@ EXTRA_DIST = TODO certtool.cfg gnutls.pdf gnutls.html	\
 	gnutls-guile.pdf gnutls-guile.html stamp_enums stamp_functions \
 	doc.mk
 
-SUBDIRS = examples cyclo scripts manpages credentials latex
+SUBDIRS = examples cyclo scripts credentials latex
 if ENABLE_GTK_DOC
 SUBDIRS += reference
 endif
diff --git a/doc/manpages/Makefile.am b/doc/manpages/Makefile.am
index db1f71b..3299269 100644
--- a/doc/manpages/Makefile.am
+++ b/doc/manpages/Makefile.am
@@ -1116,7 +1116,9 @@ APIMANS += gnutls_x509_trust_list_verify_crt.3
 APIMANS += gnutls_x509_trust_list_verify_crt2.3
 APIMANS += gnutls_x509_trust_list_verify_named_crt.3
 
+if ENABLE_DOC
 dist_man_MANS += $(APIMANS)
+endif
 
 $(APIMANS): stamp_mans
 
-- 
2.4.10



From alon.barlev at gmail.com  Fri Dec 18 11:16:55 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 12:16:55 +0200
Subject: [gnutls-devel] [PATCH] build: move manpages out of doc
In-Reply-To: <1450433783-21500-1-git-send-email-alon.barlev@gmail.com>
References: <1450433649-21321-1-git-send-email-alon.barlev@gmail.com>
 <1450433783-21500-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <CAOazyz1qaK8M9zeEXch-VzzzjcSKanphMngh9BZhn=FSQ0nOWw@mail.gmail.com>

This is optional.


From alon.barlev at gmail.com  Fri Dec 18 11:19:58 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 12:19:58 +0200
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
 <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
 <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>
 <CAOazyz23U_LFJKac8rj4krVZp_4itnmcaoGbq=ZB0oXSJHjoeQ@mail.gmail.com>
 <CAJU7zaL1qOr=RgAUQGsqNkw-Cfu2QB=8N6GRRQHiFtKcSzvr5w@mail.gmail.com>
 <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
Message-ID: <CAOazyz3RmBeKcU7J1B99DHF-1TH=E4STTcGEDUjxLt+YNJiqUg@mail.gmail.com>

On 18 December 2015 at 11:41, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> On 18 December 2015 at 11:36, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> On Fri, Dec 18, 2015 at 10:14 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>>> No problem with that. Can it be done by keeping the manpages to their
>>>> current location?
>>>
>>> it is difficult as you have:
>>>
>>> if ENABLE_DOC
>>> SUBDIRS += doc
>>> endif
>>>
>>> and doc/Makefile.am is quite complex, I will have to condition it entirely.
>>>
>>> I believe it will be simpler to split the doc (api) ones from the
>>> other, but I can create two alternatives.
>>>
>>> Let's begin with the simpler one.
>>
>> What if we have:
>> doc/texinfo doc/manpages and doc/app-manpages
>>
>> Then we can do at SUBDIRS:
>> += doc/xxx with xxx being replaced with what is needed.
>>
>> That would need to move the texinfo stuff in a subdir though.
>
> yes, but then I will have to add ENABLE_DOC conditional into the manpages.
> not sure it makes it easier to maintain.
> but I will post this alternative as well.

I sent two (three) options:
1. split manpages to doc and non doc (I prefer this one :) )
2. leave manpages at doc/manpages but enter it directly from root.
3. like 2 but move manpages to root (as expected).

Please make sure make dist is working, I am unsure I modified it correctly.

Thanks!
Alon


From alon.barlev at gmail.com  Fri Dec 18 11:24:26 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 12:24:26 +0200
Subject: [gnutls-devel] [PATCH] build: move manpages out of doc
In-Reply-To: <CAOazyz1qaK8M9zeEXch-VzzzjcSKanphMngh9BZhn=FSQ0nOWw@mail.gmail.com>
References: <1450433649-21321-1-git-send-email-alon.barlev@gmail.com>
 <1450433783-21500-1-git-send-email-alon.barlev@gmail.com>
 <CAOazyz1qaK8M9zeEXch-VzzzjcSKanphMngh9BZhn=FSQ0nOWw@mail.gmail.com>
Message-ID: <CAOazyz2m=zn+yE0fNLfEwESgc-29ieRFaKR5BjF_0=JgfZFCVQ@mail.gmail.com>

On 18 December 2015 at 12:16, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> This is optional.

sorry, I had issue with it, will send a fix.


From jan.vcelak at nic.cz  Fri Dec 18 13:34:27 2015
From: jan.vcelak at nic.cz (Jan =?utf-8?B?VsSNZWzDoWs=?=)
Date: Fri, 18 Dec 2015 13:34:27 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <CAJU7za+ZDrdu6MOoMJV4+qdwrwXr9F+0H3vgoc9uMf6KiDmk-A@mail.gmail.com>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <5664A753.700@nic.cz>
 <CAJU7za+ZDrdu6MOoMJV4+qdwrwXr9F+0H3vgoc9uMf6KiDmk-A@mail.gmail.com>
Message-ID: <2567315.FzkcVNxebF@pc-cznic4>

Hello Nikos.

> >> For a fix to make gnutls_pubkey_import_privkey() available with all
> >> keys, an alternative is for the import function to reconstruct the
> >> public key from the private key. I'll check how feasible is that.
> > 
> > I don't think this will be possible. The private key material is present
> > in the token, so the token would have to do the reconstruction.
> 
>  I'm still thinking whether gnutls_pubkey_import_privkey() should work
> with these keys or we simply return an error. How did you solve that?

I wonder if CKA_ID for a public key object and a corresponding private key 
object have to match. I'm quite certain that they have to. Because this 
attribute is used in certificates to uniquely identify matching key pairs.

So I think one solution is obvious: Use the CKA_ID to get a CKO_PUBLIC_KEY 
object from the token to initialize the gnutls_pubkey_t structure.

As for my case: I haven't fixed it yet. I'm using RSA keys for testing and 
I know that ECDSA is broken. But I intend to import public keys explicitly 
using gnutls_pubkey_import_url() instead of gnutls_pubkey_import_privkey(). 
This is a safe bet.

Cheers,

Jan


From n.mavrogiannopoulos at gmail.com  Fri Dec 18 13:59:11 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 13:59:11 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <2567315.FzkcVNxebF@pc-cznic4>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <5664A753.700@nic.cz>
 <CAJU7za+ZDrdu6MOoMJV4+qdwrwXr9F+0H3vgoc9uMf6KiDmk-A@mail.gmail.com>
 <2567315.FzkcVNxebF@pc-cznic4>
Message-ID: <CAJU7zaKH2yu=LzQWg1MJnhGfJ7adeZrOnzymHsXqQs2ehZ-UOQ@mail.gmail.com>

On Fri, Dec 18, 2015 at 1:34 PM, Jan V?el?k <jan.vcelak at nic.cz> wrote:
> Hello Nikos.
>> >> For a fix to make gnutls_pubkey_import_privkey() available with all
>> >> keys, an alternative is for the import function to reconstruct the
>> >> public key from the private key. I'll check how feasible is that.
>> > I don't think this will be possible. The private key material is present
>> > in the token, so the token would have to do the reconstruction.
>>  I'm still thinking whether gnutls_pubkey_import_privkey() should work
>> with these keys or we simply return an error. How did you solve that?
> I wonder if CKA_ID for a public key object and a corresponding private key
> object have to match. I'm quite certain that they have to. Because this
> attribute is used in certificates to uniquely identify matching key pairs.
> So I think one solution is obvious: Use the CKA_ID to get a CKO_PUBLIC_KEY
> object from the token to initialize the gnutls_pubkey_t structure.

Unfortunately there is no guarantee for the IDs to match. It is merely
a convention. Even worse the public object cannot be assumed to be
accessible without any user interaction (it may be marked as senstive
and require the user to put a password into pinpad).

> As for my case: I haven't fixed it yet. I'm using RSA keys for testing and
> I know that ECDSA is broken. But I intend to import public keys explicitly
> using gnutls_pubkey_import_url() instead of gnutls_pubkey_import_privkey().
> This is a safe bet.

Indeed. I'll also document that this function cannot operate on
certain PKCS#11 keys.

regards,
Nikos


From jan.vcelak at nic.cz  Fri Dec 18 14:14:23 2015
From: jan.vcelak at nic.cz (Jan =?utf-8?B?VsSNZWzDoWs=?=)
Date: Fri, 18 Dec 2015 14:14:23 +0100
Subject: [gnutls-devel] PKCS 11, public key from a private key
In-Reply-To: <CAJU7zaKH2yu=LzQWg1MJnhGfJ7adeZrOnzymHsXqQs2ehZ-UOQ@mail.gmail.com>
References: <1449359199-15823-1-git-send-email-jan.vcelak@nic.cz>
 <2567315.FzkcVNxebF@pc-cznic4>
 <CAJU7zaKH2yu=LzQWg1MJnhGfJ7adeZrOnzymHsXqQs2ehZ-UOQ@mail.gmail.com>
Message-ID: <2386994.gG2FmJyOv5@pc-cznic4>

> > I wonder if CKA_ID for a public key object and a corresponding private key
> > object have to match. I'm quite certain that they have to. Because this
> > attribute is used in certificates to uniquely identify matching key pairs.
> > So I think one solution is obvious: Use the CKA_ID to get a CKO_PUBLIC_KEY
> > object from the token to initialize the gnutls_pubkey_t structure.
> 
> Unfortunately there is no guarantee for the IDs to match. It is merely
> a convention. Even worse the public object cannot be assumed to be
> accessible without any user interaction (it may be marked as senstive
> and require the user to put a password into pinpad).

Currently, the RSA public key is also constructed from the private key object,  
which will be marked as sensitive for sure. So that's not a huge difference.

Anyway, if the IDs are not guaranteed to match, I would rather go for the 
second proposed solution: Make the gnutls_pubkey_import_privkey() function 
always fail for PKCS #11.

It's better than inventing some unreliable workaround. The implicit import of 
the public key will always work. And if it doesn't, then the cause is obvious.

Cheers,

Jan


From nmav at gnutls.org  Fri Dec 18 16:26:49 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Dec 2015 16:26:49 +0100
Subject: [gnutls-devel] [PATCH 3/3] build: always install man(1)
In-Reply-To: <CAOazyz3RmBeKcU7J1B99DHF-1TH=E4STTcGEDUjxLt+YNJiqUg@mail.gmail.com>
References: <1450375074-22549-1-git-send-email-alon.barlev@gmail.com>
 <1450375074-22549-3-git-send-email-alon.barlev@gmail.com>
 <CAJU7zaL8KFQE4zkkkhn0Jsx3Qo1b=k7d2SX4ABFNpMW0ikm91g@mail.gmail.com>
 <CAOazyz1aNuR_Um5-fuOWF7jA3zr+fN7BKgsA-FN_B1H-ZCbC_g@mail.gmail.com>
 <CAJU7zaK+cy7DyoJZ=M446NtgoU2ZJsEhrSoLj_f3SPY3WWZ8Cw@mail.gmail.com>
 <CAOazyz23U_LFJKac8rj4krVZp_4itnmcaoGbq=ZB0oXSJHjoeQ@mail.gmail.com>
 <CAJU7zaL1qOr=RgAUQGsqNkw-Cfu2QB=8N6GRRQHiFtKcSzvr5w@mail.gmail.com>
 <CAOazyz0XLzF0e0xF_Eyt-Z_zNdrfceZ_=EYzf5c6zKEMSYv0yg@mail.gmail.com>
 <CAOazyz3RmBeKcU7J1B99DHF-1TH=E4STTcGEDUjxLt+YNJiqUg@mail.gmail.com>
Message-ID: <CAJU7zaLm3_32vguJ2EG6+52fNi=9dJr6z1SMamgwDmdZmtyYPQ@mail.gmail.com>

On Fri, Dec 18, 2015 at 11:19 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> yes, but then I will have to add ENABLE_DOC conditional into the manpages.
>> not sure it makes it easier to maintain.
>> but I will post this alternative as well.
> I sent two (three) options:
> 1. split manpages to doc and non doc (I prefer this one :) )
> 2. leave manpages at doc/manpages but enter it directly from root.
> 3. like 2 but move manpages to root (as expected).
> Please make sure make dist is working, I am unsure I modified it correctly.

I applied version 2 but slightly modified:
https://gitlab.com/gnutls/gnutls/commit/af385d1552c0d5854db6db03c82e1e9b89e80b94

That version keeps --disable-doc working as it is now. To enable
manpages you'll need to use:
--disable-doc and --enable-manpages

regards,
Nikos


From alon.barlev at gmail.com  Fri Dec 18 16:34:01 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 17:34:01 +0200
Subject: [gnutls-devel] [PATCH] build: configure.ac: manpages cleanups
In-Reply-To: <CAJU7zaLm3_32vguJ2EG6+52fNi=9dJr6z1SMamgwDmdZmtyYPQ@mail.gmail.com>
References: <CAJU7zaLm3_32vguJ2EG6+52fNi=9dJr6z1SMamgwDmdZmtyYPQ@mail.gmail.com>
Message-ID: <1450452841-13398-1-git-send-email-alon.barlev@gmail.com>

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 configure.ac | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 23d7cd5..4efb937 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,16 +54,13 @@ AM_CONDITIONAL(ENABLE_DOC, test "$enable_doc" != "no")
 AC_ARG_ENABLE(manpages,
   AS_HELP_STRING([--enable-manpages], [install manpages even if disable-doc is given]),
     enable_manpages=$enableval,enable_manpages=auto)
-AM_CONDITIONAL(ENABLE_MANPAGES, test "$enable_manpages" != "no")
 
 if test "${enable_manpages}" = "auto";then
-  if test "$enable_doc" != "no";then
-    enable_manpages=yes
-  else
-    enable_manpages=no
-  fi
+  enable_manpages="${enable_doc}"
 fi
 
+AM_CONDITIONAL(ENABLE_MANPAGES, test "$enable_manpages" != "no")
+
 AC_ARG_ENABLE(tools,
   AS_HELP_STRING([--disable-tools], [don't compile any tools]),
     enable_tools=$enableval, enable_tools=yes)
-- 
2.4.10



From alon.barlev at gmail.com  Fri Dec 18 16:35:00 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 18 Dec 2015 17:35:00 +0200
Subject: [gnutls-devel] [PATCH] build: configure.ac: manpages cleanups
In-Reply-To: <1450452841-13398-1-git-send-email-alon.barlev@gmail.com>
References: <CAJU7zaLm3_32vguJ2EG6+52fNi=9dJr6z1SMamgwDmdZmtyYPQ@mail.gmail.com>
 <1450452841-13398-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <CAOazyz3Up2qguZqY0GmXM_ck+oLz1iUadTmQ0+2pFrhcHM4Ddw@mail.gmail.com>

On 18 December 2015 at 17:34, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
> ---
>  configure.ac | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
>

I think this is required as conditional was placed before set.


From kurt at roeckx.be  Sun Dec 20 15:34:09 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 20 Dec 2015 15:34:09 +0100
Subject: [gnutls-devel] Name constraint error?
Message-ID: <20151220143408.GA7942@roeckx.be>

Hi,

When trying to connect to cdn.it.auth.gr I get:
- Status: The certificate is NOT trusted. The certificate chain violates the signer's constraints.

However, I can't see anything wrong with it and NSS and OpenSSL
seem to be accepting it.


Kurt



From tim.kosse at filezilla-project.org  Sun Dec 20 15:34:36 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sun, 20 Dec 2015 15:34:36 +0100
Subject: [gnutls-devel] Implementing RFC 7633 to support mandatory OCSP
	stapling.
Message-ID: <5676BC7C.1070208@filezilla-project.org>

Hi,

I took a shot at implementing RFC 7633 which can be used to make OCSP
stapling mandatory.

Attached is a proof-of-concept series of patches that implements
checking for a missing certificate status during the handshake. I have
manually tested this functionality against
https://must-staple.serverhello.com/ and
https://must-staple-no-ocsp.serverhello.com/

Before continuing, I'd like your opinion on the patch series so far.


The things still missing which I'll implement after incorporating your
feedback:
- Documentation
- Tests
- Setting this extension in certificates and CSRs

Regards,
Tim Kosse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-If-we-have-sent-an-OCSP-status-request-and-have-not-.patch
Type: text/x-patch
Size: 3939 bytes
Desc: not available
URL: </pipermail/attachments/20151220/ca5b7ba1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-the-TLS-Features-extension-from-RFC-7633-to-the-.patch
Type: text/x-patch
Size: 1359 bytes
Desc: not available
URL: </pipermail/attachments/20151220/ca5b7ba1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Implement-functions-to-parse-the-TLSFeatures-X.509-e.patch
Type: text/x-patch
Size: 8287 bytes
Desc: not available
URL: </pipermail/attachments/20151220/ca5b7ba1/attachment-0002.bin>

From ametzler at bebt.de  Sun Dec 20 16:37:07 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 20 Dec 2015 16:37:07 +0100
Subject: [gnutls-devel] Name constraint error?
In-Reply-To: <20151220143408.GA7942@roeckx.be>
References: <20151220143408.GA7942@roeckx.be>
Message-ID: <20151220153707.GE1122@argenau.bebt.de>

On 2015-12-20 Kurt Roeckx <kurt at roeckx.be> wrote:
> Hi,

> When trying to connect to cdn.it.auth.gr I get:
> - Status: The certificate is NOT trusted. The certificate chain violates the signer's constraints.

> However, I can't see anything wrong with it and NSS and OpenSSL
> seem to be accepting it.
[...]

The error happens at the CA->intermed step.

host
	Issuer: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5
	Subject: C=GR,O=Aristotle University of Thessaloniki,OU=IT Center,CN=cdn.it.auth.gr

intermed CA
	Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
	Subject: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5

root CA
	Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
	Subject: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
		Name Constraints (not critical):
			Permitted:
				DNSname: .gr
				DNSname: .eu
				DNSname: .edu
				DNSname: .org
				RFC822Name: .gr
				RFC822Name: .eu
				RFC822Name: .edu
				RFC822Name: .org

I suspect that the Name Constraints might cause the error.

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 Dec 20 18:09:13 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 20 Dec 2015 19:09:13 +0200
Subject: [gnutls-devel] Name constraint error?
In-Reply-To: <20151220153707.GE1122@argenau.bebt.de>
References: <20151220143408.GA7942@roeckx.be>
 <20151220153707.GE1122@argenau.bebt.de>
Message-ID: <CAJU7zaLEgP0d1oHe8r1KUVKHDHZc7pVS3T4AE9ORjJMorAgE0A@mail.gmail.com>

On Sun, Dec 20, 2015 at 5:37 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> The error happens at the CA->intermed step.
> host
>         Issuer: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5
>         Subject: C=GR,O=Aristotle University of Thessaloniki,OU=IT Center,CN=cdn.it.auth.gr
> intermed CA
>         Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
>         Subject: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5
> root CA
>         Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
>         Subject: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
>                 Name Constraints (not critical):
>                         Permitted:
>                                 DNSname: .gr
>                                 DNSname: .eu
>                                 DNSname: .edu
>                                 DNSname: .org
>                                 RFC822Name: .gr
>                                 RFC822Name: .eu
>                                 RFC822Name: .edu
>                                 RFC822Name: .org
> I suspect that the Name Constraints might cause the error.

Indeed. That's one of the few CAs using name constraints and
unfortunately it uses them wrong.
I had an open issue at https://gitlab.com/gnutls/gnutls/issues/3
which was resolved at the 3.4.x branch.

regards,
Nikos


From kurt at roeckx.be  Sun Dec 20 18:35:26 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 20 Dec 2015 18:35:26 +0100
Subject: [gnutls-devel] Name constraint error?
In-Reply-To: <CAJU7zaLEgP0d1oHe8r1KUVKHDHZc7pVS3T4AE9ORjJMorAgE0A@mail.gmail.com>
References: <20151220143408.GA7942@roeckx.be>
 <20151220153707.GE1122@argenau.bebt.de>
 <CAJU7zaLEgP0d1oHe8r1KUVKHDHZc7pVS3T4AE9ORjJMorAgE0A@mail.gmail.com>
Message-ID: <20151220173526.GA20576@roeckx.be>

On Sun, Dec 20, 2015 at 07:09:13PM +0200, Nikos Mavrogiannopoulos wrote:
> On Sun, Dec 20, 2015 at 5:37 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> > The error happens at the CA->intermed step.
> > host
> >         Issuer: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5
> >         Subject: C=GR,O=Aristotle University of Thessaloniki,OU=IT Center,CN=cdn.it.auth.gr
> > intermed CA
> >         Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
> >         Subject: C=GR,O=Aristotle University of Thessaloniki,CN=Aristotle University of Thessaloniki Central CA R5
> > root CA
> >         Issuer: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
> >         Subject: C=GR,O=Hellenic Academic and Research Institutions Cert. Authority,CN=Hellenic Academic and Research Institutions RootCA 2011
> >                 Name Constraints (not critical):
> >                         Permitted:
> >                                 DNSname: .gr
> >                                 DNSname: .eu
> >                                 DNSname: .edu
> >                                 DNSname: .org
> >                                 RFC822Name: .gr
> >                                 RFC822Name: .eu
> >                                 RFC822Name: .edu
> >                                 RFC822Name: .org
> > I suspect that the Name Constraints might cause the error.
> 
> Indeed. That's one of the few CAs using name constraints and
> unfortunately it uses them wrong.
> I had an open issue at https://gitlab.com/gnutls/gnutls/issues/3
> which was resolved at the 3.4.x branch.

I couldn't remember the details earlier but this certificate is
exactly why OpenSSL changed it's behaviour about a year ago.


Kurt



From nmav at gnutls.org  Mon Dec 21 09:21:00 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Dec 2015 10:21:00 +0200
Subject: [gnutls-devel] Implementing RFC 7633 to support mandatory OCSP
	stapling.
In-Reply-To: <5676BC7C.1070208@filezilla-project.org>
References: <5676BC7C.1070208@filezilla-project.org>
Message-ID: <CAJU7zaJ1VEXLWgu=xc2=9otoikXOJUuqxdx6ZDvUkk_HNHD31Q@mail.gmail.com>

On Sun, Dec 20, 2015 at 4:34 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
> Hi,
> I took a shot at implementing RFC 7633 which can be used to make OCSP
> stapling mandatory.
> Attached is a proof-of-concept series of patches that implements
> checking for a missing certificate status during the handshake. I have
> manually tested this functionality against
> https://must-staple.serverhello.com/ and
> https://must-staple-no-ocsp.serverhello.com/
> Before continuing, I'd like your opinion on the patch series so far.

Thank you for the patch; it very is consistent with existing code. Do
you know any plans on other implementations to use/rely on that
extension?

Some comments:
1. "To proceed, first check whether we have requested the certificate status"
Even though it's a simple check I'd suggest to use
_gnutls_extension_list_check().

2. Would it make sense to use gnutls_x509_ext_tlsfeatures_get()
instead of gnutls_x509_crt_get_tlsfeature() to reduce the multiple
decodings of this extension in case more than one features are
present? In that case the checking for tlsfeatures would have to move
to a separate function.

regards,
Nikos


From kurt at roeckx.be  Mon Dec 21 10:33:52 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 21 Dec 2015 10:33:52 +0100
Subject: [gnutls-devel] Implementing RFC 7633 to support mandatory OCSP
 stapling.
In-Reply-To: <CAJU7zaJ1VEXLWgu=xc2=9otoikXOJUuqxdx6ZDvUkk_HNHD31Q@mail.gmail.com>
References: <5676BC7C.1070208@filezilla-project.org>
 <CAJU7zaJ1VEXLWgu=xc2=9otoikXOJUuqxdx6ZDvUkk_HNHD31Q@mail.gmail.com>
Message-ID: <20151221093352.GA23310@roeckx.be>

On Mon, Dec 21, 2015 at 10:21:00AM +0200, Nikos Mavrogiannopoulos wrote:
> On Sun, Dec 20, 2015 at 4:34 PM, Tim Kosse
> <tim.kosse at filezilla-project.org> wrote:
> > Hi,
> > I took a shot at implementing RFC 7633 which can be used to make OCSP
> > stapling mandatory.
> > Attached is a proof-of-concept series of patches that implements
> > checking for a missing certificate status during the handshake. I have
> > manually tested this functionality against
> > https://must-staple.serverhello.com/ and
> > https://must-staple-no-ocsp.serverhello.com/
> > Before continuing, I'd like your opinion on the patch series so far.
> 
> Thank you for the patch; it very is consistent with existing code. Do
> you know any plans on other implementations to use/rely on that
> extension?

OpenSSL has added support for setting and displaying it in the
certificate.  I think someone is also working on a patch to check
it in s_client.


Kurt



From jaak.ristioja at cyber.ee  Mon Dec 21 13:50:16 2015
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Mon, 21 Dec 2015 14:50:16 +0200
Subject: [gnutls-devel] Supported MAC algorithms
Message-ID: <5677F588.2030105@cyber.ee>

Hello!

The table of supported HMAC algorithms in the GnuTLS manual only lists
MAC_MD5, MAC_SHA1, MAC_SHA256 and MAC_AEAD, whereas the enum
gnutls_mac_algorithm_t in gnutls.h also lists GNUTLS_MAC_SHA384,
GNUTLS_MAC_SHA512, GNUTLS_MAC_SHA224 etc. Are these HMAC algorithms
really not supported or is the documentation incorrect?

The GnuTLS documentation doesn't clearly state whether the HMAC
implementations in GnuTLS are based on RFC 2104?

Best regards,
Jaak Ristioja


From tim.kosse at filezilla-project.org  Mon Dec 21 18:18:52 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Mon, 21 Dec 2015 18:18:52 +0100
Subject: [gnutls-devel] Implementing RFC 7633 to support mandatory OCSP
 stapling.
In-Reply-To: <CAJU7zaJ1VEXLWgu=xc2=9otoikXOJUuqxdx6ZDvUkk_HNHD31Q@mail.gmail.com>
References: <5676BC7C.1070208@filezilla-project.org>
 <CAJU7zaJ1VEXLWgu=xc2=9otoikXOJUuqxdx6ZDvUkk_HNHD31Q@mail.gmail.com>
Message-ID: <5678347C.8040802@filezilla-project.org>

On 2015-12-21 09:21, Nikos Mavrogiannopoulos wrote:
> Do you know any plans on other implementations to use/rely on
> that extension?

The latest version of Firefox Developer Edition already understands this
extension, so the NSS library should support it.

> Some comments:
> 1. "To proceed, first check whether we have requested the certificate status"
> Even though it's a simple check I'd suggest to use
> _gnutls_extension_list_check().

Excellent, didn't see this function.

> 2. Would it make sense to use gnutls_x509_ext_tlsfeatures_get()
> instead of gnutls_x509_crt_get_tlsfeature() to reduce the multiple
> decodings of this extension in case more than one features are
> present? In that case the checking for tlsfeatures would have to move
> to a separate function.

Yes, shouldn't be a problem.


Regards,
Tim


From peter.dettman at bouncycastle.org  Tue Dec 22 06:23:36 2015
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Tue, 22 Dec 2015 12:23:36 +0700
Subject: [gnutls-devel] DTLS max_fragment_length extension supported?
Message-ID: <5678DE58.5090309@bouncycastle.org>

Hi,
I am testing a development build of the BouncyCastle DTLS client against
the MacPorts build of GnuTLS (gnutls-serv 3.3.19).

At first it was not connecting, the client dropping packets after the
ServerHello for some reason. I eventually noticed that the client was
requesting max_fragment_length extension, and the server was accepting
it, agreeing on MaxFragmentLength.2^9(1). The client then appears to
ignore the Certificate message as it is too large. (Without that
extension, connections work fine).

See attached capture of the handshake start, noting the ServerHello with
max_fragment_length=1, and the Certificate message with Fragment Length 932.

I have no particular need for this functionality, but I figured I'd
report it, if only to get a second opinion on whether it's a bug in
gnutls-serv specifically, in GnuTLS generally, or some error in code or
understanding at my end.

Regards,
Pete Dettman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls_maxfrag.pcapng
Type: application/octet-stream
Size: 1920 bytes
Desc: not available
URL: </pipermail/attachments/20151222/8554adb1/attachment.obj>

From n.mavrogiannopoulos at gmail.com  Tue Dec 22 10:35:13 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 22 Dec 2015 11:35:13 +0200
Subject: [gnutls-devel] Supported MAC algorithms
In-Reply-To: <5677F588.2030105@cyber.ee>
References: <5677F588.2030105@cyber.ee>
Message-ID: <1450776913.26747.4.camel@gmail.com>

On Mon, 2015-12-21 at 14:50 +0200, Jaak Ristioja wrote:
> Hello!
> The table of supported HMAC algorithms in the GnuTLS manual only
> lists
> MAC_MD5, MAC_SHA1, MAC_SHA256 and MAC_AEAD, whereas the enum
> gnutls_mac_algorithm_t in gnutls.h also lists GNUTLS_MAC_SHA384,
> GNUTLS_MAC_SHA512, GNUTLS_MAC_SHA224 etc. Are these HMAC algorithms
> really not supported or is the documentation incorrect?

Hi Jaak,
?This table lists the algorithms supported in the TLS protocol. SHA224
and SHA512 are not supported. SHA384 is supported by some ciphersuites
and is indeed missing.

> The GnuTLS documentation doesn't clearly state whether the HMAC
> implementations in GnuTLS are based on RFC 2104?

Why would that matter? This section describes the algorithms used in
TLS, so it should be apparent that the HMAC construction used is the
one referenced by TLS. If that's not sufficient, please suggest some
text.

regards,
Nikos




From jaak.ristioja at cyber.ee  Tue Dec 22 11:12:47 2015
From: jaak.ristioja at cyber.ee (Jaak Ristioja)
Date: Tue, 22 Dec 2015 12:12:47 +0200
Subject: [gnutls-devel] Supported MAC algorithms
In-Reply-To: <1450776913.26747.4.camel@gmail.com>
References: <5677F588.2030105@cyber.ee> <1450776913.26747.4.camel@gmail.com>
Message-ID: <5679221F.9080709@cyber.ee>

On 22.12.2015 11:35, Nikos Mavrogiannopoulos wrote:
> On Mon, 2015-12-21 at 14:50 +0200, Jaak Ristioja wrote:
>> Hello!
>> The table of supported HMAC algorithms in the GnuTLS manual only
>> lists
>> MAC_MD5, MAC_SHA1, MAC_SHA256 and MAC_AEAD, whereas the enum
>> gnutls_mac_algorithm_t in gnutls.h also lists GNUTLS_MAC_SHA384,
>> GNUTLS_MAC_SHA512, GNUTLS_MAC_SHA224 etc. Are these HMAC algorithms
>> really not supported or is the documentation incorrect?
> 
> Hi Jaak,
>  This table lists the algorithms supported in the TLS protocol. SHA224
> and SHA512 are not supported. SHA384 is supported by some ciphersuites
> and is indeed missing.
> 
>> The GnuTLS documentation doesn't clearly state whether the HMAC
>> implementations in GnuTLS are based on RFC 2104?
> 
> Why would that matter? This section describes the algorithms used in
> TLS, so it should be apparent that the HMAC construction used is the
> one referenced by TLS. If that's not sufficient, please suggest some
> text.

I think it is confusing that subsection "8.3 Hash and HMAC functions"
which refers to the Table 3.2 of the supported HMAC algorithms with is
under section "8 Using GnuTLS as a cryptographic library" which I think
is rather TLS-agnostic. I think subsection 8.3 should have a separate
table listing all the algorithms supported by GnuTLS as a cryptographic
library, whereas the description of Table 3.2 should state "Supported
MAC algorithms in the TLS record layer" and the second paragraph under
3.3.1 should also be corrected accordingly.

Best regards,
Jaak


From nmav at gnutls.org  Tue Dec 22 16:21:21 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 Dec 2015 17:21:21 +0200
Subject: [gnutls-devel] Supported MAC algorithms
In-Reply-To: <5679221F.9080709@cyber.ee>
References: <5677F588.2030105@cyber.ee> <1450776913.26747.4.camel@gmail.com>
 <5679221F.9080709@cyber.ee>
Message-ID: <CAJU7zaJgEFd1++s4OebNSdVWWKn-=jigfzueravi05PYxgxmsw@mail.gmail.com>

On Tue, Dec 22, 2015 at 12:12 PM, Jaak Ristioja <jaak.ristioja at cyber.ee> wrote:
>>> The GnuTLS documentation doesn't clearly state whether the HMAC
>>> implementations in GnuTLS are based on RFC 2104?
>> Why would that matter? This section describes the algorithms used in
>> TLS, so it should be apparent that the HMAC construction used is the
>> one referenced by TLS. If that's not sufficient, please suggest some
>> text.
>
> I think it is confusing that subsection "8.3 Hash and HMAC functions"
> which refers to the Table 3.2 of the supported HMAC algorithms with is
> under section "8 Using GnuTLS as a cryptographic library" which I think
> is rather TLS-agnostic. I think subsection 8.3 should have a separate
> table listing all the algorithms supported by GnuTLS as a cryptographic
> library, whereas the description of Table 3.2 should state "Supported
> MAC algorithms in the TLS record layer" and the second paragraph under
> 3.3.1 should also be corrected accordingly.

You're right. I've committed an update which uses the whole list of
algorithms under the crypto section. Let me know if that addresses the
issue.
https://gitlab.com/gnutls/gnutls/commit/66e31a847fcd13c0374fea719f1191c6411f2fa6

regards,
Nikos


From nmav at gnutls.org  Tue Dec 22 16:42:57 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 Dec 2015 17:42:57 +0200
Subject: [gnutls-devel] DTLS max_fragment_length extension supported?
In-Reply-To: <5678DE58.5090309@bouncycastle.org>
References: <5678DE58.5090309@bouncycastle.org>
Message-ID: <CAJU7za+4sJbMGWymk-HvQ0YJ8FLNi2LZ2x5RPwdYL3pzUw95CA@mail.gmail.com>

On Tue, Dec 22, 2015 at 7:23 AM, Peter Dettman
<peter.dettman at bouncycastle.org> wrote:
> Hi,
> I am testing a development build of the BouncyCastle DTLS client against
> the MacPorts build of GnuTLS (gnutls-serv 3.3.19).
> At first it was not connecting, the client dropping packets after the
> ServerHello for some reason. I eventually noticed that the client was
> requesting max_fragment_length extension, and the server was accepting
> it, agreeing on MaxFragmentLength.2^9(1). The client then appears to
> ignore the Certificate message as it is too large. (Without that
> extension, connections work fine).
> See attached capture of the handshake start, noting the ServerHello with
> max_fragment_length=1, and the Certificate message with Fragment Length 932.
> I have no particular need for this functionality, but I figured I'd
> report it, if only to get a second opinion on whether it's a bug in
> gnutls-serv specifically, in GnuTLS generally, or some error in code or
> understanding at my end.

Thank you for reporting that. It seems like an issue in the handling
of this extension under DTLS. I've opened an issue with your report
at: https://gitlab.com/gnutls/gnutls/issues/61

regards,
Nikos


From ametzler at bebt.de  Sat Dec 26 18:28:10 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 26 Dec 2015 18:28:10 +0100
Subject: [gnutls-devel] [patch] trivial typo fixes
Message-ID: <20151226172810.GB20085@argenau.bebt.de>

Hello,

find attached a trivial patch to fix some typos. (Found by lintian).

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-some-typos.patch
Type: text/x-diff
Size: 4863 bytes
Desc: not available
URL: </pipermail/attachments/20151226/3f73c55a/attachment.patch>

From n.mavrogiannopoulos at gmail.com  Sun Dec 27 11:24:50 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 27 Dec 2015 12:24:50 +0200
Subject: [gnutls-devel] [patch] trivial typo fixes
In-Reply-To: <20151226172810.GB20085@argenau.bebt.de>
References: <20151226172810.GB20085@argenau.bebt.de>
Message-ID: <1451211890.22368.0.camel@gmail.com>

On Sat, 2015-12-26 at 18:28 +0100, Andreas Metzler wrote:
> Hello,
> 
> find attached a trivial patch to fix some typos. (Found by lintian).

Applied, thank you.