From tzz at lifelogs.com  Mon Apr  3 16:01:33 2017
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Mon, 03 Apr 2017 10:01:33 -0400
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <CAJU7zaLrLMUkL+_d8M1kxx3_aK024aqCzETVAoKRPF4qGot9zQ@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Fri, 31 Mar 2017 20:58:26
 +0200")
References: <20150207153406.GA7383@debian>
 <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian>
 <1423401290.2022.3.camel@gnutls.org> <87wpb83sfl.fsf_-_@lifelogs.com>
 <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
 <87inmq51yu.fsf@lifelogs.com>
 <CAJU7zaLrLMUkL+_d8M1kxx3_aK024aqCzETVAoKRPF4qGot9zQ@mail.gmail.com>
Message-ID: <87o9wd3802.fsf@lifelogs.com>

On Fri, 31 Mar 2017 20:58:26 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On Thu, Mar 30, 2017 at 3:27 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
>> So that's perfect. I had a feeling I was missing something :) Do you
>> think those functions could also be listed under the Cryptographic API
>> sections I cited?

NM> It's a historical reason they are in the Core API (crypto API didn't
NM> exist at the time). Now moving them to crypto.h would break existing
NM> software. I've added some text that several functions may not be
NM> listed in crypto API. If you have a better suggestion I'd appreciate a
NM> merge request.

Understood, and thanks. I'll do that.

NM> There are separate gnutls_mac_list() and gnutls_digest_list() which
NM> can be used to obtain the different sets.
>> 
>> Does it make sense to correlate MACs and digests, since digests are
>> currently a subset of MACs? You do that with AEAD ciphers (a subcase of
>> general ciphers).

NM> This correlation is only for HMACs. MACs like poly1305 and UMAC have
NM> no equivalent digest.

Right, so let me ask another way--can we say "these MACs are HMACs?"
through the API? It's unnecessary from the Emacs side to have a separate
list of digest algorithms if they are simply a subset of the MAC
algorithms.

The way I'm currently doing it is to get the MAC name and then try to
get a digest ID with the same name. If it works, I associate that digest
ID with the MAC, resulting in something like this plist:

"SHA224" (:mac-algorithm-id 9 :type gnutls-mac-algorithm :mac-algorithm-keysize 28 :mac-algorithm-noncesize 0 :digest-algorithm-id 9)

Another usage question: I can eliminate the numeric IDs and always get
them from the name when the functions are called. The risk of keeping
them in the plist is minimal, since the numbers won't change, but they
are exposing low-level implementation details to users. What would you
suggest? Is the overhead of getting the numeric ID from the name
negligible?

I'll ask here for a review of my code when it's ready, right now it's
still in progress (I have MACs and digests working, with tests). Thank
you for your kind assistance.

Ted


From rmbeer2 at gmail.com  Mon Apr  3 18:51:21 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Mon, 3 Apr 2017 13:51:21 -0300
Subject: [gnutls-help] I can't execute the lines from example server
In-Reply-To: <CAA0fXPvB9vz0Z_z-az+tNS4qS9qogZDuZ11j0ybUpL185Hwtiw@mail.gmail.com>
References: <CAA0fXPvB9vz0Z_z-az+tNS4qS9qogZDuZ11j0ybUpL185Hwtiw@mail.gmail.com>
Message-ID: <CAA0fXPvDrhH_1Y1faQx5ccrzT41VDAYNtuhhaW84LYKHgF5o3g@mail.gmail.com>

Hello, i still never receive the response. I need finish with this and go
to use the GnuTLS in my app. (Not have GnuTLS, all password is reading in
network!!)

If need any other information for fix this problem, askedme.

2017-03-27 14:27 GMT-03:00 Rm Beer <rmbeer2 at gmail.com>:

> Have problem with this example of the Server:
> https://www.gnutls.org/manual/html_node/Echo-server-with-X_0
> 02e509-authentication.html#Echo-server-with-X_002e509-authentication
>
> Get error in "PERFORMANCE:%SERVER_PRECEDENCE" and can't continue.
>
> I unknown why fail, unknown how to continue for take any data about of the
> problem. Anyone helpme with this?
> I also remove osrp and crl lines and still not work. Not found the
> SERVER_PRECEDENCE in the man help.
> i test all in openssl s_server/s_client for all certificates of pair
> key/cert for server and pair key/cert of client and with 1 CA for both. All
> certs is OK. (Also use from example for client from other web of gnutls)
>
> Never work with PERFOMANCE...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170403/3342c80d/attachment.html>

From dkg at fifthhorseman.net  Mon Apr  3 19:31:39 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 03 Apr 2017 13:31:39 -0400
Subject: [gnutls-help] I can't execute the lines from example server
In-Reply-To: <CAA0fXPvDrhH_1Y1faQx5ccrzT41VDAYNtuhhaW84LYKHgF5o3g@mail.gmail.com>
References: <CAA0fXPvB9vz0Z_z-az+tNS4qS9qogZDuZ11j0ybUpL185Hwtiw@mail.gmail.com>
 <CAA0fXPvDrhH_1Y1faQx5ccrzT41VDAYNtuhhaW84LYKHgF5o3g@mail.gmail.com>
