From mschamschula at gmail.com Sun Sep 1 21:58:26 2013 From: mschamschula at gmail.com (Marius Schamschula) Date: Sun, 1 Sep 2013 14:58:26 -0500 Subject: [gnutls-devel] GnuTLS 3.2.4: error.h missing under Mac OS X Message-ID: Hi there, I had build failures for GnuTLS 3.2.4 under Mac OS X 10.6 though 10.9: in /private/tmp/gnutls-3.2.4/src several files ask for error.h. The only problem is that there is no such (system) file. When I go to that directory and touch error.h, the compile completes as expected. -- Marius Schamschula From nmav at gnutls.org Mon Sep 2 17:08:02 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Sep 2013 18:08:02 +0300 Subject: [gnutls-devel] GnuTLS 3.2.4: error.h missing under Mac OS X In-Reply-To: References: Message-ID: On Sun, Sep 1, 2013 at 10:58 PM, Marius Schamschula wrote: > Hi there, > I had build failures for GnuTLS 3.2.4 under Mac OS X 10.6 though 10.9: > in /private/tmp/gnutls-3.2.4/src several files ask for error.h. The only problem is that there is no such (system) file. > When I go to that directory and touch error.h, the compile completes as expected. Thanks. This seems to be a side-effect from restricting gnulib to the lgpl2 components. I've committed a fix on the repository for that. regards, Nikos From wiz at NetBSD.org Mon Sep 2 18:05:56 2013 From: wiz at NetBSD.org (Thomas Klausner) Date: Mon, 2 Sep 2013 18:05:56 +0200 Subject: [gnutls-devel] portability problem in gnutls-3.2.4: error.h Message-ID: <20130902160556.GT18064@danbala.tuwien.ac.at> Hi! gnutls-3.2.4 started using the header error.h, at least in certtool-common.c. certtool-common.c:40:19: fatal error: error.h: No such file or directory I don't know on which systems this exists, but it doesn't at least on NetBSD. Please continue using fprintf instead :) Thanks, Thomas From tim.ruehsen at gmx.de Fri Sep 6 12:52:15 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 06 Sep 2013 12:52:15 +0200 Subject: [gnutls-devel] gnutls-cli and invoke-gnutls-cli.texi disagree Message-ID: <18632590.Rje6pOzYJO@blitz-lx> Hi, regarding GnuTLS 3.2.4: The docs (invoke-gnutls-cli.texi) say Cipher suites for SECURE192 TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2 TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2e TLS1.2 TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2 TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2 TLS_DHE_DSS_AES_256_CBC_SHA256 0x00, 0x6a TLS1.2 TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2 while the invokation of 'gnutls-cli --priority SECURE192 -l' says: Cipher suites for SECURE192 TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2 TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2 TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2 TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2 TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2 TLS_DHE_DSS_AES_256_CBC_SHA256 0x00, 0x6a TLS1.2 Shouldn't the DHE key exchange be preferred to RSA, like the docs say ? If I understood it correctly, DHE is more secure in means of 'Perfect Forward Security'. Could someone bring some light in here ? Regards, Tim From nmav at gnutls.org Sat Sep 7 17:13:08 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 07 Sep 2013 17:13:08 +0200 Subject: [gnutls-devel] gnutls-cli and invoke-gnutls-cli.texi disagree In-Reply-To: <18632590.Rje6pOzYJO@blitz-lx> References: <18632590.Rje6pOzYJO@blitz-lx> Message-ID: <522B4284.7070406@gnutls.org> On 09/06/2013 12:52 PM, Tim Ruehsen wrote: > Hi, > > regarding GnuTLS 3.2.4: > > The docs (invoke-gnutls-cli.texi) say > Cipher suites for SECURE192 > TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2 > TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2e TLS1.2 > TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2 > TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2 > TLS_DHE_DSS_AES_256_CBC_SHA256 0x00, 0x6a TLS1.2 > TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2 > > while the invokation of 'gnutls-cli --priority SECURE192 -l' > says: > Cipher suites for SECURE192 > TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2 > TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2 > TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2 > TLS_RSA_AES_256_CBC_SHA256 0x00, 0x3d TLS1.2 > TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2 > TLS_DHE_DSS_AES_256_CBC_SHA256 0x00, 0x6a TLS1.2 > > Shouldn't the DHE key exchange be preferred to RSA, like the docs say ? It seems there is a discrepancy there. They are automatically generated so they need to be regenerated. > If I understood it correctly, DHE is more secure in means of 'Perfect Forward > Security'. > Could someone bring some light in here ? You are correct. However, in the latest versions I am pushing for a combination of security _and_ compatibility (which isn't an easy task). The DHE ciphersuites are unfortunately quite bad in respect to compatibility as any insecure parameters can only be rejected by terminating the connection. Since there are several servers in the Internet that send insecure parameters (e.g. of 512 bits), negotiating RSA over DHE is a good compromise (given that we support ECDHE which has priority over RSA). Thus we go for perfect forward secrecy with the well-behaved ECDHE, and fallback to RSA otherwise. regards, Nikos From ametzler at bebt.de Sun Sep 8 18:58:52 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 8 Sep 2013 18:58:52 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) Message-ID: <20130908165852.GD3256@downhill.g.la> Hello, gnutls 3.2.4 guile bindings are miscompiled by "make -j3" and greater, the testsuite catches the error. On my system (Dualcore, no Hyper-threading) -j3 fails occassionally, while greater values fail more reliably. -j2 /seems/ to work. This is probably not a new bug, I have only just found it by allowing Debian autobuilders to try parallel building. 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 tobias.polzer at fau.de Tue Sep 10 18:09:33 2013 From: tobias.polzer at fau.de (Tobias Polzer) Date: Tue, 10 Sep 2013 18:09:33 +0200 Subject: [gnutls-devel] [PATCH] Fixed a typo in the documentation Message-ID: <1378829373-10633-1-git-send-email-tobias.polzer@fau.de> Fixed a typo in the documentation for gnutls_srp_set_server_credentials_function. --- lib/gnutls_srp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/gnutls_srp.c b/lib/gnutls_srp.c index 26623e1..8707b87 100644 --- a/lib/gnutls_srp.c +++ b/lib/gnutls_srp.c @@ -574,8 +574,8 @@ gnutls_srp_set_server_credentials_file (gnutls_srp_server_credentials_t res, * SRP credentials. The callback's function form is: * * int (*callback)(gnutls_session_t, const char* username, - * gnutls_datum_t* salt, gnutls_datum_t *verifier, gnutls_datum_t* g, - * gnutls_datum_t* n); + * gnutls_datum_t* salt, gnutls_datum_t *verifier, gnutls_datum_t* generator, + * gnutls_datum_t* prime); * * @username contains the actual username. * The @salt, @verifier, @generator and @prime must be filled -- 1.8.4.rc3 From nmav at gnutls.org Tue Sep 10 21:46:26 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 10 Sep 2013 21:46:26 +0200 Subject: [gnutls-devel] [PATCH] Fixed a typo in the documentation In-Reply-To: <1378829373-10633-1-git-send-email-tobias.polzer@fau.de> References: <1378829373-10633-1-git-send-email-tobias.polzer@fau.de> Message-ID: <522F7712.9000203@gnutls.org> On 09/10/2013 06:09 PM, Tobias Polzer wrote: > Fixed a typo in the documentation for > gnutls_srp_set_server_credentials_function. Applied. Thank you. From ludo at gnu.org Fri Sep 13 15:19:59 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 13 Sep 2013 15:19:59 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <20130908165852.GD3256@downhill.g.la> (Andreas Metzler's message of "Sun, 8 Sep 2013 18:58:52 +0200") References: <20130908165852.GD3256@downhill.g.la> Message-ID: <87wqmk270g.fsf@gnu.org> Hi Andreas, Andreas Metzler scribes: > gnutls 3.2.4 guile bindings are miscompiled by "make -j3" and greater, > the testsuite catches the error. On my system (Dualcore, no > Hyper-threading) -j3 fails occassionally, while greater values fail > more reliably. -j2 /seems/ to work. Commit 330995a920037b6030ec0282b51dde3f8b493cad (which is in 3.2.4) fixed a similar problem. I just tried with both Guile 2.0 and 1.8 and cannot reproduce the issue. Could you post the build log and a GDB backtrace for the failing test(s)? TIA, Ludo?. From ametzler at bebt.de Fri Sep 13 18:29:50 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 13 Sep 2013 18:29:50 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87wqmk270g.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> Message-ID: <20130913162950.GA3267@downhill.g.la> On 2013-09-13 Ludovic Court?s wrote: > Andreas Metzler scribes: >> gnutls 3.2.4 guile bindings are miscompiled by "make -j3" and greater, >> the testsuite catches the error. On my system (Dualcore, no >> Hyper-threading) -j3 fails occassionally, while greater values fail >> more reliably. -j2 /seems/ to work. > Commit 330995a920037b6030ec0282b51dde3f8b493cad (which is in 3.2.4) > fixed a similar problem. > I just tried with both Guile 2.0 and 1.8 and cannot reproduce the issue. > Could you post the build log and a GDB backtrace for the failing test(s)? [...] Build log is e.g. here: https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.2.4-3&stamp=1378651617 https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=powerpc&ver=3.2.4-3&stamp=1378653753 Can you really not reproduce this with make -j8 && make -j8 check ? FWIW in Debian I have worked around this by adding .NOTPARALLEL: to guile/{,*}/Makefile* cu Andreas From ludo at gnu.org Fri Sep 13 23:50:51 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 13 Sep 2013 23:50:51 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <20130913162950.GA3267@downhill.g.la> (Andreas Metzler's message of "Fri, 13 Sep 2013 18:29:50 +0200") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> Message-ID: <87hadov1ac.fsf@gnu.org> Andreas Metzler skribis: > On 2013-09-13 Ludovic Court?s wrote: >> Andreas Metzler scribes: > >>> gnutls 3.2.4 guile bindings are miscompiled by "make -j3" and greater, >>> the testsuite catches the error. On my system (Dualcore, no >>> Hyper-threading) -j3 fails occassionally, while greater values fail >>> more reliably. -j2 /seems/ to work. > >> Commit 330995a920037b6030ec0282b51dde3f8b493cad (which is in 3.2.4) >> fixed a similar problem. > >> I just tried with both Guile 2.0 and 1.8 and cannot reproduce the issue. > >> Could you post the build log and a GDB backtrace for the failing test(s)? > [...] > > Build log is e.g. here: > https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.2.4-3&stamp=1378651617 > https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=powerpc&ver=3.2.4-3&stamp=1378653753 Could you try this: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 510 bytes Desc: not available URL: -------------- next part -------------- I just noticed this (info "(make) Suffix Rules"): Suffix rules cannot have any prerequisites of their own. If they have any, they are treated as normal files with funny names, not as suffix rules. Thus, the rule: .c.o: foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< tells how to make the file `.c.o' from the prerequisite file `foo.h', and is not at all like the pattern rule: %.o: %.c foo.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< which tells how to make `.o' files from `.c' files, and makes all `.o' files using this pattern rule also depend on `foo.h'. That means the fix mentioned above must have been ineffective... Thanks, Ludo?. From eliz at gnu.org Sat Sep 14 09:02:02 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Sat, 14 Sep 2013 10:02:02 +0300 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87hadov1ac.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> Message-ID: <83bo3vhonp.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Date: Fri, 13 Sep 2013 23:50:51 +0200 > > Could you try this: > > diff --git a/guile/src/Makefile.am b/guile/src/Makefile.am > index 1077502..7dedd41 100644 > --- a/guile/src/Makefile.am > +++ b/guile/src/Makefile.am > @@ -102,7 +102,7 @@ priorities.i.c: $(srcdir)/make-session-priorities.scm > snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ > $(CFLAGS) $(guile_gnutls_v_2_la_CFLAGS) > > -.c.x: $(GENERATED_BINDINGS) > +%.x: %.c $(GENERATED_BINDINGS) > $(guile_snarf) -o $@ $< $(snarfcppopts) > This requires GNU Make, doesn't it? > I just noticed this (info "(make) Suffix Rules"): > > Suffix rules cannot have any prerequisites of their own. If they > have any, they are treated as normal files with funny names, not as > suffix rules. The usual way of working around this is to have separate dependencies for the *.c files. From ludo at gnu.org Sat Sep 14 14:32:04 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sat, 14 Sep 2013 14:32:04 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <83bo3vhonp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Sep 2013 10:02:02 +0300") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> Message-ID: <87wqmjshx7.fsf@gnu.org> Eli Zaretskii skribis: >> From: ludo at gnu.org (Ludovic Court?s) >> Date: Fri, 13 Sep 2013 23:50:51 +0200 >> >> Could you try this: >> >> diff --git a/guile/src/Makefile.am b/guile/src/Makefile.am >> index 1077502..7dedd41 100644 >> --- a/guile/src/Makefile.am >> +++ b/guile/src/Makefile.am >> @@ -102,7 +102,7 @@ priorities.i.c: $(srcdir)/make-session-priorities.scm >> snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ >> $(CFLAGS) $(guile_gnutls_v_2_la_CFLAGS) >> >> -.c.x: $(GENERATED_BINDINGS) >> +%.x: %.c $(GENERATED_BINDINGS) >> $(guile_snarf) -o $@ $< $(snarfcppopts) >> > > This requires GNU Make, doesn't it? Yes, which was not the case until this change. (I?m not sure if GnuTLS is still developed with make portability in mind, though.) >> I just noticed this (info "(make) Suffix Rules"): >> >> Suffix rules cannot have any prerequisites of their own. If they >> have any, they are treated as normal files with funny names, not as >> suffix rules. > > The usual way of working around this is to have separate dependencies > for the *.c files. OK, so if Andreas confirms that it works as expected, I?ll do it this way. BTW, do you know if Make?s behavior in this regard changed in 3.82? Because clearly, Make doesn?t treat .c.x as a ?funny file name? here. Ludo?. From eliz at gnu.org Sat Sep 14 15:19:20 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Sat, 14 Sep 2013 16:19:20 +0300 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87wqmjshx7.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> Message-ID: <83wqmjfsmf.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Cc: gnutls-devel at lists.gnutls.org > Date: Sat, 14 Sep 2013 14:32:04 +0200 > > >> I just noticed this (info "(make) Suffix Rules"): > >> > >> Suffix rules cannot have any prerequisites of their own. If they > >> have any, they are treated as normal files with funny names, not as > >> suffix rules. > > > > The usual way of working around this is to have separate dependencies > > for the *.c files. > > OK, so if Andreas confirms that it works as expected, I?ll do it this way. > > BTW, do you know if Make?s behavior in this regard changed in 3.82? I don't think so. > Because clearly, Make doesn?t treat .c.x as a ?funny file name? here. How do you see that? From ludo at gnu.org Sat Sep 14 15:34:17 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sat, 14 Sep 2013 15:34:17 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <83wqmjfsmf.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Sep 2013 16:19:20 +0300") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> <83wqmjfsmf.fsf@gnu.org> Message-ID: <87fvt7plwm.fsf@gnu.org> Eli Zaretskii skribis: >> From: ludo at gnu.org (Ludovic Court?s) >> Cc: gnutls-devel at lists.gnutls.org >> Date: Sat, 14 Sep 2013 14:32:04 +0200 >> >> >> I just noticed this (info "(make) Suffix Rules"): >> >> >> >> Suffix rules cannot have any prerequisites of their own. If they >> >> have any, they are treated as normal files with funny names, not as >> >> suffix rules. [...] >> Because clearly, Make doesn?t treat .c.x as a ?funny file name? here. > > How do you see that? It can build the .x files. Ludo?. From eliz at gnu.org Sat Sep 14 15:47:38 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Sat, 14 Sep 2013 16:47:38 +0300 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87fvt7plwm.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> <83wqmjfsmf.fsf@gnu.org> <87fvt7plwm.fsf@gnu.org> Message-ID: <83six7frb9.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Cc: gnutls-devel at lists.gnutls.org > Date: Sat, 14 Sep 2013 15:34:17 +0200 > > >> Because clearly, Make doesn?t treat .c.x as a ?funny file name? here. > > > > How do you see that? > > It can build the .x files. Most probably due to another recipe. Run "make -d", and you will see what happens. From ametzler at bebt.de Sun Sep 15 14:06:25 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 15 Sep 2013 14:06:25 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87hadov1ac.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> Message-ID: <20130915120625.GA3247@downhill.g.la> On 2013-09-13 Ludovic Court?s wrote: [...] > Could you try this: [...] Seems to work for me. Thanks. cu Andreas From ludo at gnu.org Sun Sep 15 23:27:12 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sun, 15 Sep 2013 23:27:12 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <83six7frb9.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Sep 2013 16:47:38 +0300") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> <83wqmjfsmf.fsf@gnu.org> <87fvt7plwm.fsf@gnu.org> <83six7frb9.fsf@gnu.org> Message-ID: <87six5kc7j.fsf@gnu.org> Eli Zaretskii skribis: >> From: ludo at gnu.org (Ludovic Court?s) >> Cc: gnutls-devel at lists.gnutls.org >> Date: Sat, 14 Sep 2013 15:34:17 +0200 >> >> >> Because clearly, Make doesn?t treat .c.x as a ?funny file name? here. >> > >> > How do you see that? >> >> It can build the .x files. > > Most probably due to another recipe. Run "make -d", and you will see > what happens. Here?s what I get: --8<---------------cut here---------------start------------->8--- Considering target file `core.x'. File `core.x' does not exist. Looking for an implicit rule for `core.x'. Trying pattern rule with stem `core'. Trying implicit prerequisite `core.c'. Found an implicit rule for `core.x'. Considering target file `core.c'. [...] Finished prerequisites of target file `core.x'. Must remake target `core.x'. Invoking recipe from Makefile:1685 to update target `core.x'. /home/ludo/src/guix/gnutls-3.2.4/test/bin/guile-snarf -o core.x core.c -DHAVE_CONFIG_H -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -g -O2 -Wno-strict-prototypes -I../../gl -I../../gl -I/nix/store/zjwxxa719d1nnr68h5iha1kcf07ls32y-guile-1.8.8/include -pthread Successfully remade target file `core.x'. --8<---------------cut here---------------end--------------->8--- So clearly it?s picking up the right recipe. Andreas: what version of GNU Make did you use? Thanks, Ludo?. From ludo at gnu.org Sun Sep 15 23:34:35 2013 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Sun, 15 Sep 2013 23:34:35 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <20130915120625.GA3247@downhill.g.la> (Andreas Metzler's message of "Sun, 15 Sep 2013 14:06:25 +0200") References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <20130915120625.GA3247@downhill.g.la> Message-ID: <87ob7tkbv8.fsf@gnu.org> Andreas Metzler skribis: > On 2013-09-13 Ludovic Court?s wrote: > [...] >> Could you try this: > [...] > > Seems to work for me. Thanks. Thanks, pushed as 0d34b03. Nikos: could you cherry-pick that patch on the relevant branches? TIA, Ludo?. From patrick at scnv.net Sun Sep 15 23:54:28 2013 From: patrick at scnv.net (Patrick) Date: Sun, 15 Sep 2013 14:54:28 -0700 Subject: [gnutls-devel] GnuTLS PHP Extension Message-ID: <680F2441-D49E-4A32-9510-8261CB187A6D@scnv.net> Is there any interest in a PHP extension for GnuTLS. As far as I can tell the OpenSSL extension is very limited, without stream support, so you can't actually pass any traffic with it. I have a prototype GnuTLS extensions working with about 30 functions. Thank you, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4130 bytes Desc: not available URL: From eliz at gnu.org Mon Sep 16 07:48:58 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 16 Sep 2013 08:48:58 +0300 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87six5kc7j.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> <83wqmjfsmf.fsf@gnu.org> <87fvt7plwm.fsf@gnu.org> <83six7frb9.fsf@gnu.org> <87six5kc7j.fsf@gnu.org> Message-ID: <83a9jdqpth.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Cc: gnutls-devel at lists.gnutls.org > Date: Sun, 15 Sep 2013 23:27:12 +0200 > > --8<---------------cut here---------------start------------->8--- > Considering target file `core.x'. > File `core.x' does not exist. > Looking for an implicit rule for `core.x'. > Trying pattern rule with stem `core'. > Trying implicit prerequisite `core.c'. > Found an implicit rule for `core.x'. > Considering target file `core.c'. > > [...] > > Finished prerequisites of target file `core.x'. > Must remake target `core.x'. > Invoking recipe from Makefile:1685 to update target `core.x'. > /home/ludo/src/guix/gnutls-3.2.4/test/bin/guile-snarf -o core.x core.c -DHAVE_CONFIG_H -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -g -O2 -Wno-strict-prototypes -I../../gl -I../../gl -I/nix/store/zjwxxa719d1nnr68h5iha1kcf07ls32y-guile-1.8.8/include -pthread > Successfully remade target file `core.x'. > --8<---------------cut here---------------end--------------->8--- > > So clearly it?s picking up the right recipe. I asked about this on the GNU Make list. From ametzler at bebt.de Mon Sep 16 18:11:07 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 16 Sep 2013 18:11:07 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87six5kc7j.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <83bo3vhonp.fsf@gnu.org> <87wqmjshx7.fsf@gnu.org> <83wqmjfsmf.fsf@gnu.org> <87fvt7plwm.fsf@gnu.org> <83six7frb9.fsf@gnu.org> <87six5kc7j.fsf@gnu.org> Message-ID: <20130916161107.GA3414@downhill.g.la> On 2013-09-15 Ludovic Court?s wrote: [...] > Andreas: what version of GNU Make did you use? GNU Make 3.81 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Tue Sep 17 00:19:43 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Sep 2013 00:19:43 +0200 Subject: [gnutls-devel] -jX broken for X > 2 (in guile) In-Reply-To: <87ob7tkbv8.fsf@gnu.org> References: <20130908165852.GD3256@downhill.g.la> <87wqmk270g.fsf@gnu.org> <20130913162950.GA3267@downhill.g.la> <87hadov1ac.fsf@gnu.org> <20130915120625.GA3247@downhill.g.la> <87ob7tkbv8.fsf@gnu.org> Message-ID: <523783FF.5050208@gnutls.org> On 09/15/2013 11:34 PM, Ludovic Court?s wrote: > Andreas Metzler skribis: > >> On 2013-09-13 Ludovic Court?s wrote: >> [...] >>> Could you try this: >> [...] >> >> Seems to work for me. Thanks. > > Thanks, pushed as 0d34b03. > > Nikos: could you cherry-pick that patch on the relevant branches? Applied, thank you. Nikos From nmav at gnutls.org Tue Sep 17 11:07:36 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Sep 2013 11:07:36 +0200 Subject: [gnutls-devel] GnuTLS PHP Extension In-Reply-To: <680F2441-D49E-4A32-9510-8261CB187A6D@scnv.net> References: <680F2441-D49E-4A32-9510-8261CB187A6D@scnv.net> Message-ID: <52381BD8.6040703@gnutls.org> On 09/15/2013 11:54 PM, Patrick wrote: > Is there any interest in a PHP extension for GnuTLS. As far as I can tell the OpenSSL > extension is very limited, without stream support, so you can't actually pass any > traffic with it. > I have a prototype GnuTLS extensions working with about 30 functions. Hello Patrick, Do you have some website setup on that? I could link on that from the downloads page so anyone interested could find it and/or help. regards, Nikos From nmav at gnutls.org Sun Sep 22 23:12:11 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Sep 2013 23:12:11 +0200 Subject: [gnutls-devel] inline command support in gnutls-cli In-Reply-To: References: Message-ID: <523F5D2B.9090408@gnutls.org> On 09/19/2013 07:09 PM, Raj Raman wrote: > Hi Nikos, > > I would like to add infrastructure support in gnutls-cli for it to support > inline commands. The comments in the file inline_cmds.h (below) describes > this facility. We found this especially useful to test session resumption > and session renegotiation with HTTPS servers (or MITM devices) that support > HTTP persistence, since a single secure connection can support multiple > HTTP requests. The implementation makes no assumptions on contextual > boundary of TCP data. The existing behavior of command line options ?-r? > and ?-e? remains unchanged. Please find the relevant description and patch > in the attachment. Hello Raj, Thank you, the idea looks nice. What I am concerned is whether the commands used for cli are meaningful in some server. Would it make sense to have an additional parameter to specify an alternative prefix for the commands? regards, Nikos From rajramanca at gmail.com Tue Sep 24 01:08:14 2013 From: rajramanca at gmail.com (Raj Raman) Date: Mon, 23 Sep 2013 16:08:14 -0700 Subject: [gnutls-devel] inline command support in gnutls-cli In-Reply-To: <523F5D2B.9090408@gnutls.org> References: <523F5D2B.9090408@gnutls.org> Message-ID: Hi Nikos, The inline commands being invoked from gnutls-cli, as currently implemented, will be consumed at the client by the gnutls cli parser and subsequent action will be performed by the client. These inline commands will not be forwarded to the server. Given that these inline commands are consumed locally at the client invoking the gnutls-cli, I am not sure I fully understand your concern w.r.t server. If your concern is that having inline commands like ^resume^ or ^renegotiate^ can lead to confusion as this functionality/command could exist in the server as well, I could change ^resume^ and ^renegotiate^ to ^client-resume^ and ^client-renegotiate^ respectively. If you think we should have flexibility in using a prefix, via an additional parameter, instead of hard-coding ^, I can definitely look into adding this. I will wait for your feedback. Sorry if I misunderstood your point. Thanks Raj PS: copying comments from an earlier email to provide more context to others. * The inline commands is a facility that can be used optionally * when --inline-commands is set during invocation of gnutls-cli * to send inline commands at any time while a secure connection * between the client and server is active. This is especially * useful when the HTTPS connection is (HTTP) persistent - * inline commands can be issued between HTTP requests, ex: GET. * session renegotiation and session resumption can be issued * inline between GET requests. * * Following inline commands are currently supported: * ^resume^ - perform session resumption (similar to option -r) * ^renegotiate^ - perform session renegotiation (similar to option -e) On Sun, Sep 22, 2013 at 2:12 PM, Nikos Mavrogiannopoulos wrote: > On 09/19/2013 07:09 PM, Raj Raman wrote: > > Hi Nikos, > > > > I would like to add infrastructure support in gnutls-cli for it to > support > > inline commands. The comments in the file inline_cmds.h (below) describes > > this facility. We found this especially useful to test session resumption > > and session renegotiation with HTTPS servers (or MITM devices) that > support > > HTTP persistence, since a single secure connection can support multiple > > HTTP requests. The implementation makes no assumptions on contextual > > boundary of TCP data. The existing behavior of command line options ?-r? > > and ?-e? remains unchanged. Please find the relevant description and > patch > > in the attachment. > > Hello Raj, > Thank you, the idea looks nice. What I am concerned is whether the > commands used for cli are meaningful in some server. Would it make sense > to have an additional parameter to specify an alternative prefix for the > commands? > > regards, > Nikos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Sep 24 10:33:50 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 Sep 2013 10:33:50 +0200 Subject: [gnutls-devel] inline command support in gnutls-cli In-Reply-To: References: <523F5D2B.9090408@gnutls.org> Message-ID: <52414E6E.9040802@gnutls.org> On 09/24/2013 01:08 AM, Raj Raman wrote: > Hi Nikos, > If your concern is that having inline commands like ^resume^ or > ^renegotiate^ can lead to confusion as this functionality/command could > exist in the server as well, I could change ^resume^ and ^renegotiate^ to > ^client-resume^ and ^client-renegotiate^ respectively. If you think we > should have flexibility in using a prefix, via an additional parameter, > instead of hard-coding ^, I can definitely look into adding this. Hello Raj, Indeed that was my point. Thanks, Nikos