From ametzler at downhill.at.eu.org Wed May 2 18:32:05 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 2 May 2012 18:32:05 +0200 Subject: help me pleasssse In-Reply-To: References: Message-ID: <20120502163203.GA1860@downhill.g.la> On 2012-04-30 Francesco Viscomi wrote: > Hi, > i'm trying to install GnuTLS but i'm going to get crazy. > in the directory*, where i download the package gnutls-3.0.8, i run > .*** > /configure > then > run make > and then > as root run make install > everything seems to goes well, but in the directory -usr/local/bin i not > find the script libgnutls-config This was dropped ages ago: Quoting NEWS: * Version 2.8.0 (released 2009-05-27) [...] *** Old libgnutls.m4 and libgnutls-config scripts removed. Please use pkg-config instead. ------------ cu andreas From nmav at gnutls.org Sat May 5 19:33:51 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 May 2012 19:33:51 +0200 Subject: gnutls 2.12.19 Message-ID: <4FA5647F.6000405@gnutls.org> Hello, I've just released gnutls 2.12.19. It includes several bug fixes. Version 2.12.19 (released 2012-05-05) ** libgnutls: When decoding a PKCS #11 URL the pin-source field is assumed to be a file that stores the pin. Based on patch by David Smith. ** libgnutls: Added strict tests in Diffie-Hellman and SRP key exchange public keys. ** minitasn1: Upgraded to libtasn1 version 2.13 (pre-release). ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.19.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From dam at opencsw.org Sat May 5 19:56:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 May 2012 19:56:47 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte> Message-ID: Hi Niels, (adding bug-gnulib@) Am 27.04.2012 um 17:24 schrieb Niels M?ller: > Simon Josefsson writes: >> Yes. Understanding what the differences is, and which one is right, >> seems useful first though. If the problem is in gnulib, we can fix >> that and GnuTLS will have the new variant soon. > > Quoting my investigation from an old (off-list) email thread, from > November last year: > > And the problem seems to be that inttypes.h doesn't define int_fast8_t > types. And then AX_CREATE_STDINT_H (used by nettle) and gnulib (used by > gnutls) both decide to define them, and they do that in an incompatible > way. > > --- > > From a quick look at gl/stdint.h.in and on posted error messages, I > think glib uses long for all of int_fast8_t, int_fast16_t and > int_fast32_t, and int64_t for int_fast64_t, while nettle uses int8_t, > int, int32_t and int64_t. > > --- > >>> Actually, one ought to have a look at the definitions in the stdint.h >>> provided by gcc (and at the definitions in the solaris10 stdint.h), and >>> make sure the definitions of the int_fast* types are equivalent. >>> Otherwise one might end up with subtle ABI differences and errors when >>> linking together code compiled by different compilers. >> >> Agreed. > > I did a quick check. The following seems to be the correct sizes: > > int_fast8_t: 1 > int_fast16_t: 4 > int_fast32_t: 4 > int_fast64_t: 8 > > This is using sizeof on the types defined in stdint.h, trying: > > gcc -m32 on solaris 9 > gcc -m64 on solaris 9 > cc -m32 on solaris 10 > cc -m64 on solaris 10 > > Remarkably enough, they all agree. I also get the same sizes from > nettle-stdint.h, for both 32 bit and 64 bit configurations. So I think > nettle (or really, AX_CREATE_STDINT_H) gets this right. > > While if I understand gl correctly, it uses 4,4,4,8 for a 32-bit build > and 8,8,8,8 for a 64-bit build (the size of long is different). This > seems wrong. Sure, these are perfectly ok sizes according to C99, but > they differ from the sparc conventions (and possibly conventions for > other architectures as well). I see different possibilities on how this can be resolved: 1. nettle uses the gnulib definitions 2. gnulib changes the definitions to conform to nettle Maybe someone from the gnulib list can give some more advice on this? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From nisse at lysator.liu.se Sat May 5 21:19:09 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Sat, 05 May 2012 21:19:09 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: (Dagobert Michelsen's message of "Sat, 5 May 2012 19:56:47 +0200") References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

Message-ID: Dagobert Michelsen writes: > I see different possibilities on how this can be resolved: > > 1. nettle uses the gnulib definitions I currently have no plans to switch to using gnulib. As far as I'm aware, there's no problem with the types which nettle actually uses. So it would be a reasonable workaround to simply not define the int_fast*_t types; then they won't collide with the incompatible definitions gnutls gets from gnulib. Question is just what's the least intrusive way to do that (*if* it's easy to avoid, I'd prefer not to modify the definition of AX_CREATE_STDINT_H). I would appreciate if you can try the workarounds I suggested the other day and let me know how it works. > 2. gnulib changes the definitions to conform to nettle The problem with gnulib is not primarily that it doesn't "conform to nettle", but that it defines some types in a way that differs both from on later releases on the OS (where the types are included), and from the definition in the stdint.h which comes with gcc. So code which uses the int_fast*_t types and relies on gnulib will get a slightly different ABI if compiled on SunOS-5.9 (or earlier) using Sun's compiler, than if compiled with gcc on the same system, or compiled with Sun's compiler on any later release of the OS. I think that's what needs to be fixed in gnulib. Do the gnulib folks agree? Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From eggert at cs.ucla.edu Sun May 6 07:02:20 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sat, 05 May 2012 22:02:20 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

Message-ID: <4FA605DC.5020400@cs.ucla.edu> On 05/05/2012 12:19 PM, Niels M?ller wrote: > So code which uses the int_fast*_t types and relies on gnulib will get a > slightly different ABI Generally speaking, it's unwise to use the int_fast*_t types in a public header file. This is a documented issue in Gnulib. It's hard to imagine a general fix for this. From nisse at lysator.liu.se Sun May 6 09:13:43 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Sun, 06 May 2012 09:13:43 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA605DC.5020400@cs.ucla.edu> (Paul Eggert's message of "Sat, 05 May 2012 22:02:20 -0700") References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> Message-ID: Paul Eggert writes: > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. Why (feel free to point to the relevant section of gnulib docs, if it's explained well there)? Maybe nobody uses these types so it's an academic issue, but if these types are used in the interface to any library (possibly some system library), then it's important that applications agree on the definition. To me, it seems like the authoritative definition of int_fast*_t ought to be the system's ABI specification. And in the case of SunOS-5.9, where the types are missing, I think it makes the most sense to adopt the ABI of SunOS-5.10. Which also seems to be what gcc does. I'm a bit confused by your statement. I had the impression that gnulib *does* fall back on the definitions in public headers like and , for the types which *are* defined there. And that's why nettle and gnutls seem to work together on SunOS-10. Correct? > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. One possibility might be to not define the types at all, unless the gnulib application *explicitly* asks for them. Lots of applications want uint32_t, and I imagine a lot fewer have any need for int_fast*_t. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From dam at opencsw.org Sun May 6 09:47:16 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 6 May 2012 09:47:16 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA605DC.5020400@cs.ucla.edu> References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> Message-ID: Hi Niels, Am 06.05.2012 um 07:02 schrieb Paul Eggert: > On 05/05/2012 12:19 PM, Niels M?ller wrote: >> So code which uses the int_fast*_t types and relies on gnulib will get a >> slightly different ABI > > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. Do you see a chance to adjust the nettle header files to avoid the fast-types? The current situation makes gnutls uncompilable on platforms like Solaris. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bruno at clisp.org Sun May 6 12:34:38 2012 From: bruno at clisp.org (Bruno Haible) Date: Sun, 06 May 2012 12:34:38 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <4FA605DC.5020400@cs.ucla.edu> Message-ID: <5405085.L6fiXlP7Mg@linuix> Niels M?ller wrote: > One possibility might be to not define the types at all, unless the > gnulib application explicitly asks for them. Lots of applications want > uint32_t, and I imagine a lot fewer have any need for int_fast*_t. Yes. For this reason, libunistring installs a trimmed-down version of gnulib's stdint.h, that defines only the int{8,16,32}_t types and not all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1] Bruno [1] http://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=lib/stdint.mini.h;hb=HEAD From nmav at gnutls.org Sun May 6 12:49:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 06 May 2012 12:49:07 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <5405085.L6fiXlP7Mg@linuix> References: <4FA605DC.5020400@cs.ucla.edu> <5405085.L6fiXlP7Mg@linuix> Message-ID: <4FA65723.8000209@gnutls.org> On 05/06/2012 12:34 PM, Bruno Haible wrote: > Niels M?ller wrote: >> One possibility might be to not define the types at all, unless the >> gnulib application explicitly asks for them. Lots of applications want >> uint32_t, and I imagine a lot fewer have any need for int_fast*_t. > Yes. For this reason, libunistring installs a trimmed-down version of > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1] Is there a gnulib module that only provides the basic types? regards, Nikos From bruno at clisp.org Sun May 6 16:38:04 2012 From: bruno at clisp.org (Bruno Haible) Date: Sun, 06 May 2012 16:38:04 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA65723.8000209@gnutls.org> References: <5405085.L6fiXlP7Mg@linuix> <4FA65723.8000209@gnutls.org> Message-ID: <3244661.D8EYbvb0ce@linuix> Nikos Mavrogiannopoulos wrote: > > libunistring installs a trimmed-down version of > > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not > > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1] > > Is there a gnulib module that only provides the basic types? It doesn't exist so far. But it is feasible. - On the other hand, it looks like nettle-stdint.h can already be easily trimmed in this way, by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ? Bruno From nisse at lysator.liu.se Sun May 6 16:52:37 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Sun, 06 May 2012 16:52:37 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <3244661.D8EYbvb0ce@linuix> (Bruno Haible's message of "Sun, 06 May 2012 16:38:04 +0200") References: <5405085.L6fiXlP7Mg@linuix> <4FA65723.8000209@gnutls.org> <3244661.D8EYbvb0ce@linuix> Message-ID: Bruno Haible writes: > It doesn't exist so far. But it is feasible. - On the other hand, it > looks like nettle-stdint.h can already be easily trimmed in this way, > by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ? I think that makes sense. I just need someone (Dagobert Michelsen?) who can try it out. Nettle uses the AX_CREATE_STDINT_H macro to generate that file. If it's easy, I'd prefer not to touch that and just add some extra #define in nettle-types.h before it includes nettle-stdint.h. Or if that doesn't work out, it's fine to hack away in the definition in aclocal.m4 to take out the unneded types. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From eggert at cs.ucla.edu Sun May 6 19:14:09 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 06 May 2012 10:14:09 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> Message-ID: <4FA6B161.6050408@cs.ucla.edu> On 05/06/2012 12:13 AM, Niels M?ller wrote: > Paul Eggert writes: > >> > Generally speaking, it's unwise to use >> > the int_fast*_t types in a public header file. > Why (feel free to point to the relevant section of gnulib docs, if it's > explained well there)? Intuitively, it's because the int_fast* types are so fragile: they depend so much on choice of compiler and compiler option. (To some extent the types are even a mistake, as modern compilers optimize so well without them.) That is why gnulib never uses these types in public headers (except for stdint.h where C requires it). Gnulib lib/stdint.in.h says this: /* Note: Other substitutes may define these types differently. It is not recommended to use these types in public header files. */ and it seems like it may be worthwhile to add this to the documentation, so I pushed this: stdint: document issues with int_fast8_t etc. * doc/posix-headers/stdint.texi (stdint.h): Say that other stdint.h substitutes may define these types differently. See . diff --git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi index be19269..aeae7d5 100644 --- a/doc/posix-headers/stdint.texi +++ b/doc/posix-headers/stdint.texi @@ -40,6 +40,8 @@ Portability problems not fixed by Gnulib: @item @code{@{uint,int@}_fast@{8,16,32,64@}_t} may not correspond to the fastest types available on the system. +Other @code{} substitutes may define these types differently, +so public header files should avoid these types. @item Macros are used instead of typedefs. @item From nisse at lysator.liu.se Sun May 6 21:38:47 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Sun, 06 May 2012 21:38:47 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA6B161.6050408@cs.ucla.edu> (Paul Eggert's message of "Sun, 06 May 2012 10:14:09 -0700") References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> <4FA6B161.6050408@cs.ucla.edu> Message-ID: Paul Eggert writes: > Intuitively, it's because the int_fast* types are so fragile: they > depend so much on choice of compiler and compiler option. Short version: I think gnulib should either make an effort to define int_fast*_t in the common way on each system (always doing the same as gcc would be very close to the Right Thing), or by default generate a stdint.h without these types and define the int_fast*_t types only when explicitly asked to. Longer version (sorry I fail to be more concise): I think I misread "public headers" in your previous mail, I thought you meant system header files, rather than public header files provided by portable non-system libraries. Sorry for the confusion. I agree one can expect these types to be a fragile and compiler dependent whenever they're left undefined by system headers and ABI spec, which will be the usual assumption for portable code. But in the particular case of SunOS, the types are defined by system headers in release 5.10 (and presumably nailed down by the ABI spec), but missing in release 5.9. Do you see any good reason for gnulib to not define the types in the same way as on 5.10, if building on 5.9? To me, that really looks like the Right Thing to do, and it also looks like the kind of job gnulib is supposed to do. Defining them in a way which differs from SunOS-5.10 definitely seems broken. In the case of gnutls and nettle, one gets compilation errors when another packed defines the same types, and does it using a configure hack which *is* compatible with SunOS-5.10. Of course, that fix doesn't magically make int_fast*_t universally non-fragile, but it definitely improves compatibility for the system in question. As for nettle, I think it's best to not define these types, which aren't used. On Solaris, it happens that AX_CREATE_STDINT_H defines them more correctly (in my view) than gnulib, but it may well cause problems on other system, so it seems more robust to not try to define them at all. But please also consider the hypothetical situation that nettle *did* use those types, even if only internally. Then I couldn't simply omit the definitions. To not cause problems for gnulib users I'd be forced to either change my definitions to prefer compatibility with gnulib over compatibility with SunOS-5.10, which seems really backwards, or introduce additional complexity in nettle-stdint.h to omit the definitions when my public headers need uint32_t. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From eggert at cs.ucla.edu Sun May 6 23:31:13 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Sun, 06 May 2012 14:31:13 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> <4FA6B161.6050408@cs.ucla.edu> Message-ID: <4FA6EDA1.9060902@cs.ucla.edu> On 05/06/2012 12:38 PM, Niels M?ller wrote: > But in the particular case of SunOS, the types are defined by system > headers in release 5.10 (and presumably nailed down by the ABI spec), Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not mention int_fast*_t, except in stdint.h where C requires their definition. Presumably this is for the same reason that Gnulib avoids these types. Arguably these types are not part of the SunOS 5.10 ABI, since nothing in the SunOS library binary interface use them. > Do you see any good reason for gnulib to not > define the types in the same way as on 5.10, if building on 5.9? The main reason is to keep gnulib simple and maintainable. I'd rather not have to hand-maintain details about an operating system that hasn't shipped since 2009. How does the nettle stuff work? Does it #define int_fast8_t etc in config.h? If so, there's a simple workaround in gnulib: don't futz with int_fast8_t if it's already #defined. That would be both simple and maintainable. That is, in lib/stdint.in.h, we could replace this: #undef int_fast8_t #define int_fast8_t gl_int_fast8_t with this: #ifndef int_fast8_t # define int_fast8_t gl_int_fast8_t #endif From nmav at gnutls.org Mon May 7 18:15:54 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 May 2012 18:15:54 +0200 Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users In-Reply-To: References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net> <4FA75CD9.6090904@gnutls.org> Message-ID: <4FA7F53A.2090109@gnutls.org> On 05/07/2012 12:35 PM, Richard Moore wrote: >> Are there ways to identify the trust purpose of those certificates? >> Is there any intention to standardize something like that, so we don't >> end up with our own trust? > > All the certs are trusted for all purposes in this scheme (subject to > the keyusage flags they contain). The problem is that there is no particular scheme and the keyusage flags are set by the CA, not by the one who trusts the certificate. Because verisign has a certificate that says it is appropriate for signing e-mail, it doesn't mean that I want to trust it. regards, Nikos From nisse at lysator.liu.se Mon May 7 19:13:02 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 07 May 2012 19:13:02 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA6EDA1.9060902@cs.ucla.edu> (Paul Eggert's message of "Sun, 06 May 2012 14:31:13 -0700") References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> <4FA6B161.6050408@cs.ucla.edu> <4FA6EDA1.9060902@cs.ucla.edu> Message-ID: Paul Eggert writes: > Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not > mention int_fast*_t, except in stdint.h where C requires their definition. I'd consider that definition to be authoritative... > Presumably this is for the same reason that Gnulib avoids these types. > Arguably these types are not part of the SunOS 5.10 ABI, since nothing > in the SunOS library binary interface use them. C is still the system programming language, and int_fast*_t are part of the language. But maybe we're splitting hairs now. > The main reason is to keep gnulib simple and maintainable. > I'd rather not have to hand-maintain details about an > operating system that hasn't shipped since 2009. I thought the point of gnulib was to do those annoying things to keep the maintanance in one place. But I guess I'll have to leave to the judgment of the gnulib maintainers which systems are too old and obsolete to care about. > How does the nettle stuff work? Does it #define int_fast8_t etc > in config.h? It is defined in a generated file nettle-stdint.h. And the names of the types are all typedefs, no #defines. With AX_CREATE_STDINT_H, it's a file generated independently of config.h. The file starts with a section with a bunch of #defines set up by configure, and then the rest of the file uses various tests on these to decide what file to include and which types to define. Where the common case is to just include the system's . The file is then installed with the other nettle header files. > If so, there's a simple workaround in gnulib: > don't futz with int_fast8_t if it's already #defined. If one could get that to work, it might solve the problem for the case that the types are defined but not used. But if it implies that size of those types will depend on #include order, it seems very brittle to me. I think it would be better to let the gnulib application say explicitly whether or not it needs those types, and not define them at all in the common case that they aren't needed. I.e., #ifdef GL_WANT_INTX_FAST_T # define int_fast8_t gl_int_fast8_t #endif Not sure where one would define GL_WANT_INTX_FAST_T, if desired, though. Should be specified in some way in configure.ac, but it can't be put in config.h if the stdint.h types are needed for installed header files. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From rich at kde.org Mon May 7 21:30:10 2012 From: rich at kde.org (Richard Moore) Date: Mon, 7 May 2012 20:30:10 +0100 Subject: Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users In-Reply-To: <4FA7F53A.2090109@gnutls.org> References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net> <4FA75CD9.6090904@gnutls.org> <4FA7F53A.2090109@gnutls.org> Message-ID: On 7 May 2012 17:15, Nikos Mavrogiannopoulos wrote: > On 05/07/2012 12:35 PM, Richard Moore wrote: > > >>> Are there ways to identify the trust purpose of those certificates? >>> Is there any intention to standardize something like that, so we don't >>> end up with our own trust? >> >> All the certs are trusted for all purposes in this scheme (subject to >> the keyusage flags they contain). > > > The problem is that there is no particular scheme and the keyusage > flags are set by the CA, not by the one who trusts the certificate. > Because verisign has a certificate that says it is appropriate for > signing e-mail, it doesn't mean that I want to trust it. Yes, I understand what you're asking for and that's not something that's supported. NSS has a more complete facility for this sort of thing using a Berkeley db of certs, but iirc that's only used by firefox and isn't actually supported by tools like thunderbird. I think this is basically an area where there's no real support at all under linux (and to be honest isn't something most users need or have the ability to configure). Cheers Rich. From eggert at cs.ucla.edu Mon May 7 22:10:19 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 07 May 2012 13:10:19 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <6F92CE78-7FBD-4792-A97E-D457886874A2@opencsw.org> <1335534378.6649.2.camel@latte>