Message-ID: <87inml4cuc.fsf@alice.fifthhorseman.net>

On Mon 2017-04-03 12:51:21 -0400, Rm Beer wrote:
> Hello, i still never receive the response. I need finish with this and go
> to use the GnuTLS in my app. (Not have GnuTLS, all password is reading in
> network!!)

What version of GnuTLS are you working with?  what does the
documentation that matches your version of GnuTLS recommend for the
priority string?  Have you tried it with "NORMAL" ?

>> Never work with PERFOMANCE...

This isn't how you spell PERFORMANCE -- i'm assuming it's a typo in your
e-mail, but i'm mentioning it here just in case the same typo slipped
into your code.

hth,

     --dkg


From nmav at gnutls.org  Tue Apr  4 10:45:54 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 4 Apr 2017 10:45:54 +0200
Subject: [gnutls-help] GnuTLS cryptographic API questions
In-Reply-To: <87o9wd3802.fsf@lifelogs.com>
References: <20150207153406.GA7383@debian> <1423387098.2022.1.camel@gnutls.org>
 <20150208120028.GA5557@debian> <1423401290.2022.3.camel@gnutls.org>
 <87wpb83sfl.fsf_-_@lifelogs.com>
 <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
 <87inmq51yu.fsf@lifelogs.com>
 <CAJU7zaLrLMUkL+_d8M1kxx3_aK024aqCzETVAoKRPF4qGot9zQ@mail.gmail.com>
 <87o9wd3802.fsf@lifelogs.com>
Message-ID: <CAJU7zaKfHBscsDAhcQMG1dzEAFxufVqn5sKt+38NVuZdsXczAg@mail.gmail.com>

On Mon, Apr 3, 2017 at 4:01 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> On Fri, 31 Mar 2017 20:58:26 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>
> NM> On Thu, Mar 30, 2017 at 3:27 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
>>> So that's perfect. I had a feeling I was missing something :) Do you
>>> think those functions could also be listed under the Cryptographic API
>>> sections I cited?
>
> NM> It's a historical reason they are in the Core API (crypto API didn't
> NM> exist at the time). Now moving them to crypto.h would break existing
> NM> software. I've added some text that several functions may not be
> NM> listed in crypto API. If you have a better suggestion I'd appreciate a
> NM> merge request.
>
> Understood, and thanks. I'll do that.
>
> NM> There are separate gnutls_mac_list() and gnutls_digest_list() which
> NM> can be used to obtain the different sets.
>>>
>>> Does it make sense to correlate MACs and digests, since digests are
>>> currently a subset of MACs? You do that with AEAD ciphers (a subcase of
>>> general ciphers).
>
> NM> This correlation is only for HMACs. MACs like poly1305 and UMAC have
> NM> no equivalent digest.
>
> Right, so let me ask another way--can we say "these MACs are HMACs?"
> through the API?

The wording is not correct as HMAC means a hash-based mac. However, as
far as the API is concerned, it can be exactly the same (and that's
how the gnutls api treats them, even though the naming is
unfortunate).

> It's unnecessary from the Emacs side to have a separate
> list of digest algorithms if they are simply a subset of the MAC
> algorithms.

In the past MAC algorithms were mostly hash based but today this trend
is changing. My bet would be that HMAC will be used less and less as
it results to slow algorithms, so MAC being a subset of Digests will
no longer hold.

> The way I'm currently doing it is to get the MAC name and then try to
> get a digest ID with the same name. If it works, I associate that digest
> ID with the MAC, resulting in something like this plist:
>
> "SHA224" (:mac-algorithm-id 9 :type gnutls-mac-algorithm :mac-algorithm-keysize 28 :mac-algorithm-noncesize 0 :digest-algorithm-id 9)
>
> Another usage question: I can eliminate the numeric IDs and always get
> them from the name when the functions are called. The risk of keeping
> them in the plist is minimal, since the numbers won't change, but they
> are exposing low-level implementation details to users. What would you
> suggest? Is the overhead of getting the numeric ID from the name
> negligible?

Do you mean relying on gnutls_mac_get_id()? I guess it makes sense.
You can rely on names as printed by " gnutls-cli -l".

regards,
Nikos


From rmbeer2 at gmail.com  Tue Apr  4 23:41:49 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Tue, 4 Apr 2017 18:41:49 -0300
Subject: [gnutls-help] Where find all the instructions for make all
 certificates?
Message-ID: <CAA0fXPvt7_euFhdL8UpkL_YgOoGj4vVvJp6U_9_gu0caT8fnPg@mail.gmail.com>

Where find all the instructions for make all certificates?
Is for this links:

https://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication

https://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

Also make a certificates as I thought it was better. Work good with
'openssl s_server' and 'openssl s_client' , but can't work with this
examples...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170404/2b233ef8/attachment.html>

From dkg at fifthhorseman.net  Wed Apr  5 00:29:31 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 04 Apr 2017 18:29:31 -0400
Subject: [gnutls-help] Where find all the instructions for make all
 certificates?
