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: <C01FD002-11F1-4EBB-AF35-6D13D166AABC@gmail.com>

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: <C01FD002-11F1-4EBB-AF35-6D13D166AABC@gmail.com>
References: <C01FD002-11F1-4EBB-AF35-6D13D166AABC@gmail.com>
Message-ID: <CAJU7zaLcWvjEiNOT+kzCTezoNVDsWUtNGxd8yP=sSMR_PZKmig@mail.gmail.com>

On Sun, Sep 1, 2013 at 10:58 PM, Marius Schamschula
<mschamschula at gmail.com> 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 <ametzler at bebt.de> 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 <ludo at gnu.org> wrote:
> Andreas Metzler <ametzler at bebt.de> 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 <ametzler at bebt.de> skribis:

> On 2013-09-13 Ludovic Court?s <ludo at gnu.org> wrote:
>> Andreas Metzler <ametzler at bebt.de> 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: </pipermail/attachments/20130913/cf63d61f/attachment.bin>
-------------- 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 <eliz at gnu.org> 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 <eliz at gnu.org> 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 <ludo at gnu.org> 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 <eliz at gnu.org> 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 <ametzler at bebt.de> skribis:

> On 2013-09-13 Ludovic Court?s <ludo at gnu.org> 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: </pipermail/attachments/20130915/27fca4ac/attachment.bin>

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 <ludo at gnu.org> 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 <ametzler at bebt.de> skribis:
> 
>> On 2013-09-13 Ludovic Court?s <ludo at gnu.org> 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: <CAM0uNfySO-vNO65vroq4J8vuckosf-iz=B-xHtNyL9VF9Rk=AA@mail.gmail.com>
References: <CAM0uNfySO-vNO65vroq4J8vuckosf-iz=B-xHtNyL9VF9Rk=AA@mail.gmail.com>
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: <CAM0uNfySO-vNO65vroq4J8vuckosf-iz=B-xHtNyL9VF9Rk=AA@mail.gmail.com>
 <523F5D2B.9090408@gnutls.org>
Message-ID: <CAM0uNfw_6ALO6J=Axq9EN2EPabaKqUbkURDMox1sONzn=tp9tw@mail.gmail.com>

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 <nmav at gnutls.org>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: </pipermail/attachments/20130923/e1013c4a/attachment.html>

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: <CAM0uNfw_6ALO6J=Axq9EN2EPabaKqUbkURDMox1sONzn=tp9tw@mail.gmail.com>
References: <CAM0uNfySO-vNO65vroq4J8vuckosf-iz=B-xHtNyL9VF9Rk=AA@mail.gmail.com>
 <523F5D2B.9090408@gnutls.org>
 <CAM0uNfw_6ALO6J=Axq9EN2EPabaKqUbkURDMox1sONzn=tp9tw@mail.gmail.com>
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