<4FA605DC.5020400@cs.ucla.edu> <4FA6B161.6050408@cs.ucla.edu> <4FA6EDA1.9060902@cs.ucla.edu> Message-ID: <4FA82C2B.80905@cs.ucla.edu> On 05/07/2012 10:13 AM, Niels M?ller wrote: > I thought the point of gnulib was to do those annoying things to keep > the maintanance in one place. True. Very true. OK, how about the following patch to gnulib's lib/stdint.in.h? Does it fix the problem? And if not, could you please explain what goes wrong? I'm still not quite understanding the pattern of includes that causes the compilation failure. Thanks. --- ChangeLog | 15 +++++++++++++++ lib/stdint.in.h | 49 +++++++++++++++++++++++++++++++++---------------- 2 files changed, 48 insertions(+), 16 deletions(-) diff --git a/ChangeLog b/ChangeLog index a05f41d..f285344 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2012-05-07 Paul Eggert + + stdint: be more consistent with glibc, SunOS libc + * lib/stdint.in.h (gl_int_fast8_t, gl_uint_fast8_t) + (gl_int_fast16_t, gl_uint_fast16_t) + (gl_int_fast32_t, gl_uint_fast32_t) + (INT_FAST8_MIN, INT_FAST8_MAX, UINT_FAST8_MAX) + (INT_FAST16_MIN, INT_FAST16_MAX, UINT_FAST16_MAX) + (INT_FAST32_MIN, INT_FAST32_MAX, UINT_FAST32_MAX): + Be consistent with glibc by default, and with SunOS 5.10 and later + if __sun is defined. This lessens the likelihood of clashes if + code compiled for older hosts is combined with code compiled for + newer ones. Problem reported by Niels M?ller in + . + 2012-05-06 Paul Eggert stat-size: comment fix diff --git a/lib/stdint.in.h b/lib/stdint.in.h index 54ec7e0..9a82ae7 100644 --- a/lib/stdint.in.h +++ b/lib/stdint.in.h @@ -90,7 +90,8 @@ # include #endif -/* Get LONG_MIN, LONG_MAX, ULONG_MAX. */ +/* Get SCHAR_MIN, SCHAR_MAX, UCHAR_MAX, INT_MIN, INT_MAX, + LONG_MIN, LONG_MAX, ULONG_MAX. */ #include #if @HAVE_INTTYPES_H@ @@ -246,8 +247,9 @@ typedef unsigned long long int gl_uint64_t; /* Here we assume a standard architecture where the hardware integer types have 8, 16, 32, optionally 64 bits. Therefore the fastN_t types - are taken from the same list of types. Assume that 'long int' - is fast enough for all narrower integers. */ + are taken from the same list of types. The following code normally + uses types consistent with glibc, as that lessens the chance of + incompatibility with older GNU hosts. */ #undef int_fast8_t #undef uint_fast8_t @@ -257,12 +259,21 @@ typedef unsigned long long int gl_uint64_t; #undef uint_fast32_t #undef int_fast64_t #undef uint_fast64_t -typedef long int gl_int_fast8_t; -typedef unsigned long int gl_uint_fast8_t; -typedef long int gl_int_fast16_t; -typedef unsigned long int gl_uint_fast16_t; +typedef signed char gl_int_fast8_t; +typedef unsigned char gl_uint_fast8_t; + +#ifdef __sun +/* Define types compatible with SunOS 5.10, so that code compiled under + earlier SunOS versions works with code compiled under SunOS 5.10. */ +typedef int gl_int_fast32_t; +typedef unsigned int gl_uint_fast32_t; +#else typedef long int gl_int_fast32_t; typedef unsigned long int gl_uint_fast32_t; +#endif +typedef gl_int_fast32_t gl_int_fast16_t; +typedef gl_uint_fast32_t gl_uint_fast16_t; + #define int_fast8_t gl_int_fast8_t #define uint_fast8_t gl_uint_fast8_t #define int_fast16_t gl_int_fast16_t @@ -418,23 +429,29 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t) #undef INT_FAST8_MIN #undef INT_FAST8_MAX #undef UINT_FAST8_MAX -#define INT_FAST8_MIN LONG_MIN -#define INT_FAST8_MAX LONG_MAX -#define UINT_FAST8_MAX ULONG_MAX +#define INT_FAST8_MIN SCHAR_MIN +#define INT_FAST8_MAX SCHAR_MAX +#define UINT_FAST8_MAX UCHAR_MAX #undef INT_FAST16_MIN #undef INT_FAST16_MAX #undef UINT_FAST16_MAX -#define INT_FAST16_MIN LONG_MIN -#define INT_FAST16_MAX LONG_MAX -#define UINT_FAST16_MAX ULONG_MAX +#define INT_FAST16_MIN INT_FAST32_MIN +#define INT_FAST16_MAX INT_FAST32_MAX +#define UINT_FAST16_MAX UINT_FAST32_MAX #undef INT_FAST32_MIN #undef INT_FAST32_MAX #undef UINT_FAST32_MAX -#define INT_FAST32_MIN LONG_MIN -#define INT_FAST32_MAX LONG_MAX -#define UINT_FAST32_MAX ULONG_MAX +#ifdef __sun +# define INT_FAST32_MIN INT_MIN +# define INT_FAST32_MAX INT_MAX +# define UINT_FAST32_MAX UINT_MAX +#else +# define INT_FAST32_MIN LONG_MIN +# define INT_FAST32_MAX LONG_MAX +# define UINT_FAST32_MAX ULONG_MAX +#endif #undef INT_FAST64_MIN #undef INT_FAST64_MAX -- 1.7.6.5 From bruno at clisp.org Mon May 7 22:43:49 2012 From: bruno at clisp.org (Bruno Haible) Date: Mon, 07 May 2012 22:43:49 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA82C2B.80905@cs.ucla.edu> References: <4FA82C2B.80905@cs.ucla.edu> Message-ID: <1928362.AFeediWS73@linuix> Paul Eggert wrote: > + stdint: be more consistent with glibc, SunOS libc > + * lib/stdint.in.h (gl_int_fast8_t, gl_uint_fast8_t) > + (gl_int_fast16_t, gl_uint_fast16_t) > + (gl_int_fast32_t, gl_uint_fast32_t) > + (INT_FAST8_MIN, INT_FAST8_MAX, UINT_FAST8_MAX) > + (INT_FAST16_MIN, INT_FAST16_MAX, UINT_FAST16_MAX) > + (INT_FAST32_MIN, INT_FAST32_MAX, UINT_FAST32_MAX): > + Be consistent with glibc by default, and with SunOS 5.10 and later > + if __sun is defined. Looks good to me. The sizes of the gnulib replacements of int_fast*_t will come out like this also with gnulib: glibc 32-bit: 1 4 4 glibc 64-bit: 1 8 8 solaris10 32-bit: 1 4 4 solaris10 64-bit: 1 4 4 Bruno From eggert at cs.ucla.edu Tue May 8 01:17:31 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Mon, 07 May 2012 16:17:31 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <1928362.AFeediWS73@linuix> References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> Message-ID: <4FA8580B.4000301@cs.ucla.edu> On 05/07/2012 01:43 PM, Bruno Haible wrote: > Looks good to me. Thanks. This seems to be a win regardless of whether it fixes the nettle problems, so I've pushed it into gnulib master. We can look into further fixes later as needed. From nitin.a.kamble at intel.com Mon May 7 21:20:42 2012 From: nitin.a.kamble at intel.com (Nitin A Kamble) Date: Mon, 7 May 2012 12:20:42 -0700 Subject: [patch] fix gnutls build with automake 1.12 Message-ID: <20120507192042.GA22394@nbuild0.sc.intel.com> Attached patch fixes a build issuw of gnutls with automake 1.12 -- Nitin A Kamble www.yoctoproject.org -------------- next part -------------- Upstream-Status: Pending This patch fixes following kind of issue with automake 1.12 | automake: warnings are treated as errors | /srv/home/nitin/builds/build-gcc47/tmp/sysroots/x86_64-linux/usr/share/automake-1.12/am/ltlibrary.am: warning: 'libgnutls.la': linking libtool libraries using a non-POSIX | /srv/home/nitin/builds/build-gcc47/tmp/sysroots/x86_64-linux/usr/share/automake-1.12/am/ltlibrary.am: archiver requires 'AM_PROG_AR' in 'configure.ac' Signed-Off-By: Nitin A Kamble 2012/05/03 Index: gnutls-2.12.18/configure.ac =================================================================== --- gnutls-2.12.18.orig/configure.ac +++ gnutls-2.12.18/configure.ac @@ -36,6 +36,9 @@ AC_MSG_RESULT([*** dnl Checks for programs. AC_PROG_CC +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it +m4_pattern_allow([AM_PROG_AR]) +AM_PROG_AR AC_PROG_LN_S GTK_DOC_CHECK(1.1) AC_PATH_PROG([GAA], [gaa]) Index: gnutls-2.12.18/lib/configure.ac =================================================================== --- gnutls-2.12.18.orig/lib/configure.ac +++ gnutls-2.12.18/lib/configure.ac @@ -31,6 +31,9 @@ m4_ifdef([AM_SILENT_RULES], [AM_SILENT_R AM_CONFIG_HEADER(config.h) AC_PROG_CC +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it +m4_pattern_allow([AM_PROG_AR]) +AM_PROG_AR lgl_EARLY AC_LIBTOOL_WIN32_DLL Index: gnutls-2.12.18/libextra/configure.ac =================================================================== --- gnutls-2.12.18.orig/libextra/configure.ac +++ gnutls-2.12.18/libextra/configure.ac @@ -31,6 +31,9 @@ m4_ifdef([AM_SILENT_RULES], [AM_SILENT_R AM_CONFIG_HEADER(config.h) AC_PROG_CC +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it +m4_pattern_allow([AM_PROG_AR]) +AM_PROG_AR xgl_EARLY AC_LIBTOOL_WIN32_DLL From nisse at lysator.liu.se Tue May 8 10:55:51 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 08 May 2012 10:55:51 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA8580B.4000301@cs.ucla.edu> (Paul Eggert's message of "Mon, 07 May 2012 16:17:31 -0700") References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu> Message-ID: Paul Eggert writes: > Thanks. This seems to be a win regardless of whether it > fixes the nettle problems, Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., apply Paul's patch to gnutls/gnulib, then *unapply* the nettle workaround I comitted yesterday, and see if you still get compilation errors related to nettle-stdint.h. I'm not sure how picky the compiler is about multiple but equivalent typedefs of the same name. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From INVALID.NOREPLY at gnu.org Tue May 8 14:43:26 2012 From: INVALID.NOREPLY at gnu.org (Toby Inkster) Date: Tue, 08 May 2012 12:43:26 +0000 Subject: [sr #108051] certtool Message-ID: <20120508-124326.sv73119.25664@savannah.gnu.org> URL: Summary: certtool Project: GnuTLS Submitted by: tobyink Submitted on: Tue 08 May 2012 12:43:26 GMT Category: Included programs Priority: 5 - Normal Severity: 1 - Wish Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: I'm trying to port a certificate generation script from OpenSSL to GnuTLS. It would be useful if certtool supported (via the certtool.cfg file) more types of subjectAltName. Currently it supports e-mail addresses, domain names and IP addresses. I need support for URIs, and it would also be nice to have support for OIDs. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From eggert at cs.ucla.edu Tue May 8 17:05:44 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Tue, 08 May 2012 08:05:44 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu> Message-ID: <4FA93648.1040202@cs.ucla.edu> On 05/08/2012 01:55 AM, Niels M?ller wrote: > I'm not sure how picky the compiler is about multiple but equivalent > typedefs of the same name. Such usage violates the C standard: even if one compiler is not picky about it, your're likely to run into another that does. So a better solution is needed. Earlier you asked for a special hook to have gnulib not define int_fast8_t etc. I'd rather have an approach where the code simply does "#include " and assumes that int_fast8_t works. I don't understand the overall situation, though, so I don't know what exactly to suggest. From nisse at lysator.liu.se Tue May 8 17:56:49 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 08 May 2012 17:56:49 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA93648.1040202@cs.ucla.edu> (Paul Eggert's message of "Tue, 08 May 2012 08:05:44 -0700") References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu> <4FA93648.1040202@cs.ucla.edu> Message-ID: Paul Eggert writes: > Such usage violates the C standard: even if one compiler > is not picky about it, your're likely to run into another that > does. So a better solution is needed. I've committed a workaround to nettle-types.h. It now does /* Pretend these types always exists. Nettle doesn't use them. */ #define _STDINT_HAVE_INT_FAST32_T 1 #include "nettle-stdint.h" which overrides the result of the configure checks used in the generated nettle-stdint.h. Maybe not the prettiest way to do it, but apparantly it solves the problem, independently of your fixes to gnulib. (But I'd still like to know if your fixes also solves this problem, independently of that Nettle workaround). > I'd rather have an approach where the code simply does "#include > " and assumes that int_fast8_t works. I don't understand the > overall situation, though, so I don't know what exactly to suggest. I think when you build gnutls on a system lacking stdint.h, a typical compilation unit will contain /* From gnulib's stdint.h */ typedef unsigned int gl_uint32_t; #define uint32_t gl_uint32_t ... /* From nettle/nettle-stdint.h */ typedef unsigned int uint32_t; where the final line is macro-expanded to typedef unsigned int gl_uint32_t; >From what I've seen, this has been no problem. And I hope nettle-stdint.h and gnulib/stdint.h always do these types in the same way. There is some freedom in how to define these types; on a system where for example int and long are the same size, typedef unsigned long uint32_t; typedef unsigned int uint32_t; would be a two distinct but correct definitions, and I imagine the compiler would complain. And to consider the problematic int_fast*_t types, until a day or two ago, you got /* From gnulib's stdint.h */ typedef long gl_int_fast8_t; #define int_fast8_t gl_int_fast8_t ... /* From nettle/nettle-stdint.h */ typedef char int_fast8_t; which no reasonable compiler will accept. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From home_pw at msn.com Tue May 8 18:10:03 2012 From: home_pw at msn.com (Peter Williams) Date: Tue, 8 May 2012 09:10:03 -0700 Subject: [sr #108051] certtool In-Reply-To: <20120508-124326.sv73119.25664@savannah.gnu.org> References: <20120508-124326.sv73119.25664@savannah.gnu.org> Message-ID: Out of interest, why do you want the oid name form alternate? It's just that the oid name form has such a very rare place in today's world, and only one group I know of uses it (for its actually quite special role in the modern Internet). Sent from my iPhone On May 8, 2012, at 5:43 AM, "Toby Inkster" wrote: > URL: > > > Summary: certtool > Project: GnuTLS > Submitted by: tobyink > Submitted on: Tue 08 May 2012 12:43:26 GMT > Category: Included programs > Priority: 5 - Normal > Severity: 1 - Wish > Status: None > Privacy: Public > Assigned to: None > Originator Email: > Open/Closed: Open > Discussion Lock: Any > Operating System: None > > _______________________________________________________ > > Details: > > I'm trying to port a certificate generation script from OpenSSL to GnuTLS. It > would be useful if certtool supported (via the certtool.cfg file) more types > of subjectAltName. > > Currently it supports e-mail addresses, domain names and IP addresses. I need > support for URIs, and it would also be nice to have support for OIDs. > > > > > _______________________________________________________ > > Reply to this item at: > > > > _______________________________________________ > Message sent via/by Savannah > http://savannah.gnu.org/ > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel From dam at opencsw.org Tue May 8 21:35:43 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 8 May 2012 21:35:43 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu> Message-ID: Hi Niels, Am 08.05.2012 um 10:55 schrieb Niels M?ller: > Paul Eggert writes: >> Thanks. This seems to be a win regardless of whether it >> fixes the nettle problems, > > Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., > apply Paul's patch to gnutls/gnulib, then *unapply* the nettle > workaround I comitted yesterday, and see if you still get compilation > errors related to nettle-stdint.h. > > I'm not sure how picky the compiler is about multiple but equivalent > typedefs of the same name. If Paul or you could provide a bootstrapped tarball I'll be happy to test it as I am not really familiar with gnulib bootstrapping. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From nisse at lysator.liu.se Tue May 8 22:05:43 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 08 May 2012 22:05:43 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: (Dagobert Michelsen's message of "Tue, 8 May 2012 21:35:43 +0200") References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu>