In-Reply-To: <CAA0fXPvt7_euFhdL8UpkL_YgOoGj4vVvJp6U_9_gu0caT8fnPg@mail.gmail.com>
References: <CAA0fXPvt7_euFhdL8UpkL_YgOoGj4vVvJp6U_9_gu0caT8fnPg@mail.gmail.com>
Message-ID: <871st724dw.fsf@alice.fifthhorseman.net>

hi Rm Beer--

On Tue 2017-04-04 17:41:49 -0400, Rm Beer wrote:
> Where find all the instructions for make all certificates?

It's not clear to me what you're asking.  Can you be more specific?  The
examples you link to are code, not system configuration.  certificates
are usually system configuration.

> Also make a certificates as I thought it was better. Work good with
> 'openssl s_server' and 'openssl s_client' , but can't work with this
> examples...

when you say "can't work", are you getting error messages?  when do you
get them?  what are they specifically?  how did you generate the
certificates specifically?

the more useful detail and specifics you can provide, the more likely
you will get useful help answering your questions.

    --dkg


From lavr at ncbi.nlm.nih.gov  Wed Apr  5 17:52:43 2017
From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C])
Date: Wed, 5 Apr 2017 15:52:43 +0000
Subject: [gnutls-help] DLL unload issues on Windows,
 MSVC2015 ReleaseDLL builds only
Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D5C982BE9@msgb06.nih.gov>

Hello,

We have recently had to work around a (very hard to get down to) issue of GNUTLS DLL's unloading bug that caused our (previously working) code start crashing way past the return from the main() function.

The crash happened when GNUTLS was attempting to deinit the mutexes that it created earlier (via the provided callbacks).  The reason was that since GNUTLS implicitly initializes itself (why, BTW?) in DllMain, any explicit global_init from our code just increased the init count, and global_deinit from our cleanup code, was called when the count was still 2, so no actual deinit occurred (and no mutexes have been freed).  Now, it looks like MVSC2015's RTL's ucrtbase.dll (that controls the app's heap) gets unloaded prior to GNUTLS DLL, zeroing up the heap base address, so any attempt to call free() lead to Access Violation (Exception 5) at address 0x74 (that's some offset that the heap manager uses to add to the base heap).  And that happened from GNUTLS's DLL fini (DESTRUCTOR) that followed ucrtbase.dll's fini sequence.

To work around, we have inserted a second global_deinit call to compensate for global_init (courtesy of DllMain), and so that it actually would do the cleanup.

We'd rather see a mutex leaking at the end of the process (we don't care, it's terminating, anyways) than to crash it altogether, because of the order that DLL's are unloading.  BTW, the run-time uses different version of free() in Debug mode, and so that does not crash at the end...

Regards,

Anton Lavrentiev
Contractor NIH/NLM/NCBI



From nmav at gnutls.org  Thu Apr  6 13:17:17 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 6 Apr 2017 13:17:17 +0200
Subject: [gnutls-help] DLL unload issues on Windows,
 MSVC2015 ReleaseDLL builds only
In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D5C982BE9@msgb06.nih.gov>
References: <5F8AAC04F9616747BC4CC0E803D5907D5C982BE9@msgb06.nih.gov>
Message-ID: <CAJU7zaKR4DsCnSR55nEq_C4h-Q8D0QAgkhgKdFZMdemqOizmog@mail.gmail.com>

On Wed, Apr 5, 2017 at 5:52 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
<lavr at ncbi.nlm.nih.gov> wrote:
> Hello,
>
> We have recently had to work around a (very hard to get down to) issue of GNUTLS DLL's unloading bug that caused our (previously working) code start crashing way past the return from the main() function.
>
> The crash happened when GNUTLS was attempting to deinit the mutexes that it created earlier (via the provided callbacks).  The reason was that since GNUTLS implicitly initializes itself (why, BTW?) in DllMain, any explicit global_init from our code just increased the init count, and global_deinit from our cleanup code, was called when the count was still 2, so no actual deinit occurred (and no mutexes have been freed).  Now, it looks like MVSC2015's RTL's ucrtbase.dll (that controls the app's heap) gets unloaded prior to GNUTLS DLL, zeroing up the heap base address, so any attempt to call free() lead to Access Violation (Exception 5) at address 0x74 (that's some offset that the heap manager uses to add to the base heap).  And that happened from GNUTLS's DLL fini (DESTRUCTOR) that followed ucrtbase.dll's fini sequence.
> To work around, we have inserted a second global_deinit call to compensate for global_init (courtesy of DllMain), and so that it actually would do the cleanup.

That's quite interesting case. Is that particular issue happening
because of the way you are using gnutls, or would this happen to most
users in windows? Do you have a suggestion on what can be improved to
avoid these crashes? Skipping the deinitialization completely in
windows could be an option, but that would create leaks to
applications that use it via the equivalent of dlopen().

btw. you can disable the transparent initialization with an
environment variable:
http://www.gnutls.org/manual/html_node/Initialization.html#Initialization

regards,
Nikos


From lavr at ncbi.nlm.nih.gov  Thu Apr  6 15:35:52 2017
From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C])
Date: Thu, 6 Apr 2017 13:35:52 +0000
Subject: [gnutls-help] DLL unload issues on Windows,
 MSVC2015 ReleaseDLL builds only
In-Reply-To: <CAJU7zaKR4DsCnSR55nEq_C4h-Q8D0QAgkhgKdFZMdemqOizmog@mail.gmail.com>
References: <5F8AAC04F9616747BC4CC0E803D5907D5C982BE9@msgb06.nih.gov>
 <CAJU7zaKR4DsCnSR55nEq_C4h-Q8D0QAgkhgKdFZMdemqOizmog@mail.gmail.com>
Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D5C982F78@msgb06.nih.gov>

> That's quite interesting case. Is that particular issue happening
> because of the way you are using gnutls, or would this happen to most
> users in windows?

All code that uses GNUTLS in our builds made by MSVC2015/ReleaseDLL/x64 exhibits this problem of crashing at the infamous address 0x74 at process termination...
Prior to using GNUTLS we set custom lock callbacks with gnutls_global_set_mutex()  (it's releasing all those locks that leads to calling free() with the app heap already gone).  Then we call gnutls_global_init() when begin using GNUTLS, and gnutls_global_deinit() when done with it.  We weren't aware of the (pretty big) change in behavior with auto-init from version 2 to 3 (somehow it escaped my attention).  As for the documentation,

http://www.gnutls.org/manual/html_node/Initialization.html#Initialization

says, "The resources allocated by the initialization process will be released on library deinitialization, or explicitly by calling gnutls_global_deinit."
Well, that's not 100% accurate with auto-init (and what's exactly we were dealing with):  if user's code called gnutls_global_init() (which is no-operation with auto-init), so the user's gnutls_global_deinit() is no-operation just as well.  So either gnutls_global_init() must _not_ be called at all, or gnutls_global_deinit() must be called plus-one the number of times of explicit global_init's, to make the actual cleanup happen.

I wasn't aware of the option to disable auto-init...  But it's rather cumbersome to use: the environment must be defined prior to the process start.  So any program that wants to avoid the auto-init must set it somehow.  If the binary is shipped out, there must be instructions, launch script or something to take care of the environment...  Simply put, it won't work easily.

Lastly, gnutls_global_set_mutex should be documented of having a side effect of doing the global_deinit() / global_init() sequence internally -- this is important for counting the number of init / deinit pairs.

> Do you have a suggestion on what can be improved to avoid these crashes?

It seems that there's no one-fits-all solution here.  While auto-init is a great feature in general, you can make it a soft-init; so any explicit global_init() would override it and make the count of initializations restarted.  So last explicit global_deinit() will do the actual cleanup.  global_deinit() should be able to do the cleanup from the soft state as well (when there was no explicit global_init() issued from the user code, but only global_deinit()).

Anton Lavrentiev
Contractor NIH/NLM/NCBI


From nmav at gnutls.org  Fri Apr  7 08:14:11 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 07 Apr 2017 08:14:11 +0200
Subject: [gnutls-help] gnutls 3.5.11
Message-ID: <1491545651.4737.2.camel@gnutls.org>

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

* Version 3.5.11 (released 2017-04-07)

** gnutls.pc: do not include libtool options into Libs.private.

** libgnutls: Fixed issue when rehandshaking without a client certificate in
???a session which initially used one. Reported by Frantisek Sumsal.

** libgnutls: Addressed read of 4 bytes past the end of buffer in OpenPGP
???certificate parsing. Issues found using oss-fuzz project and were fixed
???by Alex Gaynor:
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=737
???https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=824

** libgnutls: Introduced locks in gnutls_pkcs11_privkey_t structure access.
???That allows PKCS#11 operations such as signing to be performed with the
???same object from multiple threads.

** libgnutls: Added support for MacOSX key chain for obtaining trust store's
???root CA certificates. That is, gnutls_x509_trust_list_add_system_trust() and
???gnutls_certificate_set_x509_system_trust() will load the certificates from
???the key chain. That also means that we no longer check for a default trust
???store file in configure when building on MacOSX (unless explicitly asked to).
???Patch by David Caldwell.

** libgnutls: when disabling OpenPGP authentication, the resulting library
???is ABI compatible (with openpgp related functions being stubs that fail
???on invocation).

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


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

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

Here are the XZ compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos


From fgunbin at fastmail.fm  Fri Apr  7 16:56:12 2017
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Fri, 07 Apr 2017 17:56:12 +0300
Subject: [gnutls-help] [gnutls-devel] gnutls 3.5.11
In-Reply-To: <1491545651.4737.2.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Fri, 07 Apr 2017 08:14:11 +0200")
References: <1491545651.4737.2.camel@gnutls.org>
Message-ID: <m21st45ks3.fsf@fastmail.fm>

Hello,

I seem to have trouble building with gcc-6.3.0 on macOS, can you help
please?

Filipp

/System/Library/Frameworks/CoreFoundation.framework/Headers/CFDateFormatter.h:53:34: error: 'introduced' undeclared here (not in a function)
     kCFISO8601DateFormatWithYear API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0)) = (1UL << 0),
                                  ^
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFURL.h:777:39: error: 'deprecated' undeclared here (not in a function)
 const CFStringRef kCFURLLabelColorKey API_DEPRECATED("Use NSURLLabelColorKey", macosx(10.6, 10.12), ios(4.0, 10.0), watchos(2.0, 3.0), tvos(9.0, 10.0));
                                       ^
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFURL.h:777:39: error: 'message' undeclared here (not in a function)
 const CFStringRef kCFURLLabelColorKey API_DEPRECATED("Use NSURLLabelColorKey", macosx(10.6, 10.12), ios(4.0, 10.0), watchos(2.0, 3.0), tvos(9.0, 10.0));
                                       ^
In file included from /System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32:0,
                 from /System/Library/Frameworks/Security.framework/Headers/Security.h:43,
                 from system/certs.c:49:
/System/Library/Frameworks/Security.framework/Headers/Authorization.h:192:7: error: variably modified 'bytes' at file scope
  char bytes[kAuthorizationExternalFormLength];


From rmbeer2 at gmail.com  Sat Apr  8 04:05:29 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Fri, 7 Apr 2017 23:05:29 -0300
Subject: [gnutls-help] In the wiki have a incomplete example
Message-ID: <CAA0fXPu7A7+2EicJczT47P5MWU_VgqTKEsZHquCEx0sa5SaJZA@mail.gmail.com>

In this two examples not have the command for make the certificates:

https://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication
https://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

How to make the certificates with openssl for this examples? I need it for
work with examples, If anyone is so kind to tell me. thank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170407/58457b72/attachment-0001.html>

From nmav at gnutls.org  Sat Apr  8 09:41:51 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Apr 2017 09:41:51 +0200
Subject: [gnutls-help] [gnutls-devel] gnutls 3.5.11
In-Reply-To: <m21st45ks3.fsf@fastmail.fm>
References: <1491545651.4737.2.camel@gnutls.org> <m21st45ks3.fsf@fastmail.fm>
Message-ID: <1491637311.2343.1.camel@gnutls.org>

On Fri, 2017-04-07 at 17:56 +0300, Filipp Gunbin wrote:
> Hello,
> 
> I seem to have trouble building with gcc-6.3.0 on macOS, can you help
> please?

It seems that certain system headers do not compile with gcc on macosx.
You'll have to use clang at this point. Please follow up at:
https://gitlab.com/gnutls/gnutls/merge_requests/342

regards,
Nikos



From fgunbin at fastmail.fm  Mon Apr 10 15:56:31 2017
From: fgunbin at fastmail.fm (Filipp Gunbin)
Date: Mon, 10 Apr 2017 16:56:31 +0300
Subject: [gnutls-help] [gnutls-devel] gnutls 3.5.11
In-Reply-To: <1491637311.2343.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Sat, 08 Apr 2017 09:41:51 +0200")
References: <1491545651.4737.2.camel@gnutls.org> <m21st45ks3.fsf@fastmail.fm>
 <1491637311.2343.1.camel@gnutls.org>
Message-ID: <m2d1ck4b8w.fsf@fastmail.fm>

On 08/04/2017 09:41 +0200, Nikos Mavrogiannopoulos wrote:

> On Fri, 2017-04-07 at 17:56 +0300, Filipp Gunbin wrote:
>> Hello,
>> 
>> I seem to have trouble building with gcc-6.3.0 on macOS, can you help
>> please?
>
> It seems that certain system headers do not compile with gcc on macosx.
> You'll have to use clang at this point. Please follow up at:
> https://gitlab.com/gnutls/gnutls/merge_requests/342

Thanks!


From rmbeer2 at gmail.com  Tue Apr 11 19:29:21 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Tue, 11 Apr 2017 14:29:21 -0300
Subject: [gnutls-help] Problem with certificates of example files
Message-ID: <CAA0fXPvZRgWLbcH-E9Fw0esyp=XsegtWHxTEs5UXT_fejWNFtw@mail.gmail.com>

Is with this two examples:

https://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication
https://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

I need make the certificates for my app that exist in my web site:
http://superpez.ddns.net/ , by several mouth can't use the TLS
communication and this is really bad. Can anyone giveme the complete
example with exact instructions of openssl for work with GnuTLS? Thank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170411/8137d825/attachment.html>

From rmbeer2 at gmail.com  Wed Apr 12 23:34:02 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Wed, 12 Apr 2017 18:34:02 -0300
Subject: [gnutls-help] Problem with certificates of example files
In-Reply-To: <CAA0fXPvZRgWLbcH-E9Fw0esyp=XsegtWHxTEs5UXT_fejWNFtw@mail.gmail.com>
References: <CAA0fXPvZRgWLbcH-E9Fw0esyp=XsegtWHxTEs5UXT_fejWNFtw@mail.gmail.com>
Message-ID: <CAA0fXPtMJKYZE9Z091_jYmPWbVAHSpq+PjGcLObQwkBe9OQZ7g@mail.gmail.com>

i really need help with this...

2017-04-11 14:29 GMT-03:00 Rm Beer <rmbeer2 at gmail.com>:

> Is with this two examples:
>
> https://www.gnutls.org/manual/html_node/Echo-server-with-X_
> 002e509-authentication.html#Echo-server-with-X_002e509-authentication
> https://www.gnutls.org/manual/html_node/Simple-client-
> example-with-X_002e509-certificate-support.html#
> Simple-client-example-with-X_002e509-certificate-support
>
> I need make the certificates for my app that exist in my web site:
> http://superpez.ddns.net/ , by several mouth can't use the TLS
> communication and this is really bad. Can anyone giveme the complete
> example with exact instructions of openssl for work with GnuTLS? Thank.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170412/021d683f/attachment.html>

From tzz at lifelogs.com  Sat Apr 15 13:45:43 2017
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Sat, 15 Apr 2017 07:45:43 -0400
Subject: [gnutls-help] GnuTLS cryptographic API questions
References: <20150207153406.GA7383@debian>
 <1423387098.2022.1.camel@gnutls.org> <20150208120028.GA5557@debian>
 <1423401290.2022.3.camel@gnutls.org> <87wpb83sfl.fsf_-_@lifelogs.com>
 <CAJU7zaJB35h0V1KxoMes84M6JjuZH9hg7F1bp_UyYfoLTR0Hhg@mail.gmail.com>
 <87inmq51yu.fsf@lifelogs.com>
 <CAJU7zaLrLMUkL+_d8M1kxx3_aK024aqCzETVAoKRPF4qGot9zQ@mail.gmail.com>
 <87o9wd3802.fsf@lifelogs.com>
 <CAJU7zaKfHBscsDAhcQMG1dzEAFxufVqn5sKt+38NVuZdsXczAg@mail.gmail.com>
Message-ID: <87o9vxx5aw.fsf@lifelogs.com>

I put the Emacs GnuTLS crypto integration code up for review:

https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00313.html

The original work was against libnettle, so the branch is still called
`scratch/tzz/nettle` and lives in the emacs.git master repo.

I also pushed to a PR branch on gitlab.com since that site also hosts
GnuTLS, to make it easier for the GnuTLS developers to review and
comment:

https://gitlab.com/emacs-ci/emacs/merge_requests/2

There is one update to my original list from emacs-devel:

* "the AEAD ciphers "CHACHA20-POLY1305" "AES-128-CCM-8" "AES-256-CCM-8"
  are not working yet."--they are now

I'll keep updating the GitLab PR and the emacs.git branch as I get
reviews and comments.

Questions for the GnuTLS developers:

* are my names for functions and cipher/mac properties reasonable? Is my
  classification of macs and ciphers all right?

* For non-AEAD output I'm allocating exactly equal blocks to the inputs. For
  AEAD output I'm allocating input blocks + tag size. Is that good?

* any code smells or bad practices?

Thanks
Ted


From rmbeer2 at gmail.com  Mon Apr 17 00:18:51 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Sun, 16 Apr 2017 19:18:51 -0300
Subject: [gnutls-help] Hello???
Message-ID: <CAA0fXPs4SFwoNFy1Gq8-iEQSfPxexdttbO-aocR813C011=atA@mail.gmail.com>

i'm ignored? Why anyone readme???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170416/5911ed5a/attachment.html>

From nmav at gnutls.org  Thu Apr 20 17:33:52 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Apr 2017 17:33:52 +0200
Subject: [gnutls-help] DLL unload issues on Windows,
 MSVC2015 ReleaseDLL builds only
In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D5C982F78@msgb06.nih.gov>
References: <5F8AAC04F9616747BC4CC0E803D5907D5C982BE9@msgb06.nih.gov>
 <CAJU7zaKR4DsCnSR55nEq_C4h-Q8D0QAgkhgKdFZMdemqOizmog@mail.gmail.com>
 <5F8AAC04F9616747BC4CC0E803D5907D5C982F78@msgb06.nih.gov>
Message-ID: <CAJU7za+7vuxn1xAcPF0gMKKv=xmzAfSOT_7jnS4wg7ioseUTAA@mail.gmail.com>

On Thu, Apr 6, 2017 at 3:35 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
<lavr at ncbi.nlm.nih.gov> wrote:
>> That's quite interesting case. Is that particular issue happening
>> because of the way you are using gnutls, or would this happen to most
>> users in windows?
>
> All code that uses GNUTLS in our builds made by MSVC2015/ReleaseDLL/x64 exhibits this problem of crashing at the infamous address 0x74 at process termination...
> Prior to using GNUTLS we set custom lock callbacks with gnutls_global_set_mutex()  (it's releasing all those locks that leads to calling free() with the app heap already gone).  Then we call gnutls_global_init() when begin using GNUTLS, and gnutls_global_deinit() when done with it.  We weren't aware of the (pretty big) change in behavior with auto-init from version 2 to 3 (somehow it escaped my attention).  As for the documentation,
>
> http://www.gnutls.org/manual/html_node/Initialization.html#Initialization
>
> says, "The resources allocated by the initialization process will be released on library deinitialization, or explicitly by calling gnutls_global_deinit."
> Well, that's not 100% accurate with auto-init (and what's exactly we were dealing with):  if user's code called gnutls_global_init() (which is no-operation with auto-init), so the user's gnutls_global_deinit() is no-operation just as well.  So either gnutls_global_init() must _not_ be called at all, or gnutls_global_deinit() must be called plus-one the number of times of explicit global_init's, to make the actual cleanup happen.

Thanks. I've committed a fix addressing that at documentation, by
removing the "or explicitly ... " part.
https://gitlab.com/gnutls/gnutls/commit/89d4aeb37f7028a033334361eb14f2bef095dc75

> I wasn't aware of the option to disable auto-init...  But it's rather cumbersome to use: the environment must be defined prior to the process start.  So any program that wants to avoid the auto-init must set it somehow.  If the binary is shipped out, there must be instructions, launch script or something to take care of the environment...  Simply put, it won't work easily.
>
> Lastly, gnutls_global_set_mutex should be documented of having a side effect of doing the global_deinit() / global_init() sequence internally -- this is important for counting the number of init / deinit pairs.
>
>> Do you have a suggestion on what can be improved to avoid these crashes?
> It seems that there's no one-fits-all solution here.  While auto-init is a great feature in general, you can make it a soft-init; so any explicit global_init() would override it and make the count of initializations restarted.  So last explicit global_deinit() will do the actual cleanup.  global_deinit() should be able to do the cleanup from the soft state as well (when there was no explicit global_init() issued from the user code, but only global_deinit()).

That unfortunately is too late to be added without causing problems to
existing programs. We can improve documentation though.

regards,
Nikos


From rmbeer2 at gmail.com  Sat Apr 22 02:28:08 2017
From: rmbeer2 at gmail.com (Rm Beer)
Date: Fri, 21 Apr 2017 21:28:08 -0300
Subject: [gnutls-help] [BUG] Incomplete examples
Message-ID: <CAA0fXPut77-Td-ajT4uKNywqtuGV9zpgVEWgAbNDQJvOaFiQsQ@mail.gmail.com>

This examples not have how to make the certificates:

https://www.gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication
https://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support

tellme if fix the examples. thank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170421/3bb83f41/attachment.html>

From w at uter.be  Sun Apr 23 20:51:45 2017
From: w at uter.be (Wouter Verhelst)
Date: Sun, 23 Apr 2017 20:51:45 +0200
Subject: [gnutls-help] Decoding the status parameter in
 gnutls_certificate_verify_peers2
Message-ID: <20170423185145.kgg7amwcdqktylgm@grep.be>

Hi,

gnutls_certificate_verify_peers2 is documented to have two parameters; a
gnutls_session_t and an unsigned int *status. The info page has these
two things to say about that status parameter:

    STATUS: is the output of the verification

and

   *Returns:* 'GNUTLS_E_SUCCESS' (0) when the validation is performed,
    or a negative error code otherwise.  A sucessful error code means
    that the 'status' parameter must be checked to obtain the
    validation status.

Unfortunately, it does not explain *how* one must check the "status"
parameter. I originally believed that the contents of the "status"
parameter should be 0, but now suddenly my test suite starts to fail
because status has changed to something else, and I can't figure out
what it means.

As such, I have two questions:
- What do I need to do to decode the "status" parameter?
- Why is this not documented in the documentation for verify_peers2 (and
  likewise, for verify_peers and verify_peers3)?

Thanks,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12


From nmav at gnutls.org  Mon Apr 24 13:29:05 2017
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 24 Apr 2017 13:29:05 +0200
Subject: [gnutls-help] Decoding the status parameter in
 gnutls_certificate_verify_peers2
In-Reply-To: <20170423185145.kgg7amwcdqktylgm@grep.be>
References: <20170423185145.kgg7amwcdqktylgm@grep.be>
Message-ID: <CAJU7zaK-Lw995goNpnMq4dYmKKWruKJwU+hjTEuPyZGScU5+yg@mail.gmail.com>

On Sun, Apr 23, 2017 at 8:51 PM, Wouter Verhelst <w at uter.be> wrote:
> Hi,
>
> gnutls_certificate_verify_peers2 is documented to have two parameters; a
> gnutls_session_t and an unsigned int *status. The info page has these
> two things to say about that status parameter:
>
>     STATUS: is the output of the verification
>
> and
>
>    *Returns:* 'GNUTLS_E_SUCCESS' (0) when the validation is performed,
>     or a negative error code otherwise.  A sucessful error code means
>     that the 'status' parameter must be checked to obtain the
>     validation status.
>
> Unfortunately, it does not explain *how* one must check the "status"
> parameter. I originally believed that the contents of the "status"
> parameter should be 0, but now suddenly my test suite starts to fail
> because status has changed to something else, and I can't figure out
> what it means.

In my system with gnutls 3.5.11 the manpage mentions:
"This  function  will verify the peer's certificate and store the
status in the  status variable
 as a bitwise or'd gnutls_certificate_status_t values or zero if  the
certificate  is  trusted."

Does this answer your question?

regards,
Nikos


From w at uter.be  Mon Apr 24 18:28:32 2017
From: w at uter.be (Wouter Verhelst)
Date: Mon, 24 Apr 2017 18:28:32 +0200
Subject: [gnutls-help] Decoding the status parameter in
 gnutls_certificate_verify_peers2
In-Reply-To: <CAJU7zaK-Lw995goNpnMq4dYmKKWruKJwU+hjTEuPyZGScU5+yg@mail.gmail.com>
References: <20170423185145.kgg7amwcdqktylgm@grep.be>
 <CAJU7zaK-Lw995goNpnMq4dYmKKWruKJwU+hjTEuPyZGScU5+yg@mail.gmail.com>
Message-ID: <20170424162832.ukqybwtdzpuwyfcd@grep.be>

On Mon, Apr 24, 2017 at 01:29:05PM +0200, Nikos Mavrogiannopoulos wrote:
> On Sun, Apr 23, 2017 at 8:51 PM, Wouter Verhelst <w at uter.be> wrote:
> > Hi,
> >
> > gnutls_certificate_verify_peers2 is documented to have two parameters; a
> > gnutls_session_t and an unsigned int *status. The info page has these
> > two things to say about that status parameter:
> >
> >     STATUS: is the output of the verification
> >
> > and
> >
> >    *Returns:* 'GNUTLS_E_SUCCESS' (0) when the validation is performed,
> >     or a negative error code otherwise.  A sucessful error code means
> >     that the 'status' parameter must be checked to obtain the
> >     validation status.
> >
> > Unfortunately, it does not explain *how* one must check the "status"
> > parameter. I originally believed that the contents of the "status"
> > parameter should be 0, but now suddenly my test suite starts to fail
> > because status has changed to something else, and I can't figure out
> > what it means.
> 
> In my system with gnutls 3.5.11 the manpage mentions:
> "This  function  will verify the peer's certificate and store the
> status in the  status variable
>  as a bitwise or'd gnutls_certificate_status_t values or zero if  the
> certificate  is  trusted."
> 
> Does this answer your question?

It does, thank you. Of course, it does not explain why the info page
does not document this -- should I open a bug report for that?

(in case you were wondering, it turned out the test suite's certificate,
which is committed into the repository to avoid having to generate a new
one every time the test suite runs, has now expired; I simply need to
generate a new one)

Thanks,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12


From ametzler at bebt.de  Mon Apr 24 19:26:24 2017
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 24 Apr 2017 19:26:24 +0200
Subject: [gnutls-help] Decoding the status parameter in
 gnutls_certificate_verify_peers2
In-Reply-To: <20170424162832.ukqybwtdzpuwyfcd@grep.be>
References: <20170423185145.kgg7amwcdqktylgm@grep.be>
 <CAJU7zaK-Lw995goNpnMq4dYmKKWruKJwU+hjTEuPyZGScU5+yg@mail.gmail.com>
 <20170424162832.ukqybwtdzpuwyfcd@grep.be>
Message-ID: <20170424172624.jmff7s2lxrsh4rqi@argenau.bebt.de>

On 2017-04-24 Wouter Verhelst <w at uter.be> wrote:
> On Mon, Apr 24, 2017 at 01:29:05PM +0200, Nikos Mavrogiannopoulos wrote:
[...]
> > Does this answer your question?

> It does, thank you. Of course, it does not explain why the info page
> does not document this -- should I open a bug report for that?

Hello,

what version of GnuTLS are you using? I have just checked Debian's
gnutls-doc package version 3.5.8-5 and the info documentation seems to
be complete:
|gnutls_certificate_verify_peers2
|--------------------------------
|
| -- Function: int gnutls_certificate_verify_peers2 (gnutls_session_t
|          SESSION, unsigned int * STATUS)
|     SESSION: is a gnutls session
|
|     STATUS: is the output of the verification
|
|     This function will verify the peer's certificate and store the
|     status in the 'status' variable as a bitwise or'd
|     gnutls_certificate_status_t values or zero if the certificate is
|     trusted.  Note that value in 'status' is set only when the return
|     value of this function is success (i.e, failure to trust a
|     certificate does not imply a negative return value).  The default
|     verification flags used by this function can be overridden using
|     'gnutls_certificate_set_verify_flags()' .
|
|     This function will take into account the OCSP Certificate Status
|     TLS extension, as well as the following X.509 certificate
|     extensions: Name Constraints, Key Usage, and Basic Constraints
|     (pathlen).
|
|     To avoid denial of service attacks some default upper limits
|     regarding the certificate key size and chain size are set.  To
|     override them use 'gnutls_certificate_set_verify_limits()' .
|
|     Note that you must also check the peer's name in order to check if
|     the verified certificate belongs to the actual peer, see
|     'gnutls_x509_crt_check_hostname()' , or use
|     'gnutls_certificate_verify_peers3()' .
|
|     *Returns:* 'GNUTLS_E_SUCCESS' (0) when the validation is performed,
|     or a negative error code otherwise.  A sucessful error code means
|     that the 'status' parameter must be checked to obtain the
|     validation status.

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'