From INVALID.NOREPLY at gnu.org Tue Nov 1 08:43:51 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 01 Nov 2011 07:43:51 +0000 Subject: [sr #107860] The read_file function is too generic, clashes with similarly named functions in user applications In-Reply-To: <20111031-152438.sv85909.76320@savannah.gnu.org> References: <20111031-152438.sv85909.76320@savannah.gnu.org> Message-ID: <20111101-094351.sv707.42823@savannah.gnu.org> Update of sr #107860 (project gnutls): Status: None => Done Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Thanks for reporting that. I have renamed it to gl_read_file() so it shouldn't class any more. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 1 09:37:23 2011 From: INVALID.NOREPLY at gnu.org (Martin =?UTF-8?B?U3RvcnNqw7Y=?=) Date: Tue, 01 Nov 2011 08:37:23 +0000 Subject: [sr #107860] The read_file function is too generic, clashes with similarly named functions in user applications In-Reply-To: <20111101-094351.sv707.42823@savannah.gnu.org> References: <20111031-152438.sv85909.76320@savannah.gnu.org> <20111101-094351.sv707.42823@savannah.gnu.org> Message-ID: <20111101-083723.sv85909.56329@savannah.gnu.org> Follow-up Comment #2, sr #107860 (project gnutls): Great, thanks! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ludo at gnu.org Fri Nov 4 00:43:50 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 04 Nov 2011 00:43:50 +0100 Subject: Update on the Guile bindings Message-ID: <8762j07ow9.fsf@gnu.org> Hello! I?ve merged the (gnutls) and (gnutls extra) modules in ?master? to reflect recent changes in that area, and updated the doc accordingly. While I was at it I?ve changed the installation path of the loadable Guile module: formerly it was installed as $libdir/libguile-gnutls-v-1.la, and now it will be installed as $libdir/guile/X.Y/guile-gnutls-v-2.la, where X.Y is the effective version of Guile (currently 1.8 or 2.0). The previous path was inappropriate since this shared library is not meant to be used from C. (In fact, this change had been requested to me looong ago when guile-gnutls was first packaged in Debian.) Thanks, Ludo?. From nmav at gnutls.org Fri Nov 4 19:57:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2011 19:57:12 +0100 Subject: NULL cipher suites broken in gnutls 3.0.5 ? In-Reply-To: References: Message-ID: <4EB43588.70704@gnutls.org> On 11/04/2011 01:59 AM, Fabrice Gautier wrote: > Hi, > I get decryption error when using NULL-MD5 or NULL-SHA1 cipher suites > when using gnutls-serv, and connecting with a openssl client. Hello, Thanks for reporting that. It seems the AEAD ciphers addition has broken the NULL cipher. I've committed a fix in the repository. regards, Nikos From nmav at gnutls.org Sat Nov 5 09:28:02 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 09:28:02 +0100 Subject: EC keys interoperability issue between openSSL and GnuTLS ? In-Reply-To: References: Message-ID: <4EB4F392.4010901@gnutls.org> On 11/05/2011 12:46 AM, Fabrice Gautier wrote: > Hi, > > I generated some EC keys and cert using openssl, and when I try to use > them with gnutls_serv, it seems that gnutls_serv will just crash. Ouch. It seems there are two issues here. One bug which didn't report a parsing error back to the caller (was fixed) and the fact that openssl uses an old format for storing ECC private keys. GnuTLS uses the format from RFC 5915 for ECC keys. OpenSSL seems to be able to read this format, but I couldn't find an option to generate keys using this format. regards, Nikos From nmav at gnutls.org Sat Nov 5 10:38:41 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 10:38:41 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <87hb34mz2q.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> Message-ID: <4EB50421.7070800@gnutls.org> On 10/19/2011 11:49 PM, Ludovic Court?s wrote: > I?ve reproduced it on armv5tel-unknown-linux-gnueabi, with Guile 1.8.8, > GCC 4.5.1, and glibc 2.12. > The 0x1 above seems to be the value of some port?s ?putback_buf? field. > Normally it should be either NULL or a valid pointer. > Adding ?c_port->putback_buf = NULL? in > $GNUTLS/guile/src/core.c:make_session_record_port, which is supposed to > be a non-functional change, leads to a malloc inconsistency much more > quickly (setting $MALLOC_CHECK_=2 helps catch it.) > So I?m starting to wonder if libguile and GnuTLS somehow have a > different vision of the layout of ?scm_t_port?, which would explain > these inconsistencies. Hi, Any update on that? Do the observed issue seem related to a gnulib change? regards, Nikos From n.mavrogiannopoulos at gmail.com Sat Nov 5 12:13:28 2011 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 05 Nov 2011 12:13:28 +0100 Subject: EC keys interoperability issue between openSSL and GnuTLS ? In-Reply-To: <4EB4F392.4010901@gnutls.org> References: <4EB4F392.4010901@gnutls.org> Message-ID: <4EB51A58.1090000@gmail.com> On 11/05/2011 09:28 AM, Nikos Mavrogiannopoulos wrote: > GnuTLS uses the format from RFC 5915 for ECC keys. OpenSSL seems to be > able to read this format, but I couldn't find an option to generate keys > using this format. I was wrong on that. If you generate an ECC key using: $ openssl ecparam -genkey -text -name secp224r1 it is stored using the RFC 5915 format. I don't know why your command outputs that old format. Maybe you should report it to the openssl guys. regards, Nikos From ludo at gnu.org Sun Nov 6 18:07:51 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 06 Nov 2011 18:07:51 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <4EB50421.7070800@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 05 Nov 2011 10:38:41 +0100") References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> Message-ID: <87y5vtxjq0.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On 10/19/2011 11:49 PM, Ludovic Court?s wrote: > >> I?ve reproduced it on armv5tel-unknown-linux-gnueabi, with Guile 1.8.8, >> GCC 4.5.1, and glibc 2.12. >> The 0x1 above seems to be the value of some port?s ?putback_buf? field. >> Normally it should be either NULL or a valid pointer. >> Adding ?c_port->putback_buf = NULL? in >> $GNUTLS/guile/src/core.c:make_session_record_port, which is supposed to >> be a non-functional change, leads to a malloc inconsistency much more >> quickly (setting $MALLOC_CHECK_=2 helps catch it.) >> So I?m starting to wonder if libguile and GnuTLS somehow have a >> different vision of the layout of ?scm_t_port?, which would explain >> these inconsistencies. > > Hi, > Any update on that? Do the observed issue seem related to a gnulib change? Yes. The problem is that Guile 1.8 uses off_t fields in its scm_t_port structure, which is public [0]. On armv5tel-unknown-linux-gnueabi, that structure is 96-byte long when _FILE_OFFSET_BITS == 32, and 120-bit long otherwise. By default, Guile 1.8 is compiled with _FILE_OFFSET_BITS == 32, whereas GnuTLS 3.0 gets compiled with _FILE_OFFSET_BITS == 64 (probably as a result of a Gnulib change.) Hence the problem. A simple workaround is to build Guile 1.8 with CPPFLAGS=-D_FILE_OFFSET_BITS=64, or to #define _FILE_OFFSET_BITS 32 just before any #include in GnuTLS (or, better yet, to use Guile 2.0 ;-)). Ideally, though, GnuTLS would have a configure check to determine what _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any reliable way to do that. Ideas? Thanks, Ludo?. [0] Guile 2.0 uses scm_t_off, instead of off_t, precisely to avoid this problem. From nmav at gnutls.org Sun Nov 6 19:07:50 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Nov 2011 19:07:50 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <87y5vtxjq0.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> Message-ID: <4EB6CCF6.9000400@gnutls.org> On 11/06/2011 06:07 PM, Ludovic Court?s wrote: >> Hi, >> Any update on that? Do the observed issue seem related to a gnulib change? > > Yes. > > The problem is that Guile 1.8 uses off_t fields in its scm_t_port > structure, which is public [0]. On armv5tel-unknown-linux-gnueabi, that > structure is 96-byte long when _FILE_OFFSET_BITS == 32, and 120-bit long > otherwise. [...] > Ideally, though, GnuTLS would have a configure check to determine what > _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any > reliable way to do that. Ideas? How does the size of off_t affect the gnutls-guile code? Which code does it affect? (could it be written so that it is independent of that size?) regards, Nikos From ludo at gnu.org Sun Nov 6 21:57:26 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 06 Nov 2011 21:57:26 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <4EB6CCF6.9000400@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 06 Nov 2011 19:07:50 +0100") References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> Message-ID: <87mxc9ufyh.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On 11/06/2011 06:07 PM, Ludovic Court?s wrote: > >>> Hi, >>> Any update on that? Do the observed issue seem related to a gnulib change? >> >> Yes. >> >> The problem is that Guile 1.8 uses off_t fields in its scm_t_port >> structure, which is public [0]. On armv5tel-unknown-linux-gnueabi, that >> structure is 96-byte long when _FILE_OFFSET_BITS == 32, and 120-bit long >> otherwise. (This should read ?120-byte long?.) >> Ideally, though, GnuTLS would have a configure check to determine what >> _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any >> reliable way to do that. Ideas? > > How does the size of off_t affect the gnutls-guile code? Which code > does it affect? (could it be written so that it is independent of that > size?) The file guile/src/core.c contains code that manipulates the scm_t_port structure, which is defined by Guile and contains off_t fields. So the gnutls-guile code thinks scm_t_port is 120-byte whereas libguile thinks it?s 96-byte long, and more generally they use different field offsets. The code that uses scm_t_port in gnutls-guile relates to the ?session record port? (info "(gnutls-guile) Input and Output"). HTH, Ludo?. From nmav at gnutls.org Sun Nov 6 22:14:56 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Nov 2011 22:14:56 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <87mxc9ufyh.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> Message-ID: <4EB6F8D0.3050109@gnutls.org> On 11/06/2011 09:57 PM, Ludovic Court?s wrote: >>> Ideally, though, GnuTLS would have a configure check to determine what >>> _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any >>> reliable way to do that. Ideas? >> >> How does the size of off_t affect the gnutls-guile code? Which code >> does it affect? (could it be written so that it is independent of that >> size?) > The file guile/src/core.c contains code that manipulates the scm_t_port > structure, which is defined by Guile and contains off_t fields. So the > gnutls-guile code thinks scm_t_port is 120-byte whereas libguile thinks > it?s 96-byte long, and more generally they use different field offsets. > The code that uses scm_t_port in gnutls-guile relates to the ?session > record port? (info "(gnutls-guile) Input and Output"). I don't quite understand the issue. Ok I see access of the structure in core.c but how is that an issue? Aren't the headers that define scm_t_port correct? (in systems where is 120-byte to actually define an 120-byte structure and otherwise?). Why would the size of off_t cause issues if the header is the same in guile and gnutls? Is it a guile issue or gnutls' guile code? From ludo at gnu.org Sun Nov 6 22:35:45 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 06 Nov 2011 22:35:45 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <4EB6F8D0.3050109@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 06 Nov 2011 22:14:56 +0100") References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> <4EB6F8D0.3050109@gnutls.org> Message-ID: <878vntszm6.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On 11/06/2011 09:57 PM, Ludovic Court?s wrote: > >>>> Ideally, though, GnuTLS would have a configure check to determine what >>>> _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any >>>> reliable way to do that. Ideas? >>> >>> How does the size of off_t affect the gnutls-guile code? Which code >>> does it affect? (could it be written so that it is independent of that >>> size?) >> The file guile/src/core.c contains code that manipulates the scm_t_port >> structure, which is defined by Guile and contains off_t fields. So the >> gnutls-guile code thinks scm_t_port is 120-byte whereas libguile thinks >> it?s 96-byte long, and more generally they use different field offsets. >> The code that uses scm_t_port in gnutls-guile relates to the ?session >> record port? (info "(gnutls-guile) Input and Output"). > > I don't quite understand the issue. Ok I see access of the structure in > core.c but how is that an issue? Aren't the headers that define > scm_t_port correct? (in systems where is 120-byte to actually define an > 120-byte structure and otherwise?). Why would the size of off_t cause > issues if the header is the same in guile and gnutls? Is it a guile > issue or gnutls' guile code? Try this: #include int main () { printf ("%i -> %i\n", _FILE_OFFSET_BITS, sizeof (scm_t_port)); } Compile & run with -D_FILE_OFFSET_BITS=32 then -D_FILE_OFFSET_BITS=64: 32 -> 96 64 -> 120 Problems arise when libguile is compiled, say, with _FILE_OFFSET_BITS=32 whereas gnutls-guile is compiled with _FILE_OFFSET_BITS=64. Does that clarify a bit? Thanks, Ludo?. From nmav at gnutls.org Sun Nov 6 23:58:29 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Nov 2011 23:58:29 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <878vntszm6.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> <4EB6F8D0.3050109@gnutls.org> <878vntszm6.fsf@gnu.org> Message-ID: <4EB71115.2020502@gnutls.org> On 11/06/2011 10:35 PM, Ludovic Court?s wrote: >> Is it a guile >> issue or gnutls' guile code? > > Try this: > > #include > int main () { > printf ("%i -> %i\n", _FILE_OFFSET_BITS, sizeof (scm_t_port)); > } > Compile & run with -D_FILE_OFFSET_BITS=32 then -D_FILE_OFFSET_BITS=64: > 32 -> 96 > 64 -> 120 > Problems arise when libguile is compiled, say, with _FILE_OFFSET_BITS=32 > whereas gnutls-guile is compiled with _FILE_OFFSET_BITS=64. So as I understand it, it doesn't really seem like a gnutls or guile issue. Wouldn't all programs (and especially libraries) be compiled with the same file offset bits in a system? (Andreas?) regards, Nikos From ametzler at downhill.at.eu.org Mon Nov 7 19:48:20 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 7 Nov 2011 19:48:20 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <4EB71115.2020502@gnutls.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> <4EB6F8D0.3050109@gnutls.org> <878vntszm6.fsf@gnu.org> <4EB71115.2020502@gnutls.org> Message-ID: <20111107184820.GA2483@downhill.g.la> On 2011-11-06 Nikos Mavrogiannopoulos wrote: > On 11/06/2011 10:35 PM, Ludovic Court?s wrote: [...] >> Try this: >> >> #include >> int main () { >> printf ("%i -> %i\n", _FILE_OFFSET_BITS, sizeof (scm_t_port)); >> } >> Compile & run with -D_FILE_OFFSET_BITS=32 then -D_FILE_OFFSET_BITS=64: >> 32 -> 96 >> 64 -> 120 >> Problems arise when libguile is compiled, say, with _FILE_OFFSET_BITS=32 >> whereas gnutls-guile is compiled with _FILE_OFFSET_BITS=64. > So as I understand it, it doesn't really seem like a gnutls or guile > issue. Wouldn't all programs (and especially libraries) be compiled with > the same file offset bits in a system? (Andreas?) Hello, (At least) on 32bit systems building with _FILE_OFFSET_BITS=32 is done by default, however packages which need to/want to handle large (> 2GB) files need to be built with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Guile1.8 seems to be built without LFS. GnuTLS also used to be built without LFS flags. However this changed with 2385c7f999c12802b11859a34b89ff7662b1f4af. 5 new gnulib modules are added, two of these (argp and scandir) pull in largefile.m4. Bang. 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 ludo at gnu.org Mon Nov 7 21:31:20 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 07 Nov 2011 21:31:20 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <4EB71115.2020502@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 06 Nov 2011 23:58:29 +0100") References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> <4EB6F8D0.3050109@gnutls.org> <878vntszm6.fsf@gnu.org> <4EB71115.2020502@gnutls.org> Message-ID: <87obwny8rr.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On 11/06/2011 10:35 PM, Ludovic Court?s wrote: > >>> Is it a guile >>> issue or gnutls' guile code? >> >> Try this: >> >> #include >> int main () { >> printf ("%i -> %i\n", _FILE_OFFSET_BITS, sizeof (scm_t_port)); >> } >> Compile & run with -D_FILE_OFFSET_BITS=32 then -D_FILE_OFFSET_BITS=64: >> 32 -> 96 >> 64 -> 120 >> Problems arise when libguile is compiled, say, with _FILE_OFFSET_BITS=32 >> whereas gnutls-guile is compiled with _FILE_OFFSET_BITS=64. > > So as I understand it, it doesn't really seem like a gnutls or guile > issue. Well, yes and no. Application programmers are free to choose whichever _FILE_OFFSET_BITS they may want. So it?s a Guile problem in the sense that libguile?s API should match its ABI, and thus should be independent of the _FILE_OFFSET_BITS value its users choose for themselves. That?s how it was fixed in Guile 2.0: http://git.savannah.gnu.org/cgit/guile.git/commit/?id=f1ce9199335bebab1a62286ac965f33dc91ca97f Thanks, Ludo?. From nmav at gnutls.org Mon Nov 7 21:35:55 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Nov 2011 21:35:55 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <87obwny8rr.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <4EB6CCF6.9000400@gnutls.org> <87mxc9ufyh.fsf@gnu.org> <4EB6F8D0.3050109@gnutls.org> <878vntszm6.fsf@gnu.org> <4EB71115.2020502@gnutls.org> <87obwny8rr.fsf@gnu.org> Message-ID: <4EB8412B.8060801@gnutls.org> On 11/07/2011 09:31 PM, Ludovic Court?s wrote: >>> Compile & run with -D_FILE_OFFSET_BITS=32 then -D_FILE_OFFSET_BITS=64: >>> 32 -> 96 >>> 64 -> 120 >>> Problems arise when libguile is compiled, say, with _FILE_OFFSET_BITS=32 >>> whereas gnutls-guile is compiled with _FILE_OFFSET_BITS=64. >> >> So as I understand it, it doesn't really seem like a gnutls or guile >> issue. > > Well, yes and no. Application programmers are free to choose whichever > _FILE_OFFSET_BITS they may want. So it?s a Guile problem in the sense > that libguile?s API should match its ABI, and thus should be independent > of the _FILE_OFFSET_BITS value its users choose for themselves. > > That?s how it was fixed in Guile 2.0: > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=f1ce9199335bebab1a62286ac965f33dc91ca97f I've reported it to gnulib because adding unrelated modules shouldn't enable 64-bit support implicitly anyway. regards, Nikos From nmav at gnutls.org Mon Nov 7 22:42:22 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Nov 2011 22:42:22 +0100 Subject: gnutls 3.0.6 Message-ID: <4EB850BE.7000409@gnutls.org> Hello, I've just released gnutls 3.0.6. It is a bug-fix release on the current stable branch. * Version 3.0.6 (released 2011-11-07) ** gnutls-guile: Compilation fixes. ** libgnutls: Fixed possible buffer overflow in gnutls_session_get_data(). Reported and fix by Alban Crequy. ** libgnutls: Bug fixes in the ciphersuites with NULL cipher. Reported by Fabrice Gautier. ** libgnutls: Bug fixes in ECC code for 64-bit MIPS systems. Thanks to Joseph Graham for providing access to such a system. ** libgnutls: Correctly report ECC private key parsing errors. Reported by Fabrice Gautier. ** libgnutls: In ECDHE verify that the received point lies on the selected curve. The ECDHE ciphersuites now take precendence to plain DHE. ** 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-3.0.6.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.6.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.6.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.6.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Nov 7 22:42:37 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Nov 2011 22:42:37 +0100 Subject: gnutls 2.12.13 Message-ID: <4EB850CD.2010908@gnutls.org> Hello, I've just released gnutls 2.12.13. This is a bugfix release on the 2.12.x branch. Version 2.12.13 (released 2011-11-07) ** minitasn1: Upgraded to libtasn1 version 2.10. ** libgnutls: Fixed possible buffer overflow in gnutls_session_get_data(). Reported and fix by Alban Crequy. ** 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.13.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.13.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 nmav at gnutls.org Tue Nov 8 08:26:25 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 08 Nov 2011 08:26:25 +0100 Subject: gnutls 3.0.7 Message-ID: <4EB8D9A1.3080800@gnutls.org> Hello, I've just released gnutls 3.0.7. The 3.0.6 release introduced a usability issue in an attempt to fix a security bug. This release eliminates the usability issue. I understand there is not much information on the security issue. This might change soon. * Version 3.0.7 (released 2011-11-08) ** libgnutls: Corrected fix in gnutls_session_get_data() to report the actual session size when the provided buffer is not enough. ** libgnutls: Fixed ciphersuite GNUTLS_ECDHE_RSA_AES_128_CBC_SHA256, which was using a wrong MAC algorithm. Reported by Fabrice Gautier. ** 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-3.0.7.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.7.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.7.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.7.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Tue Nov 8 08:29:02 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 08 Nov 2011 08:29:02 +0100 Subject: gnutls 2.12.14 Message-ID: <4EB8DA3E.5020206@gnutls.org> Hello, I've just released gnutls 2.12.14. This is a bugfix release on the 2.12.x branch. Version 2.12.14 (released 2011-11-08) ** libgnutls: Corrected fix in gnutls_session_get_data() to report the actual session size when the provided buffer is not enough. ** 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.14.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.14.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 alban.crequy at collabora.co.uk Tue Nov 8 12:55:54 2011 From: alban.crequy at collabora.co.uk (Alban Crequy) Date: Tue, 8 Nov 2011 11:55:54 +0000 Subject: Possible buffer overflow on gnutls_session_get_data Message-ID: <20111108115554.1a34d07a@chocolatine.cbg.collabora.co.uk> The gnutls_session_get_data function in the GnuTLS library before 3.0.6 or before 2.12.13 on the 2.12.x branch could overflow a too-short buffer parameter allocated by the caller. The test to avoid the buffer overflow was not working correctly. Often the code using the GnuTLS library calls gnutls_session_get_data() twice: the first time to get the buffer size and the second time with a buffer allocated to the correct size. In this code pattern, there is no buffer overflows. But if gnutls_session_get_data() is called with a too-short buffer, the function failed to detect it and it would overflow. I am not aware of any code using gnutls_session_get_data() in this way. It could be that there is no real software affected by this bug. The size of the session data is determined by the server and it is opaque to the client. RFC#5077 suggests it could be around 65kB but it is not mandatory. A malicious server could send a larger SessionTicket in the hope to overflow the client. From nmav at gnutls.org Tue Nov 8 13:49:14 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Nov 2011 13:49:14 +0100 Subject: Possible buffer overflow on gnutls_session_get_data In-Reply-To: <20111108115554.1a34d07a@chocolatine.cbg.collabora.co.uk> References: <20111108115554.1a34d07a@chocolatine.cbg.collabora.co.uk> Message-ID: On Tue, Nov 8, 2011 at 12:55 PM, Alban Crequy wrote: > The gnutls_session_get_data function in the GnuTLS library before > 3.0.6 or before 2.12.13 on the 2.12.x branch could overflow a > too-short buffer parameter allocated by the caller. The test to avoid > the buffer overflow was not working correctly. > Often the code using the GnuTLS library calls gnutls_session_get_data() > twice: the first time to get the buffer size and the second time with a > buffer allocated to the correct size. In this code pattern, there is no > buffer overflows. [...] Thank you for finding out this bug and reporting it. I'll point the security advisory for this issue to your mail later this day. An update to your note is that gnutls releases 2.12.14 and 3.0.7 correctly fix the issue. best regards, Nikos From simon at josefsson.org Wed Nov 9 15:29:56 2011 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 09 Nov 2011 15:29:56 +0100 Subject: Compile fix for gnutls-3.0.5 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 28 Oct 2011 14:08:26 +0200") References: <4EA9BA9A.5070107@rcn.com> <87y5w5eb8w.fsf@latte.josefsson.org> <87ty6teb67.fsf@latte.josefsson.org> Message-ID: <87mxc5qsgr.fsf@latte.josefsson.org> This should be fixed now. I've made a bunch of other documentation tweaks as well... unfortunately one side effect was that all man pages for the APIs were lost because our way of generating them was broken (many APIs did not have man pages). I'm not convinced there is a huge demand for API man pages, but if there is, it would be great if someone had time to either fix the Makefile rules or come up with a more reliable way of generating the man pages (from gtk-doc perhaps?). /Simon Nikos Mavrogiannopoulos writes: > Please check into it. I have no idea on the gtk-doc manual generation. > > regards, > Nikos > > On Fri, Oct 28, 2011 at 11:08 AM, Simon Josefsson wrote: >> Trying to build trunk, I also noticed that libgnutls-extra is still >> referenced by the GTK-DOC manual... >> >> gtk-doc: Building HTML >> warning: failed to load external entity "../xml/extra.xml" >> ../gnutls-docs.sgml:25: element include: XInclude error : could not >> load ../xml/extra.xml, and no fallback was found >> warning: failed to load external entity "../xml/openssl.xml" >> ../gnutls-docs.sgml:32: element include: XInclude error : could not >> load ../xml/openssl.xml, and no fallback was found >> Computing chunks... >> >> /Simon >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> https://lists.gnu.org/mailman/listinfo/gnutls-devel >> From nmav at gnutls.org Thu Nov 10 22:19:21 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Nov 2011 22:19:21 +0100 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> Message-ID: <4EBC3FD9.3040400@gnutls.org> On 11/10/2011 10:11 PM, Fabrice Gautier wrote: > Hum, so actually I upgrade to 3.0.7 on the Good system, and now its bad... > Bug introduced between 3.0.5 and 3.0.7 ? Unfortunately yes. It does not export working ECDSA keys. I've fixed the issue and added test cases in master. That is the reason you had that issue. From ametzler at downhill.at.eu.org Fri Nov 11 19:49:53 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 11 Nov 2011 19:49:53 +0100 Subject: 2.12.12 and later: FAIL: test-select (on kfreebsd-i386) Message-ID: <20111111184953.GA2001@downhill.g.la> Hello, from 2.12.12 on gnutls stopped building on kfreebsd-i386. The gnulib test-select test fails: ----------------- (sid)ametzler at io:~/GNUTLS$ ./gnutls26-2.12.11/gl/tests/test-select ; echo $? Unconnected socket test... passed Connected sockets test... passed General socket test with fork... passed Pipe test... passed 0 (sid)ametzler at io:~/GNUTLS$ ./gnutls26-2.12.12/gl/tests/test-select ; echo $? Invalid fd test... failed (invalid fd among rfds) failed (invalid fd among wfds) failed (invalid fd among xfds) Unconnected socket test... passed Connected sockets test... passed General socket test with fork... passed Pipe test... passed 3 ----------------- 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 hoyt6 at llnl.gov Fri Nov 11 22:31:43 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Fri, 11 Nov 2011 13:31:43 -0800 Subject: Generating EC keys with certtool In-Reply-To: References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> <4EBC3FD9.3040400@gnutls.org> Message-ID: > What do I need to build gnutls from the git repo? Use "make -f cfg.mk autoreconf" From fabrice.gautier at gmail.com Fri Nov 11 22:27:45 2011 From: fabrice.gautier at gmail.com (Fabrice Gautier) Date: Fri, 11 Nov 2011 13:27:45 -0800 Subject: Generating EC keys with certtool In-Reply-To: <4EBC3FD9.3040400@gnutls.org> References: <4EBC0615.7000602@gnutls.org> <4EBC22FB.3080209@gnutls.org> <4EBC2CED.5040607@gnutls.org> <4EBC2F4E.5010602@gmail.com> <4EBC3FD9.3040400@gnutls.org> Message-ID: What do I need to build gnutls from the git repo ? It does not have the configure script in there, so I guess I need to use autoconf or automake to generate them, but I'm unsure on how this is done, or which version of those tools it would require. Thanks -- Fabrice On Thu, Nov 10, 2011 at 1:19 PM, Nikos Mavrogiannopoulos wrote: > On 11/10/2011 10:11 PM, Fabrice Gautier wrote: >> Hum, so actually I upgrade to 3.0.7 on the Good system, and now its bad... >> Bug introduced between 3.0.5 and 3.0.7 ? > > Unfortunately yes. It does not export working ECDSA keys. I've fixed the > issue and added test cases in master. That is the reason you had that issue. > > > From nmav at gnutls.org Sat Nov 12 16:11:11 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Nov 2011 16:11:11 +0100 Subject: gnutls 3.0.8 Message-ID: <4EBE8C8F.6040503@gnutls.org> Hello, I've just released gnutls 3.0.8. This release fixes issues in ECC key generation, and reduces the timing information provided to an adversary in DTLS. * Version 3.0.8 (released 2011-11-12) ** certtool: Certtool -e returns error code on verification failure. ** certtool: Verifies parameters of generated keys. ** libgnutls: Corrected ECC key generation (introduced in 3.0.6) ** libgnutls: Provide less timing information when decoding TLS/DTLS record packets. ** doc: man pages for API functions were removed. The reason was that the code that auto-generated the man pages missed many APIs and we couldn't fix it (volunteers welcome). See the info manual or the GTK-DOC manual instead. ** API and ABI modifications: gnutls_x509_privkey_verify_params: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.8.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.8.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.8.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From ametzler at downhill.at.eu.org Sat Nov 12 17:16:54 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 12 Nov 2011 17:16:54 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel In-Reply-To: <87y5vtxjq0.fsf@gnu.org> References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> Message-ID: <20111112161654.GA2020@downhill.g.la> On 2011-11-06 Ludovic Court?s wrote: [...] > The problem is that Guile 1.8 uses off_t fields in its scm_t_port > structure, which is public [0]. On armv5tel-unknown-linux-gnueabi, that > structure is 96-byte long when _FILE_OFFSET_BITS == 32, and 120-bit long > otherwise. > By default, Guile 1.8 is compiled with _FILE_OFFSET_BITS == 32, whereas > GnuTLS 3.0 gets compiled with _FILE_OFFSET_BITS == 64 (probably as a > result of a Gnulib change.) Hence the problem. > A simple workaround is to build Guile 1.8 with > CPPFLAGS=-D_FILE_OFFSET_BITS=64, or to #define _FILE_OFFSET_BITS 32 just > before any #include in GnuTLS (or, better yet, to use Guile > 2.0 ;-)). FYI as a hotfix I am now building gnutls with --disable-largefile on armel armhf mipsel. > Ideally, though, GnuTLS would have a configure check to determine what > _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any > reliable way to do that. Ideas? [...] Could you build a simple program that returns sizeof(scm_t_port)? cu andreas From ludo at gnu.org Sun Nov 13 00:21:02 2011 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 13 Nov 2011 00:21:02 +0100 Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel References: <20111016160905.GA1921@downhill.g.la> <87hb34mz2q.fsf@gnu.org> <4EB50421.7070800@gnutls.org> <87y5vtxjq0.fsf@gnu.org> <20111112161654.GA2020@downhill.g.la> Message-ID: <87aa81orkx.fsf@gnu.org> Hi Andreas, Andreas Metzler skribis: >> Ideally, though, GnuTLS would have a configure check to determine what >> _FILE_OFFSET_BITS value Guile is expecting, but I can?t think of any >> reliable way to do that. Ideas? > [...] > > Could you build a simple program that returns sizeof(scm_t_port)? The result would be dependent on the _FILE_OFFSET_BITS settings of the program that computes sizeof(scm_t_port). What you want to know is libguile.so?s idea of sizeof(scm_t_port), which is another kettle of fish... Thanks, Ludo?. From nmav at gnutls.org Mon Nov 14 14:01:33 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Nov 2011 14:01:33 +0100 Subject: 2.12.12 and later: FAIL: test-select (on kfreebsd-i386) In-Reply-To: <20111111184953.GA2001@downhill.g.la> References: <20111111184953.GA2001@downhill.g.la> Message-ID: <4EC1112D.5050906@gnutls.org> On 11/11/2011 07:49 PM, Andreas Metzler wrote: > Hello, > from 2.12.12 on gnutls stopped building on kfreebsd-i386. The > gnulib test-select test fails: I've reported it to bug-gnulib. I'd suggest to ignore that issue, at least for the library (which doesn't use select() in 2.12.x. For the applications there might be an issue, but given that 2.12.11 was working and the gnulib select was exactly the same (only the test changed), I bet they are ok too. regards, Nikos From toralf.foerster at gmx.de Mon Nov 14 16:23:48 2011 From: toralf.foerster at gmx.de (Toralf =?utf-8?q?F=C3=B6rster?=) Date: Mon, 14 Nov 2011 16:23:48 +0100 Subject: DSA-1024 with TLS 1.0 test fails w/ current gnutls version Message-ID: <201111141623.48762.toralf.foerster@gmx.de> May I point you to a problem which doesn't vanished althought a patch was introduced in the code as a Gentoo dev said : https://bugs.gentoo.org/show_bug.cgi?id=389959 ? -- MfG/Sincerely Toralf F?rster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 From nmav at gnutls.org Mon Nov 14 17:12:58 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Nov 2011 17:12:58 +0100 Subject: DSA-1024 with TLS 1.0 test fails w/ current gnutls version In-Reply-To: <201111141623.48762.toralf.foerster@gmx.de> References: <201111141623.48762.toralf.foerster@gmx.de> Message-ID: <4EC13E0A.6050108@gnutls.org> On 11/14/2011 04:23 PM, Toralf F?rster wrote: > May I point you to a problem which doesn't vanished althought a patch was > introduced in the code as a Gentoo dev said : > > https://bugs.gentoo.org/show_bug.cgi?id=389959 Hi, The patch that was previously sent to solve that issue was applied. Is the failure because of another reason (and if yes which?) regards, Nikos From INVALID.NOREPLY at gnu.org Tue Nov 15 10:42:57 2011 From: INVALID.NOREPLY at gnu.org (Martin =?UTF-8?B?U3RvcnNqw7Y=?=) Date: Tue, 15 Nov 2011 09:42:57 +0000 Subject: [sr #107874] Parallel builds for mingw fail Message-ID: <20111115-094255.sv85909.47054@savannah.gnu.org> URL: Summary: Parallel builds for mingw fail Project: GnuTLS Submitted by: mstorsjo Submitted on: Tue 15 Nov 2011 09:42:55 AM GMT Category: Core library Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: Currently, parallel builds for mingw fail with this error: make[2]: *** No rule to make target `libgnutls-26.def', needed by `all-am'. Stop. This comes from the fact that libgnutls-26.def is generated implicitly when libgnutls.la is built, and make does not know about this. The attached patch fixes the issue by adding a dependency on libgnutls.la, so that make won't bother about the def file until the la file is built. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 15 Nov 2011 09:42:55 AM GMT Name: 0001-Add-dependencies-from-the-def-files-to-the-libraries.patch Size: 2kB By: mstorsjo _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tapiwa.gutu at gmail.com Tue Nov 15 18:24:16 2011 From: tapiwa.gutu at gmail.com (Tapiwa Gutu) Date: Tue, 15 Nov 2011 19:24:16 +0200 Subject: gnutls_e_asn1_element_not_found Message-ID: Hi, I am writing a server application to to use TLS in Common Lisp running on Ubuntu 10.04LTS. Since I am using a foreign language I load gnutls.so into my image. I am incrementally building it up and everything is working well so far but when I perform a handshake with any server I get a GNUTLS_E_ASN1_ELEMENT_NOT_FOUND error. Connecting to the same server using gnutls-cli with the same ciphersuite and priority string works so I am stumped. Ideas? Regards, Tapiwa MIH Electronic Media Lab Electronic & Electrical Engineering Department Stellenbosch University South Africa http://www.ml.sun.ac.za/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Nov 15 23:20:51 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 15 Nov 2011 23:20:51 +0100 Subject: gnutls_e_asn1_element_not_found In-Reply-To: References: Message-ID: <4EC2E5C3.1050501@gnutls.org> On 11/15/2011 06:24 PM, Tapiwa Gutu wrote: > Hi, > > I am writing a server application to to use TLS in Common Lisp running on > Ubuntu 10.04LTS. Since I am using a foreign language I load gnutls.so into > my image. > I am incrementally building it up and everything is working well so far but > when I perform a handshake with any server I get a > GNUTLS_E_ASN1_ELEMENT_NOT_FOUND error. > Connecting to the same server using gnutls-cli with the same ciphersuite > and priority string works so I am stumped. Ideas? Did you execute gnutls_global_init()? From INVALID.NOREPLY at gnu.org Wed Nov 16 14:27:51 2011 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Wed, 16 Nov 2011 13:27:51 +0000 Subject: [sr #107874] Parallel builds for mingw fail In-Reply-To: <20111115-094255.sv85909.47054@savannah.gnu.org> References: <20111115-094255.sv85909.47054@savannah.gnu.org> Message-ID: <20111116-132751.sv7213.30778@savannah.gnu.org> Update of sr #107874 (project gnutls): Status: None => Done Assigned to: None => jas Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: I've applied it, thank you. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 16 14:28:20 2011 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Wed, 16 Nov 2011 13:28:20 +0000 Subject: [sr #107860] The read_file function is too generic, clashes with similarly named functions in user applications In-Reply-To: <20111101-083723.sv85909.56329@savannah.gnu.org> References: <20111031-152438.sv85909.76320@savannah.gnu.org> <20111101-094351.sv707.42823@savannah.gnu.org> <20111101-083723.sv85909.56329@savannah.gnu.org> Message-ID: <20111116-132820.sv7213.57614@savannah.gnu.org> Update of sr #107860 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #3: I've modified the solution here to use config.h #define's instead. Please test. I'm closing this meanwhile... _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 16 14:54:18 2011 From: INVALID.NOREPLY at gnu.org (Martin =?UTF-8?B?U3RvcnNqw7Y=?=) Date: Wed, 16 Nov 2011 13:54:18 +0000 Subject: [sr #107860] The read_file function is too generic, clashes with similarly named functions in user applications In-Reply-To: <20111116-132820.sv7213.57614@savannah.gnu.org> References: <20111031-152438.sv85909.76320@savannah.gnu.org> <20111101-094351.sv707.42823@savannah.gnu.org> <20111101-083723.sv85909.56329@savannah.gnu.org> <20111116-132820.sv7213.57614@savannah.gnu.org> Message-ID: <20111116-135418.sv85909.96705@savannah.gnu.org> Follow-up Comment #4, sr #107860 (project gnutls): The new solution using #defines seem to work just fine as well. Thanks! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From rebelneurofog at gmail.com Wed Nov 16 20:05:24 2011 From: rebelneurofog at gmail.com (Rebel Neurofog) Date: Wed, 16 Nov 2011 22:05:24 +0300 Subject: Documentation HTML troubles Message-ID: Hi! Did you notice that you've got troubles with HTML documentation? It seems to be a problem of makeinfo to HTML generator. I've noticed several problems and I'm afraid there are more. That's probably due to version mismatch or invalid scheme or even wrong processing sequence (like re-escaping already escaped sequences). 1. http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_check_version it don't scroll you where it should but following would: http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_005fcheck_005fversion You may find this in HTML code: 2. On the same page at very beginning find the text: "This function will return a string that describes the given alert number, or . See ." Again troubles with references. Good luck, guys! From nmav at gnutls.org Thu Nov 17 23:55:12 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Nov 2011 23:55:12 +0100 Subject: Documentation HTML troubles In-Reply-To: References: Message-ID: <4EC590D0.9040606@gnutls.org> On 11/16/2011 08:05 PM, Rebel Neurofog wrote: > Hi! > > Did you notice that you've got troubles with HTML documentation? > It seems to be a problem of makeinfo to HTML generator. Indeed. It seems that switching to texi2html produces a better output. The next version might have its documentation updated as well. > I've noticed several problems and I'm afraid there are more. > That's probably due to version mismatch or invalid scheme > or even wrong processing sequence (like re-escaping already escaped sequences). > 1. http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_check_version > it don't scroll you where it should but following would: > http://www.gnu.org/s/gnutls/manual/html_node/Core-functions.html#gnutls_005fcheck_005fversion > You may find this in HTML code: > > 2. On the same page at very beginning find the text: > "This function will return a string that describes the given alert > number, or . See ." > Again troubles with references. This is the problem of supporting multiple formats :) It seems that the texinfo and manpages formats had issues that didn't exist in latex output that I was checking. I commited a fix for the generation. Thanks for reporting it. regards, Nikos From info at prosistel.es Sat Nov 19 07:11:32 2011 From: info at prosistel.es (Prosistel, Technology Consulting) Date: Sat, 19 Nov 2011 07:11:32 +0100 Subject: HTTPS server running GnuTLS is not available Message-ID: Hello, I'm trying to test the online HTTPS server, but it doesn't work. https://test.gnutls.org:5556/ Thanks, Jose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nix at esperi.org.uk Wed Nov 23 18:48:23 2011 From: nix at esperi.org.uk (Nix) Date: Wed, 23 Nov 2011 17:48:23 +0000 Subject: [PATCH] Missing config.h inclusion breaks 32-bit _LARGEFILE64_SOURCE compilation --with-zlib Message-ID: <87lir6ybko.fsf@spindle.srvr.nix> When building a 32-bit gnutls, when _LARGEFILE64_SOURCE is set in CFLAGS and _FILE_OFFSET_BITS=64 is not, and zlib is built in, we see this failure: In file included from ../gnutls_compress.h:45:0, from ../gnutls_int.h:300, from opencdk.h:31, from dummy.c:4: /usr/include/32/zlib.h:1583:30: error: conflicting types for 'gzseek64' /usr/include/32/zlib.h:1567:30: note: previous declaration of 'gzseek64' was here /usr/include/32/zlib.h:1584:30: error: conflicting types for 'gztell64' /usr/include/32/zlib.h:1568:30: note: previous declaration of 'gztell64' was here /usr/include/32/zlib.h:1585:30: error: conflicting types for 'gzoffset64' /usr/include/32/zlib.h:1569:30: note: previous declaration of 'gzoffset64' was here /usr/include/32/zlib.h:1586:28: error: conflicting types for 'adler32_combine64' /usr/include/32/zlib.h:1570:26: note: previous declaration of 'adler32_combine64' was here /usr/include/32/zlib.h:1587:28: error: conflicting types for 'crc32_combine64' /usr/include/32/zlib.h:1571:26: note: previous declaration of 'crc32_combine64' was here This is because dummy.c does not include config.h early enough (which defines _FILE_OFFSET_BITS=64 in this situation): thus, we end up with z_off_t and z_off64_t as two distinct types, yet _FILE_OFFSET_BITS=64 also set. This leads to two distinct definitions of gzseek64() et al, and compilation fails. (If we could rely on using GCC, we could use -include to avoid this error-prone include-at-the-top-of-every-file stuff. But we can't, so we can't.) --- lib/opencdk/dummy.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Applies to 2.12.x, 3.0.x, and master. diff --git a/lib/opencdk/dummy.c b/lib/opencdk/dummy.c index be44a35..dd54dda 100644 --- a/lib/opencdk/dummy.c +++ b/lib/opencdk/dummy.c @@ -1,3 +1,6 @@ +#ifdef HAVE_CONFIG_H +#include +#endif #include #include -- 1.7.7.2.144.g3624f From nmav at gnutls.org Thu Nov 24 08:22:26 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 24 Nov 2011 08:22:26 +0100 Subject: [PATCH] Missing config.h inclusion breaks 32-bit _LARGEFILE64_SOURCE compilation --with-zlib In-Reply-To: <87lir6ybko.fsf@spindle.srvr.nix> References: <87lir6ybko.fsf@spindle.srvr.nix> Message-ID: <4ECDF0B2.6010702@gnutls.org> On 11/23/2011 06:48 PM, Nix wrote: > When building a 32-bit gnutls, when _LARGEFILE64_SOURCE is set in CFLAGS > and _FILE_OFFSET_BITS=64 is not, and zlib is built in, we see this > failure: Thanks for reporting that. I've fixed that in master by removing this file completely. regards, Nikos From pablo.cantarini at gilbarco.com Thu Nov 24 22:14:20 2011 From: pablo.cantarini at gilbarco.com (Pablo Cantarini) Date: Thu, 24 Nov 2011 21:14:20 +0000 (UTC) Subject: about PKCS11 References: <4E8E055D.2080900@gnutls.org> <4E8FE946.1000502@collabora.co.uk> <4E9C2F5A.2080706@thewalter.net> Message-ID: Stef Walter thewalter.net> writes: > > On 10/08/2011 08:10 AM, Stef Walter wrote: > > On 2011-10-06 21:45, Nikos Mavrogiannopoulos wrote: > >> Hello, > >> Do you need smart card support? If not just use the --without-p11-kit > >> configure flag. If you need smart-card support in gnutls, then I don't > >> know whether p11-kit is could run on windows. Stef would have more > >> insight on that. > > > > Yes, win32 support needs to be done. I don't see any major obstacles, > > but I just need to get a win32 VM setup and actually work on it. I > > imagine I'll need to do an MSVC and a GCC mingw build. I'm not looking > > forward to releasing binaries, but at least I'll get it building. > > Completed the initial port of p11-kit to win32. It's at p11-kit git master. > > The build works, and the tools run. I built with: > > $ ./autogen.sh --host=i586-mingw32msvc --enable-strict ... > > The tests don't all pass on wine yet. In particular the test-init > recursion test fails. But I'm not sure if this is a wine bug or a > problem in the p11-kit windows stuff. > > The win32 port needs more attention, but at least this is a start. > > Thanks Vincent for your help. > > Cheers, > > Stef > Hi Stef, I'm trying to build GnuTLS on windows using MinGW. Due to this I'm building p11- kit to as I want to have the feature. Just running: ./configure --enable-shared make make check Indeed, "test-init.exe" is failing while initializing the module using threads. What I see is that the first call of "p11_kit_initialize_module" succeeds but the second one fails. By the time the _p11_thread_join over the second thread tries to join, the CuAssertTrue at "initialization_thread" in the second thread was triggered. I'm using a native windows (WinXP SP3) 32 bit machine. Is there any findings on how this can be fixed? Thanks, -Pablo. From nix at esperi.org.uk Fri Nov 25 13:00:50 2011 From: nix at esperi.org.uk (Nix) Date: Fri, 25 Nov 2011 12:00:50 +0000 Subject: [PATCH] Missing config.h inclusion breaks 32-bit _LARGEFILE64_SOURCE compilation --with-zlib In-Reply-To: <4ECDF0B2.6010702@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 24 Nov 2011 08:22:26 +0100") References: <87lir6ybko.fsf@spindle.srvr.nix> <4ECDF0B2.6010702@gnutls.org> Message-ID: <87zkfkwgwd.fsf@spindle.srvr.nix> On 24 Nov 2011, Nikos Mavrogiannopoulos verbalised: > On 11/23/2011 06:48 PM, Nix wrote: >> When building a 32-bit gnutls, when _LARGEFILE64_SOURCE is set in CFLAGS >> and _FILE_OFFSET_BITS=64 is not, and zlib is built in, we see this >> failure: > > Thanks for reporting that. I've fixed that in master by removing this > file completely. I wondered what it was for... :) -- NULL && (void) From INVALID.NOREPLY at gnu.org Wed Nov 30 13:38:30 2011 From: INVALID.NOREPLY at gnu.org (Elias Pipping) Date: Wed, 30 Nov 2011 12:38:30 +0000 Subject: [sr #107896] gnutls 3.0.8 fails to compile with clang Message-ID: <20111130-123829.sv76013.65986@savannah.gnu.org> URL: Summary: gnutls 3.0.8 fails to compile with clang Project: GnuTLS Submitted by: pipping Submitted on: Wed 30 Nov 2011 12:38:29 GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Earlier versions worked. (My theory for) the reason this version does not work for: gl/argp-parse.c uses alignof(); for that, is included. a usable stdalign.h is also shipped with gnutls for use with compilers that don't come with such a header yet. clang does have such a header but it only defines alignas(), not alignof(). here is the actual error: argp-parse.c:490:41: error: expected expression csum = alignto (gsum + clen, alignof (struct option)); ^ And this is what /usr/lib64/clang/3.1/include/stdalign.h contains for me (aside from the copyright header and the include guards): #define alignas _Alignas #define __alignas_is_defined 1 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/