Message-ID: Dagobert Michelsen writes: > If Paul or you could provide a bootstrapped tarball I'll be happy to test it as > I am not really familiar with gnulib bootstrapping. I'm also not very familiar with gnulib. But I think it should work fine to just get the gnutls release and apply Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the configure script. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From eggert at cs.ucla.edu Tue May 8 23:17:06 2012 From: eggert at cs.ucla.edu (Paul Eggert) Date: Tue, 08 May 2012 14:17:06 -0700 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu>

Message-ID: <4FA98D52.6030304@cs.ucla.edu> On 05/08/2012 01:05 PM, Niels M?ller wrote: > I think it should work fine to just get the gnutls release and apply > Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the > configure script. Yes, that's the idea. Thanks. From mail at tobyinkster.co.uk Tue May 8 23:43:30 2012 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Tue, 8 May 2012 22:43:30 +0100 Subject: [sr #108051] certtool In-Reply-To: References: <20120508-124326.sv73119.25664@savannah.gnu.org> Message-ID: <20120508224330.57923786@miranda.g5n.co.uk> On Tue, 8 May 2012 09:10:03 -0700 Peter Williams wrote: > Out of interest, why do you want the oid name form alternate? It was mostly just an afterthought. I have an OID, and it would be nice to stuff it in there. The main part of the wish is for URIs though. -- Toby A Inkster From nmav at gnutls.org Wed May 9 08:12:21 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 May 2012 08:12:21 +0200 Subject: [sr #108051] certtool In-Reply-To: <20120508224330.57923786@miranda.g5n.co.uk> References: <20120508-124326.sv73119.25664@savannah.gnu.org> <20120508224330.57923786@miranda.g5n.co.uk> Message-ID: <4FAA0AC5.1030009@gnutls.org> On 05/08/2012 11:43 PM, Toby Inkster wrote: >> Out of interest, why do you want the oid name form alternate? > It was mostly just an afterthought. I have an OID, and it would be nice > to stuff it in there. > The main part of the wish is for URIs though. Are these fields being used by anyone? I understand they might be good to have them for completeness, but on the practical side does it change anything? rfc2818 that defines a way to verify hostnames for https isn't mentioning those two fields at all. If there are no known practical applications, I'll not spend any resources on these, but of course I'll accept any patch that adds them. regards, Nikos From nmav at gnutls.org Wed May 9 08:22:12 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 May 2012 08:22:12 +0200 Subject: [patch] fix gnutls build with automake 1.12 In-Reply-To: <20120507192042.GA22394@nbuild0.sc.intel.com> References: <20120507192042.GA22394@nbuild0.sc.intel.com> Message-ID: <4FAA0D14.1050407@gnutls.org> On 05/07/2012 09:20 PM, Nitin A Kamble wrote: > Attached patch fixes a build issuw of gnutls with automake 1.12 Thank you. Applied. regards, Nikos From nmav at gnutls.org Wed May 9 16:32:36 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 09 May 2012 16:32:36 +0200 Subject: [PATCH v2 gnutls] introduce gnutls_certificate_set_x509_system_trust In-Reply-To: <1336487305-21544-1-git-send-email-ludwig.nussel@suse.de> References: <1336487305-21544-1-git-send-email-ludwig.nussel@suse.de> Message-ID: <4FAA8004.7070009@gnutls.org> On 05/08/2012 04:28 PM, Ludwig Nussel wrote: > gnutls_certificate_set_x509_system_trust() imports the trusted root CA's > from a compile time defined location. That way applications don't > need to know. Applied, thank you. From mail at tobyinkster.co.uk Wed May 9 15:56:24 2012 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Wed, 9 May 2012 14:56:24 +0100 Subject: [sr #108051] certtool In-Reply-To: <4FAA0AC5.1030009@gnutls.org> References: <20120508-124326.sv73119.25664@savannah.gnu.org> <20120508224330.57923786@miranda.g5n.co.uk> <4FAA0AC5.1030009@gnutls.org> Message-ID: <7661ef8f73e0ddee9046833153f17f24.squirrel@goddamn.co.uk> > Are these fields being used by anyone? Yes, URIs are used by WebID . Lack of support for URI subjectAltNames in certtool is why I'm currently reliant on OpenSSL. -Toby From nmav at gnutls.org Fri May 11 13:55:50 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 May 2012 13:55:50 +0200 Subject: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users In-Reply-To: References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net> <4FA75CD9.6090904@gnutls.org> Message-ID: On Mon, May 7, 2012 at 1:06 PM, Sam Varshavchik wrote: > Debian installs /etc/ssl/certs/ca-certificates.crt. Fedora, and its > derivations, (Red Hat, Cent-OS) have /etc/pki/tls/cert.pem installed. > FreeBSD has /usr/local/share/certs/ca-root-nss.crt > The standard practice on Fedora is to have applications configured or > patched to use its default /etc/pki/tls/cert.pem certificate bundle. Thanks to Ludwig the next releases of gnutls would include a new function, gnutls_certificate_set_x509_system_trust(), which will use the system's trusted certificates, which are determined at configure time. Are there any comments or suggestions on this functionality? regards, Nikos From branko at majic.rs Fri May 11 18:50:14 2012 From: branko at majic.rs (=?UTF-8?B?0JHRgNCw0L3QutC+INCc0LDRmNC40Zs=?=) Date: Fri, 11 May 2012 18:50:14 +0200 Subject: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users In-Reply-To: References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net> <4FA75CD9.6090904@gnutls.org>

Message-ID: <20120511185014.569fb0e2@majic.rs> A small curiosity - this function only supports working with single large file? No support for something like hashed directory (OpenSSL-style)? On Fri, 11 May 2012 13:55:50 +0200 Nikos Mavrogiannopoulos wrote: > On Mon, May 7, 2012 at 1:06 PM, Sam Varshavchik > wrote: > > > Debian installs /etc/ssl/certs/ca-certificates.crt. Fedora, and its > > derivations, (Red Hat, Cent-OS) have /etc/pki/tls/cert.pem > > installed. FreeBSD has /usr/local/share/certs/ca-root-nss.crt > > The standard practice on Fedora is to have applications configured > > or patched to use its default /etc/pki/tls/cert.pem certificate > > bundle. > > Thanks to Ludwig the next releases of gnutls would include a new > function, gnutls_certificate_set_x509_system_trust(), which will use > the system's trusted certificates, which are determined at configure > time. Are there any comments or suggestions on this functionality? > > regards, > Nikos > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From nmav at gnutls.org Fri May 11 21:40:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 May 2012 21:40:11 +0200 Subject: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users In-Reply-To: <20120511185014.569fb0e2@majic.rs> References: <4FA3B6DD.1070503@suse.de> <4FA717D9.2000104@fifthhorseman.net> <4FA75CD9.6090904@gnutls.org>

<20120511185014.569fb0e2@majic.rs> Message-ID: <4FAD6B1B.9060809@gnutls.org> On 05/11/2012 06:50 PM, ?????? ????? wrote: > A small curiosity - this function only supports working with single > large file? No support for something like hashed directory > (OpenSSL-style)? No this patch doesn't include that functionality. regards, Nikos From nmav at gnutls.org Fri May 11 22:23:45 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 May 2012 22:23:45 +0200 Subject: [sr #108051] certtool In-Reply-To: <7661ef8f73e0ddee9046833153f17f24.squirrel@goddamn.co.uk> References: <20120508-124326.sv73119.25664@savannah.gnu.org> <20120508224330.57923786@miranda.g5n.co.uk> <4FAA0AC5.1030009@gnutls.org> <7661ef8f73e0ddee9046833153f17f24.squirrel@goddamn.co.uk> Message-ID: <4FAD7551.20906@gnutls.org> On 05/09/2012 03:56 PM, Toby Inkster wrote: >> Are these fields being used by anyone? > > Yes, URIs are used by WebID > . Lack of support for URI > subjectAltNames in certtool is why I'm currently reliant on OpenSSL. I've added support for it in certtool. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c4951af8b85be1963f8dc67f97fb82df55e0fced regards, Nikos From nmav at gnutls.org Thu May 17 14:00:36 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 May 2012 14:00:36 +0200 Subject: windows and gnutls_certificate_set_x509_system_trust Message-ID: <4FB4E864.6010602@gnutls.org> Hello, Is there any of the windows users of gnutls interested into enhancing gnutls_certificate_set_x509_system_trust to be supported in windows? Currently it returns an error code on unsupported systems, but according to [0] there may be a way to work there as well. regards, Nikos [0]. http://marc.info/?l=openssl-users&m=119583966725315 From dam at opencsw.org Tue May 22 22:53:50 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 22 May 2012 22:53:50 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <4FA98D52.6030304@cs.ucla.edu> References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu>

<4FA98D52.6030304@cs.ucla.edu> Message-ID: <7D268C49-8FEF-4CA7-879C-C8797A455A7E@opencsw.org> Hi, Am 08.05.2012 um 23:17 schrieb Paul Eggert: > On 05/08/2012 01:05 PM, Niels M?ller wrote: >> I think it should work fine to just get the gnutls release and apply >> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the >> configure script. > > Yes, that's the idea. Thanks. Sorry for the delay, I got distracted. I just tested the latest stdint.in.h from gnulib master and gnutls 3.0.19 passes this stage now. However, I didn't change anything on the nettle includes and now get lots of warnings. Probably the gl_* definitions should not belong to the installed nettle headers? CC pkcs12_bag.lo "/opt/csw/include/nettle/nettle-stdint.h", line 237: warning: typedef redeclared: gl_int_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: typedef redeclared: gl_int_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: typedef redeclared: gl_int_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t "/opt/csw/include/nettle/nettle-stdint.h", line 244: warning: typedef redeclared: gl_uint_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 245: warning: typedef redeclared: gl_uint_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 246: warning: typedef redeclared: gl_uint_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From nisse at lysator.liu.se Wed May 23 10:37:05 2012 From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 23 May 2012 10:37:05 +0200 Subject: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc In-Reply-To: <7D268C49-8FEF-4CA7-879C-C8797A455A7E@opencsw.org> (Dagobert Michelsen's message of "Tue, 22 May 2012 22:53:50 +0200") References: <4FA82C2B.80905@cs.ucla.edu> <1928362.AFeediWS73@linuix> <4FA8580B.4000301@cs.ucla.edu>

<4FA98D52.6030304@cs.ucla.edu> <7D268C49-8FEF-4CA7-879C-C8797A455A7E@opencsw.org> Message-ID: Dagobert Michelsen writes: > Sorry for the delay, I got distracted. I just tested the latest stdint.in.h from gnulib > master and gnutls 3.0.19 passes this stage now. Thanks. > However, I didn't change anything on the nettle includes and now get > lots of warnings. Are these warnings harmless? If so, I think this is good enough. > Probably the gl_* definitions should not belong to the installed > nettle headers? They don't, they're defined in gnulib, and appear in the nettle-stdint.h warnings because of gnulib's preprocessor macros. In gnutls/gl/stdint.h: typedef signed char gl_int_fast8_t; ... #define int_fast8_t gl_int_fast8_t; In nettle-stdint.h (included later in the compilation unit): typedef int8_t int_fast8_t; > CC pkcs12_bag.lo > "/opt/csw/include/nettle/nettle-stdint.h", line 237: warning: typedef redeclared: gl_int_fast8_t > "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: typedef redeclared: gl_int_fast16_t > "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: typedef redeclared: gl_int_fast32_t > "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t > "/opt/csw/include/nettle/nettle-stdint.h", line 244: warning: typedef redeclared: gl_uint_fast8_t > "/opt/csw/include/nettle/nettle-stdint.h", line 245: warning: typedef redeclared: gl_uint_fast16_t > "/opt/csw/include/nettle/nettle-stdint.h", line 246: warning: typedef redeclared: gl_uint_fast32_t > "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t I don't understand why you get "uint64_t" rather than "gl_uint64_t", it seems gnulib handles this type (and int64_t) differently from the rest. But if it works now, despite these warnings, I think we can consider this problem solved. Do you agree? (And then I also have the fix in nettle to avoid defining the *int_fast*_t types at all, which you have tested previously and which also solved the problem, right?) Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From INVALID.NOREPLY at gnu.org Sat May 26 21:48:48 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sat, 26 May 2012 19:48:48 +0000 Subject: [sr #108064] MAX_ENTRIES in src/certtool-cfg.c is too small Message-ID: <20120526-194847.sv0.68553@savannah.gnu.org> URL: Summary: MAX_ENTRIES in src/certtool-cfg.c is too small Project: GnuTLS Submitted by: None Submitted on: Sat 26 May 2012 07:48:47 PM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: animus at wayround.org Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Can be MAX_ENTRIES in src/certtool-cfg.c increased, say, up to 100? Current number of 16 is to small for certs with many `dns_name' parameters. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun May 27 11:16:16 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 27 May 2012 09:16:16 +0000 Subject: [sr #108064] MAX_ENTRIES in src/certtool-cfg.c is too small In-Reply-To: <20120526-194847.sv0.68553@savannah.gnu.org> References: <20120526-194847.sv0.68553@savannah.gnu.org> Message-ID: <20120527-121616.sv707.18418@savannah.gnu.org> Update of sr #108064 (project gnutls): Status: None => Done Assigned to: None => nmav Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: I've increased it to 128. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Sun May 27 11:54:16 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 27 May 2012 11:54:16 +0200 Subject: certtool --generate-dh-params: Size of generator in 2.12.19 and 3.0.19 Message-ID: <20120527095415.GB2626@downhill.g.la> Hello, certtool --generate-dh-params --bits 2236 seems to generate different things in GnuTLS 2.12.19 and 3.0.19. The resulting files are of different size. certtool --dh-info show this: ------------------ ametzler at argenau:/tmp/dh$ for i in * ; do echo $i ;certtool --dh-info < $i | grep -E 'Generator |Prime ' ;echo ; done 2.12.19-try1 Generator (8 bits): 05 Prime (2240 bits): 2.12.19-try2 Generator (8 bits): 05 Prime (2240 bits): 3.0.19-try1 Generator (2248 bits): 01:01:e8:5e:f1:b9:ad:0f:5a:eb:61:76 Prime (2248 bits): 3.0.19-try2 Generator (2240 bits): 0f:bf:05:ea:18:02:e5:97:8e:81:17:c5 Prime (2240 bits): ------------------ + 3.0.19 Uses a large value for Generator + In 3.0.19 the size of "Prime" is not constant. ("openssl dhparam" produces results similar to 2.12.19.) Do DH paramater files generated with OpenSSL/GnuTLS-2.12.19 work fine with GnuTLS-3.0.19, or the other way round do DH paramater files generated with GnuTLS-3.0.19 work fine with OpenSSL/GnuTLS-2.12.19? 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 ametzler at downhill.at.eu.org Sun May 27 12:12:26 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 27 May 2012 12:12:26 +0200 Subject: certtool --generate-dh-params: Size of generator in 2.12.19 and 3.0.19 In-Reply-To: <20120527095415.GB2626@downhill.g.la> References: <20120527095415.GB2626@downhill.g.la> Message-ID: <20120527101226.GC2626@downhill.g.la> On 2012-05-27 Andreas Metzler wrote: [...] > ------------------ > + 3.0.19 Uses a large value for Generator > + In 3.0.19 the size of "Prime" is not constant. > ("openssl dhparam" produces results similar to 2.12.19.) > Do DH paramater files generated with OpenSSL/GnuTLS-2.12.19 work fine with > GnuTLS-3.0.19, or the other way round do DH paramater files generated > with GnuTLS-3.0.19 work fine with OpenSSL/GnuTLS-2.12.19? I have stumbled upon http://nikmav.blogspot.com/2011/12/generating-diffie-hellman-parameters.html which afaiu answers these questions with: Cross-Compability is no problem, but GnuTLS 3 should be faster with a file written by GnuTLS 3 because privateValueLength is used if present. Do I understand this correctly? thanks, cu andreas From n.mavrogiannopoulos at gmail.com Sun May 27 12:50:40 2012 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 27 May 2012 12:50:40 +0200 Subject: certtool --generate-dh-params: Size of generator in 2.12.19 and 3.0.19 In-Reply-To: <20120527101226.GC2626@downhill.g.la> References: <20120527095415.GB2626@downhill.g.la> <20120527101226.GC2626@downhill.g.la> Message-ID: <4FC20700.50308@gmail.com> On 05/27/2012 12:12 PM, Andreas Metzler wrote: >> + 3.0.19 Uses a large value for Generator >> + In 3.0.19 the size of "Prime" is not constant. > >> ("openssl dhparam" produces results similar to 2.12.19.) > >> Do DH paramater files generated with OpenSSL/GnuTLS-2.12.19 work fine with >> GnuTLS-3.0.19, or the other way round do DH paramater files generated >> with GnuTLS-3.0.19 work fine with OpenSSL/GnuTLS-2.12.19? > > I have stumbled upon > http://nikmav.blogspot.com/2011/12/generating-diffie-hellman-parameters.html > which afaiu answers these questions with: Cross-Compability is no > problem, but GnuTLS 3 should be faster with a file written by GnuTLS 3 > because privateValueLength is used if present. > > Do I understand this correctly? Yes, that's correct. regards, Nikos From ametzler at downhill.at.eu.org Tue May 29 20:22:02 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 29 May 2012 20:22:02 +0200 Subject: gnutls-cli does not show response to EHLO, telnet does Message-ID: <20120529182202.GE4172@downhill.g.la> Hello, it seems to be impossible to connect to smtp.jaist.ac.jp 587 with gnutls-cli: ------------------- ametzler at argenau:~$ gnutls-cli -s --priority=NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.2 smtp.jaist.ac.jp -p 587 Processed 152 CA certificate(s). Resolving 'smtp.jaist.ac.jp'... Connecting to '150.65.19.12:587'... - Simple Client Mode: 220 jaist.ac.jp ESMTP mail service ready EHLO openssl.client.net [nothing happens] ------------------- telnet succeeds. Any idea why? thanks, cu andreas From dkg at fifthhorseman.net Tue May 29 20:41:36 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 29 May 2012 14:41:36 -0400 Subject: gnutls-cli does not show response to EHLO, telnet does In-Reply-To: <20120529182202.GE4172@downhill.g.la> References: <20120529182202.GE4172@downhill.g.la> Message-ID: <4FC51860.2020804@fifthhorseman.net> On 05/29/2012 02:22 PM, Andreas Metzler wrote: > Hello, > > it seems to be impossible to connect to smtp.jaist.ac.jp 587 with > gnutls-cli: > > ------------------- > ametzler at argenau:~$ gnutls-cli -s --priority=NORMAL:%COMPAT:-VERS-TLS1.1:-VERS-TLS1.2 smtp.jaist.ac.jp -p 587 > Processed 152 CA certificate(s). > Resolving 'smtp.jaist.ac.jp'... > Connecting to '150.65.19.12:587'... > > - Simple Client Mode: > > 220 jaist.ac.jp ESMTP mail service ready > EHLO openssl.client.net > [nothing happens] > ------------------- > > telnet succeeds. Any idea why? It looks to me like smtp.jaist.ac.jp expects proper CRLF line endings. Compare: socat STDIO TCP4:smtp.jaist.ac.jp:587 socat STDIO TCP4:smtp.jaist.ac.jp:587,crnl I get a response from the latter, but not from the former. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: