From ludo at chbouib.org  Fri Jun  1 01:17:07 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 01 Jun 2007 01:17:07 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
Message-ID: <87vee8d1n0.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Thanks!  I accidentally used 'git pull' on your repository (I think I
> wanted to use 'git fetch' instead), so your changes have now been
> installed!

How fun!  ;-)

Anyway, sorry for all the mess that you ended up merging.

> * guile/ isn't part of SUBDIRS in top-level Makefile.am so it is never
>   built...

Done.

> * building in the directory fails:

Fixed (I had a dangling copy of the `modules' directory at the top-level
which is why I hadn't noticed it.  Sigh.).

> * configure.ac contains:
>
>    AC_PATH_PROG([guile_snarf], [guile-snarf], [not-found])
>    if test "x$guile_snarf" = "xnot-found"; then
>       AC_MSG_ERROR([`guile-snarf' not found.  Please install Guile 1.8.x or later.])
>    fi
>
>   This seems unsafe.  Could you change this so that if guile-snarf is
>   not available, the guile bindings are disabled rather than aborting
>   the build?

Done.

> * Automake complains:
>
> doc/Makefile.am:131: `%'-style pattern rules are a GNU make extension
> doc/Makefile.am:139: `%'-style pattern rules are a GNU make extension
>
> We don't want any GNU make extensions.  Hard-coding the rules for the
> two files would be one solution.

Done.

> * The manual's @node's were heavily changed, which causes problems.  You
>   shouldn't need these modifications if you use the latest texinfo.  I
>   reverted this stuff.

I think I routinely hit "Update all nodes" in Emacs, hence those
changes.  Sorry.

> Another problem:
>
> ./configure: line 7459: GUILE_PROGS: command not found
> ./configure: line 7460: GUILE_FLAGS: command not found
>
> The m4 files that define these macros need to be included in GnuTLS, I
> suggest to place them in m4/.

That's from `guile.m4' from Guile 1.8 which should be available at
`/usr/share/aclocal' (or similar).  It's only needed by those who modify
`configure.in'.  Should we really include it?


The changes above are available in my repository.

There are still a couple of minor glitches:

  * Code in `guile/src' doesn't want to be compiled with
    `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
    doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
    have to remove `-Wstrict-prototypes' at the project level (i.e, in
    `configure.in'), and add it to `CFLAGS' in sub-directories where it
    makes sense.

  * The "function index" of the manual mixes Scheme procedures and C
    functions.  In theory it might be possible to create separate
    indices but since `@deffn' automatically adds functions to the
    function index, it would not be convenient.


For some reason, `make' now fails here in `doc/reference':

  $ make -C doc/reference/
  make: Entering directory `/home/ludo/src/gnutls/doc/reference'
  gtk-doc: Scanning header files
  [...]
  gtk-doc: Compiling scanner
  gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
  [...]

Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
Unfortunately, I wasn't able to pinpoint the root of the problem.
Re-running `autoreconf' and `configure' didn't help.  Any hint?

Thanks,
Ludovic.



From simon at josefsson.org  Fri Jun  1 13:55:25 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Jun 2007 13:55:25 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87vee8d1n0.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Fri, 01 Jun 2007 01:17:07 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org>
Message-ID: <878xb3lwia.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Thanks!  I accidentally used 'git pull' on your repository (I think I
>> wanted to use 'git fetch' instead), so your changes have now been
>> installed!
>
> How fun!  ;-)
>
> Anyway, sorry for all the mess that you ended up merging.

Ok, this time I used 'git-pull --no-commit' but it seems to have
committed everything anyway!

jas at mocca:~/src/gnutls$ gitco
jas at mocca:~/src/gnutls$ git-pull --no-commit http://www.laas.fr/~lcourtes/software/gnutls.git
Fetching HEAD from http://www.laas.fr/~lcourtes/software/gnutls.git using http
walk ac2c37fd6a7820ebc10182b02d5d9e9d075981d9
walk f469cfce51318df3b629d9af210ce4b4e587fac0
walk 76b313969e72860092441f54cc9a4f52c8eaba57
walk be1614e554969c35c5a58fdf0deff4b065cde1fe
Updating faa8f90..ac2c37f
Fast forward
 Makefile.am                                    |    4 ++
 configure.in                                   |   51 ++++++++++++------------
 doc/Makefile.am                                |   17 ++++++-
 doc/extract-guile-c-doc.scm                    |   38 ++++++++---------
 guile/modules/system/documentation/c-snarf.scm |    5 +-
 guile/src/Makefile.am                          |    7 +--
 guile/src/core.c                               |    2 +-
 guile/src/errors.c                             |    2 +-
 guile/src/extra.c                              |    2 +-
 9 files changed, 71 insertions(+), 57 deletions(-)
jas at mocca:~/src/gnutls$ gitco
jas at mocca:~/src/gnutls$ git-commit
nothing to commit
jas at mocca:~/src/gnutls$

I reviewed your changes manually, but I'm really starting to wonder what
git command I should be using to review the changes 'git-pull' from
someone else's repository will actually pull in.

In the future, do you want to develop things in your git repository, and
ask me to pull things in when ready?  I think that would work well, if I
can figure out which command I should be using for reviewing the changes
before committing them.

>> * configure.ac contains:
>>
>>    AC_PATH_PROG([guile_snarf], [guile-snarf], [not-found])
>>    if test "x$guile_snarf" = "xnot-found"; then
>>       AC_MSG_ERROR([`guile-snarf' not found.  Please install Guile 1.8.x or later.])
>>    fi
>>
>>   This seems unsafe.  Could you change this so that if guile-snarf is
>>   not available, the guile bindings are disabled rather than aborting
>>   the build?
>
> Done.

It now says:

if test "x$opt_guile_bindings" = "xyes"; then
   GUILE_PROGS
   GUILE_FLAGS
   AC_PATH_PROG([guile_snarf], [guile-snarf])
   if test "x$guile_snarf" = "x"; then
      AC_MSG_WARN([`guile-snarf' from Guile 1.8 not found.  Guile bindings not built.])
      opt_guile_bindings=no
   else

Would it work to move GUILE_PROGS + GUILE_FLAGS down into the else-case?
This avoids some unnecessary checking if guile isn't going to be used
anyway, due to guile-snarf missing.

>> * The manual's @node's were heavily changed, which causes problems.  You
>>   shouldn't need these modifications if you use the latest texinfo.  I
>>   reverted this stuff.
>
> I think I routinely hit "Update all nodes" in Emacs, hence those
> changes.  Sorry.

That should probably be reported as a Emacs bug, I don't think it is
considered good practice to maintain such @node's anymore.  But I don't
know for sure.

>> Another problem:
>>
>> ./configure: line 7459: GUILE_PROGS: command not found
>> ./configure: line 7460: GUILE_FLAGS: command not found
>>
>> The m4 files that define these macros need to be included in GnuTLS, I
>> suggest to place them in m4/.
>
> That's from `guile.m4' from Guile 1.8 which should be available at
> `/usr/share/aclocal' (or similar).  It's only needed by those who modify
> `configure.in'.  Should we really include it?

Yes -- otherwise people who don't have guile.m4 on their systems will
get the above error when they build from CVS.  And we don't want to
require that guile is installed in order to bootstrap gnutls.

Compare this with including libgcrypt.m4, libtasn1.m4, gtk-doc.m4.
Building gnutls from CVS doesn't require that all of the tools are
installed (i.e., libtasn1 is optional, gtk-dock is optional), and
consequently building gnutls should not require files from those
packages.  If the files aren't available at build-time, the generated
tar-ball won't work correctly for end-users.  This happens on the daily
build machine now, since it doesn't have guile.m4: you probably can't
build gnutls with guile-features, because guile.m4 was not included into
the daily snapshot (and it is not picked up at user's build-time).

> The changes above are available in my repository.

Incorporated now...

> There are still a couple of minor glitches:
>
>   * Code in `guile/src' doesn't want to be compiled with
>     `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
>     doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>     have to remove `-Wstrict-prototypes' at the project level (i.e, in
>     `configure.in'), and add it to `CFLAGS' in sub-directories where it
>     makes sense.

Ouch.  What is the reason the code needs this?  Maybe we can fix that
problem instead.  It seems to build for me now, though, with warnings,
but I'd rather have warning messages than potentially hiding other
problems.

>   * The "function index" of the manual mixes Scheme procedures and C
>     functions.  In theory it might be possible to create separate
>     indices but since `@deffn' automatically adds functions to the
>     function index, it would not be convenient.

It may be possible to re-define the function index somehow, perhaps we
could ask on the texinfo list about this.  I think it would be cleaner
to have a separate C API index and Scheme API index.  Although it is not
important to fix this before the first releases.

> For some reason, `make' now fails here in `doc/reference':
>
>   $ make -C doc/reference/
>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>   gtk-doc: Scanning header files
>   [...]
>   gtk-doc: Compiling scanner
>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>   [...]
>
> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
> Unfortunately, I wasn't able to pinpoint the root of the problem.
> Re-running `autoreconf' and `configure' didn't help.  Any hint?

Hm, which gtk-doc-tools version are you using?

Btw, building fails in another way now:

make[3]: Entering directory `/home/jas/src/gnutls/guile/src'
/usr/bin/guile-snarf -o core.x core.c -DHAVE_CONFIG_H  -I.  -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -Wno-pointer-sign -pipe -I/usr/local/include  -I/usr/local/include
In file included from core.c:27:
enums.h:5:20: error: config.h: No such file or directory
make[3]: *** [core.x] Error 1
make[3]: Leaving directory `/home/jas/src/gnutls/guile/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jas/src/gnutls/guile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jas/src/gnutls'
make: *** [all] Error 2
jas at mocca:~/src/gnutls$

But I fixed this by adding a -I.

Thanks,
Simon


From ludovic.courtes at laas.fr  Fri Jun  1 14:29:59 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 01 Jun 2007 14:29:59 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
Message-ID: <87sl9bdfi0.fsf@laas.fr>

Hi,

Just a quick reply before I actually look into the details (either later
today or next week).

Simon Josefsson <simon at josefsson.org> writes:

> In the future, do you want to develop things in your git repository, and
> ask me to pull things in when ready?  I think that would work well, if I
> can figure out which command I should be using for reviewing the changes
> before committing them.

Yes, that's how we could do.  Alternatively, I could use
`git-format-patch' and send the resulting messages to the list but as I
said, that may introduce some undesirable overhead.

My understanding is that `git-fetch' allows remote changes to be fetched
locally without being actually integrated (and committed) locally.
Then, it should be possible to find the latest remote commit ID in
`.git/refs/remotes' and use that with `git-diff'.  And finally, one
should be able to `git-merge' to actually merge the changes locally.

This is a bit vague, and that's because I haven't actually tried it.  ;-)
I'll report back when I have better experience.

>>   * Code in `guile/src' doesn't want to be compiled with
>>     `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
>>     doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>>     have to remove `-Wstrict-prototypes' at the project level (i.e, in
>>     `configure.in'), and add it to `CFLAGS' in sub-directories where it
>>     makes sense.
>
> Ouch.  What is the reason the code needs this?  Maybe we can fix that
> problem instead.  It seems to build for me now, though, with warnings,
> but I'd rather have warning messages than potentially hiding other
> problems.

That's because Guile contains this declaration:

  SCM scm_c_define_subr (const char *name, long type, SCM (*fcn)());

This function allows C code to bind C function FCN to the Scheme level
under NAME.  It makes perfect sense to have FCN declared this way,
because FCN can have any number of arguments (its number of required,
optional and "rest" arguments are specified as part of TYPE).

I can't think of a better way to declare FCN.  Requiring users to cast
their functions to, e.g., `SCM (* fcn) (void)', is not an option.  At
any rate, should a fix be found for Guile, it won't be available until
the next Guile release.

I'll take care of the other issues you mentioned later on.

Thanks!

Ludovic.



From andrew.w.nosenko at gmail.com  Fri Jun  1 14:46:17 2007
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Fri, 1 Jun 2007 15:46:17 +0300
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <878xb3lwia.fsf@mocca.josefsson.org>
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
Message-ID: <6161f3180706010546p71395bc0laf07a15bb97085bd@mail.gmail.com>

On 6/1/07, Simon Josefsson <simon at josefsson.org> wrote:
> ludo at chbouib.org (Ludovic Court?s) writes:
> >> * configure.ac contains:
> >>
> >>    AC_PATH_PROG([guile_snarf], [guile-snarf], [not-found])
> >>    if test "x$guile_snarf" = "xnot-found"; then
> >>       AC_MSG_ERROR([`guile-snarf' not found.  Please install Guile 1.8.x or later.])
> >>    fi
> >>
> >>   This seems unsafe.  Could you change this so that if guile-snarf is
> >>   not available, the guile bindings are disabled rather than aborting
> >>   the build?
> >
> > Done.
>
> It now says:
>
> if test "x$opt_guile_bindings" = "xyes"; then
>    GUILE_PROGS
>    GUILE_FLAGS
>    AC_PATH_PROG([guile_snarf], [guile-snarf])
>    if test "x$guile_snarf" = "x"; then
>       AC_MSG_WARN([`guile-snarf' from Guile 1.8 not found.  Guile bindings not built.])
>       opt_guile_bindings=no
>    else
>
> Would it work to move GUILE_PROGS + GUILE_FLAGS down into the else-case?
> This avoids some unnecessary checking if guile isn't going to be used
> anyway, due to guile-snarf missing.

[skip]

> >> Another problem:
> >>
> >> ./configure: line 7459: GUILE_PROGS: command not found
> >> ./configure: line 7460: GUILE_FLAGS: command not found
> >>
> >> The m4 files that define these macros need to be included in GnuTLS, I
> >> suggest to place them in m4/.
> >
> > That's from `guile.m4' from Guile 1.8 which should be available at
> > `/usr/share/aclocal' (or similar).  It's only needed by those who modify
> > `configure.in'.  Should we really include it?
>
> Yes -- otherwise people who don't have guile.m4 on their systems will
> get the above error when they build from CVS.  And we don't want to
> require that guile is installed in order to bootstrap gnutls.

It's not a problem if GUILE_PROGS and GUILE_FLAGS will be moved to the
else-case as proposed above.  No guile-snarf -- no guile bindings and,
therefore, no GUILE_PROGS and GUILE_FLAGS on the execution path.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>


From simon at josefsson.org  Fri Jun  1 15:30:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Jun 2007 15:30:34 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87sl9bdfi0.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 01
	Jun 2007 14:29:59 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87sl9bdfi0.fsf@laas.fr>
Message-ID: <87zm3jiyyt.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Just a quick reply before I actually look into the details (either later
> today or next week).
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> In the future, do you want to develop things in your git repository, and
>> ask me to pull things in when ready?  I think that would work well, if I
>> can figure out which command I should be using for reviewing the changes
>> before committing them.
>
> Yes, that's how we could do.  Alternatively, I could use
> `git-format-patch' and send the resulting messages to the list but as I
> said, that may introduce some undesirable overhead.
>
> My understanding is that `git-fetch' allows remote changes to be fetched
> locally without being actually integrated (and committed) locally.
> Then, it should be possible to find the latest remote commit ID in
> `.git/refs/remotes' and use that with `git-diff'.  And finally, one
> should be able to `git-merge' to actually merge the changes locally.
>
> This is a bit vague, and that's because I haven't actually tried it.  ;-)
> I'll report back when I have better experience.

Once you have something in your public repository that I should merge,
I'll try it.

>>>   * Code in `guile/src' doesn't want to be compiled with
>>>     `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
>>>     doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>>>     have to remove `-Wstrict-prototypes' at the project level (i.e, in
>>>     `configure.in'), and add it to `CFLAGS' in sub-directories where it
>>>     makes sense.
>>
>> Ouch.  What is the reason the code needs this?  Maybe we can fix that
>> problem instead.  It seems to build for me now, though, with warnings,
>> but I'd rather have warning messages than potentially hiding other
>> problems.
>
> That's because Guile contains this declaration:
>
>   SCM scm_c_define_subr (const char *name, long type, SCM (*fcn)());
>
> This function allows C code to bind C function FCN to the Scheme level
> under NAME.  It makes perfect sense to have FCN declared this way,
> because FCN can have any number of arguments (its number of required,
> optional and "rest" arguments are specified as part of TYPE).
>
> I can't think of a better way to declare FCN.  Requiring users to cast
> their functions to, e.g., `SCM (* fcn) (void)', is not an option.  At
> any rate, should a fix be found for Guile, it won't be available until
> the next Guile release.

I can't think of a better solution right now.  Still, do the warnings
cause any real harm?  I'd rather not drop -Wstrict-prototypes if the
advantage of doing so would be to just hide some warnings.  Did you try
changing the order of -Wno-strict-prototypes to see if you really can't
negate the effect of the other parameter?

> I'll take care of the other issues you mentioned later on.

Thanks!

/Simon


From ludovic.courtes at laas.fr  Fri Jun  1 15:44:56 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 01 Jun 2007 15:44:56 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87sl9bdfi0.fsf@laas.fr> <87zm3jiyyt.fsf@mocca.josefsson.org>
Message-ID: <873b1bbxgn.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> That's because Guile contains this declaration:
>>
>>   SCM scm_c_define_subr (const char *name, long type, SCM (*fcn)());
>>
>> This function allows C code to bind C function FCN to the Scheme level
>> under NAME.  It makes perfect sense to have FCN declared this way,
>> because FCN can have any number of arguments (its number of required,
>> optional and "rest" arguments are specified as part of TYPE).
>>
>> I can't think of a better way to declare FCN.  Requiring users to cast
>> their functions to, e.g., `SCM (* fcn) (void)', is not an option.  At
>> any rate, should a fix be found for Guile, it won't be available until
>> the next Guile release.
>
> I can't think of a better solution right now.  Still, do the warnings
> cause any real harm?  I'd rather not drop -Wstrict-prototypes if the
> advantage of doing so would be to just hide some warnings.

No, the warnings don't cause any harm by themselves, but it's annoying
to get warnings for things that are intentional and harmless.

> Did you try changing the order of -Wno-strict-prototypes to see if you
> really can't negate the effect of the other parameter?

No I didn't, but it wouldn't be convenient.  Currently,
`guile/src/Makefile.am' adds `-Wno-strict-prototypes' to the
`libxxx_CFLAGS' but those are appended to `CFLAGS' rather than
prepended.

I'll try to see if I can hack around something else but I'm not very
hopeful...

Thanks,
Ludovic.



From simon at josefsson.org  Wed Jun  6 01:13:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 6 Jun 2007 01:13:13 +0200
Subject: [gnutls-dev] opencdk-0.6.1 vs. gnutls-1.6.3
In-Reply-To: <20070605205638.GE27312@danbala.tuwien.ac.at>
References: <20070605205638.GE27312@danbala.tuwien.ac.at>
Message-ID: <31FE2AAF-8CC5-4068-AE2D-8B8F0B64C317@josefsson.org>

Gnutls 1.6.x doesn't work with OpenCDK 0.6.x, you'll need OpenCDK  
0.5.x, or --enable-included-opencdk.  I am sorry for the problems,  
but the OpenCDK maintainer wanted to fix some things and that lead to  
API/ABI breaks.

/Simon

On 5 jun 2007, at 22.56, Thomas Klausner wrote:

> Hi!
>
> The latest release of opencdk, 0.6.1, breaks the compilation of the
> latest non-development release of gnutls, 1.6.3:
> gnutls_openpgp.c: In function 'openpgp_pk_to_gnutls_cert':
> gnutls_openpgp.c:294: warning: passing argument 4 of 'cdk_pk_get_mpi'
> makes integer from pointer without a cast
> gnutls_openpgp.c:294: error: too few arguments to function
> 'cdk_pk_get_mpi'
> gnutls_openpgp.c: In function '_gnutls_openpgp_raw_privkey_to_gkey':
> gnutls_openpgp.c:337: warning: assignment makes pointer from integer
> without a cast
> gnutls_openpgp.c:363: warning: passing argument 4 of 'cdk_pk_get_mpi'
> makes integer from pointer without a cast
> gnutls_openpgp.c:363: error: too few arguments to function
> 'cdk_pk_get_mpi'
> gnutls_openpgp.c:376: warning: passing argument 4 of 'cdk_sk_get_mpi'
> makes integer from pointer without a cast
> gnutls_openpgp.c:376: error: too few arguments to function
> 'cdk_sk_get_mpi'
> gnutls_openpgp.c: In function  
> 'gnutls_certificate_set_openpgp_key_mem':
> gnutls_openpgp.c:583: error: too few arguments to function
> 'cdk_stream_tmp_from_mem'
> gnutls_openpgp.c:678: error: too few arguments to function
> 'cdk_stream_tmp_from_mem'
> gnutls_openpgp.c: In function
> 'gnutls_certificate_set_openpgp_key_file':
> gnutls_openpgp.c:744: warning: passing argument 2 of
> 'read_binary_file' from incompatible pointer type
> gnutls_openpgp.c:751: warning: passing argument 2 of
> 'read_binary_file' from incompatible pointer type
> gnutls_openpgp.c: In function
> 'gnutls_certificate_set_openpgp_keyring_mem':
> gnutls_openpgp.c:944: error: too few arguments to function
> 'cdk_stream_tmp_from_mem'
>
> Is there a workaround, or is a new gnutls out very soon?
>  Thomas



From ludo at chbouib.org  Wed Jun  6 17:22:08 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 06 Jun 2007 17:22:08 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
Message-ID: <87abvdaz1b.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Would it work to move GUILE_PROGS + GUILE_FLAGS down into the else-case?

Done.

> Yes -- otherwise people who don't have guile.m4 on their systems will
> get the above error when they build from CVS.  And we don't want to
> require that guile is installed in order to bootstrap gnutls.

Agreed.  Done.

>> There are still a couple of minor glitches:
>>
>>   * Code in `guile/src' doesn't want to be compiled with
>>     `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
>>     doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>>     have to remove `-Wstrict-prototypes' at the project level (i.e, in
>>     `configure.in'), and add it to `CFLAGS' in sub-directories where it
>>     makes sense.
>
> Ouch.  What is the reason the code needs this?  Maybe we can fix that
> problem instead.  It seems to build for me now, though, with warnings,
> but I'd rather have warning messages than potentially hiding other
> problems.

I fixed this by tweaking `AM_CFLAGS' (see Git log for details, commit
befacfea1d24f2b6b43ecdf12a22f47b160f39b6).

> It may be possible to re-define the function index somehow, perhaps we
> could ask on the texinfo list about this.  I think it would be cleaner
> to have a separate C API index and Scheme API index.  Although it is not
> important to fix this before the first releases.

After reading `(texinfo.gz)Functions Commands' and related nodes, I
couldn't find a way to do this.  It seems that the `@def*' macros cannot
be instructed to use a specific index.

>> For some reason, `make' now fails here in `doc/reference':
>>
>>   $ make -C doc/reference/
>>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>>   gtk-doc: Scanning header files
>>   [...]
>>   gtk-doc: Compiling scanner
>>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>>   [...]
>>
>> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
>> Unfortunately, I wasn't able to pinpoint the root of the problem.
>> Re-running `autoreconf' and `configure' didn't help.  Any hint?
>
> Hm, which gtk-doc-tools version are you using?

I'm using 1.8-3 from Debian sid.  I still haven't found any way around
it.  :-(

> Btw, building fails in another way now:

[...]

> But I fixed this by adding a -I.

Perfect!  Again, sorry about that.

Hopefully, this is all looking better now.  Let me know if you notice
any other annoyance.

Thanks,
Ludovic.



From simon at josefsson.org  Fri Jun  8 13:41:50 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 13:41:50 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <873b1bbxgn.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 01
	Jun 2007 15:44:56 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87sl9bdfi0.fsf@laas.fr> <87zm3jiyyt.fsf@mocca.josefsson.org>
	<873b1bbxgn.fsf@laas.fr>
Message-ID: <873b123c75.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>
>>> That's because Guile contains this declaration:
>>>
>>>   SCM scm_c_define_subr (const char *name, long type, SCM (*fcn)());
>>>
>>> This function allows C code to bind C function FCN to the Scheme level
>>> under NAME.  It makes perfect sense to have FCN declared this way,
>>> because FCN can have any number of arguments (its number of required,
>>> optional and "rest" arguments are specified as part of TYPE).
>>>
>>> I can't think of a better way to declare FCN.  Requiring users to cast
>>> their functions to, e.g., `SCM (* fcn) (void)', is not an option.  At
>>> any rate, should a fix be found for Guile, it won't be available until
>>> the next Guile release.
>>
>> I can't think of a better solution right now.  Still, do the warnings
>> cause any real harm?  I'd rather not drop -Wstrict-prototypes if the
>> advantage of doing so would be to just hide some warnings.
>
> No, the warnings don't cause any harm by themselves, but it's annoying
> to get warnings for things that are intentional and harmless.

I think that either there actually are some cases were this usage will
cause problems (perhaps for '...' function prototypes?  Or perhaps the C
standard regards something in this as undefined, possibly function
pointers aren't type-compatible in general), or GCC should not have a
warning mechanism for it.  I'm leaning towards that there actually may
be some platform where this could cause problems, and that was what
prompted GCC to add this warning flag.

>> Did you try changing the order of -Wno-strict-prototypes to see if you
>> really can't negate the effect of the other parameter?
>
> No I didn't, but it wouldn't be convenient.  Currently,
> `guile/src/Makefile.am' adds `-Wno-strict-prototypes' to the
> `libxxx_CFLAGS' but those are appended to `CFLAGS' rather than
> prepended.
>
> I'll try to see if I can hack around something else but I'm not very
> hopeful...

I noticed you found a way.  Great!

/Simon


From simon at josefsson.org  Fri Jun  8 13:45:12 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 13:45:12 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87abvdaz1b.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 06 Jun 2007 17:22:08 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87abvdaz1b.fsf@chbouib.org>
Message-ID: <87y7iu1xh3.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

>>> There are still a couple of minor glitches:
>>>
>>>   * Code in `guile/src' doesn't want to be compiled with
>>>     `-Wstrict-prototypes'.  Since adding `-Wno-strict-prototypes'
>>>     doesn't annul the effect of `-Wstrict-prototypes', I'm afraid we'll
>>>     have to remove `-Wstrict-prototypes' at the project level (i.e, in
>>>     `configure.in'), and add it to `CFLAGS' in sub-directories where it
>>>     makes sense.
>>
>> Ouch.  What is the reason the code needs this?  Maybe we can fix that
>> problem instead.  It seems to build for me now, though, with warnings,
>> but I'd rather have warning messages than potentially hiding other
>> problems.
>
> I fixed this by tweaking `AM_CFLAGS' (see Git log for details, commit
> befacfea1d24f2b6b43ecdf12a22f47b160f39b6).

Let's see if I can manage to review patches before pulling them into the
repository this time...

>> It may be possible to re-define the function index somehow, perhaps we
>> could ask on the texinfo list about this.  I think it would be cleaner
>> to have a separate C API index and Scheme API index.  Although it is not
>> important to fix this before the first releases.
>
> After reading `(texinfo.gz)Functions Commands' and related nodes, I
> couldn't find a way to do this.  It seems that the `@def*' macros cannot
> be instructed to use a specific index.

I didn't find anything either.  Sigh.  I'll ask on the texinfo list.

>>> For some reason, `make' now fails here in `doc/reference':
>>>
>>>   $ make -C doc/reference/
>>>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>>>   gtk-doc: Scanning header files
>>>   [...]
>>>   gtk-doc: Compiling scanner
>>>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>>>   [...]
>>>
>>> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
>>> Unfortunately, I wasn't able to pinpoint the root of the problem.
>>> Re-running `autoreconf' and `configure' didn't help.  Any hint?
>>
>> Hm, which gtk-doc-tools version are you using?
>
> I'm using 1.8-3 from Debian sid.  I still haven't found any way around
> it.  :-(

Weird, I'm using the same version.  The file glib-object.h is in
libglib2.0-dev, does it help to install that package?  If so, I would
consider it a bug in gtk-doc-tools, it should depend on that package.

> Hopefully, this is all looking better now.  Let me know if you notice
> any other annoyance.

I'll see if I can make a release now, so we can get the guile stuff out
there for others to test.

/Simon


From simon at josefsson.org  Fri Jun  8 14:19:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 14:19:34 +0200
Subject: [gnutls-dev] I like git (was: Re: Starting Guile integration)
In-Reply-To: <87y7iu1xh3.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 08 Jun 2007 13:45:12 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87abvdaz1b.fsf@chbouib.org> <87y7iu1xh3.fsf@mocca.josefsson.org>
Message-ID: <87tzti1vvt.fsf_-_@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> I fixed this by tweaking `AM_CFLAGS' (see Git log for details, commit
>> befacfea1d24f2b6b43ecdf12a22f47b160f39b6).
>
> Let's see if I can manage to review patches before pulling them into the
> repository this time...

I'm so starting to like git.  I started by adding your repository as a
branch:

cg-branch-add guile http://www.laas.fr/~lcourtes/software/gnutls.git

Then I can update your stuff as easy as:

cg-fetch guile

I can review your changes by using:

git-log -p master..guile

If I want to try and build your stuff before pulling it in, I can do:

git-checkout guile

Then I can revert and pull your changes in with:

git-checkout master
git-merge guile

The logs are fully preserved.

I need to learn how to pull in only some of the patches from a
particular branch (I was a bit unsure about your CFLAGS/AM_CFLAGS
change), and I'm not yet sure how to do this.  It doesn't feel important
though.

/Simon


From ludovic.courtes at laas.fr  Fri Jun  8 13:52:06 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 08 Jun 2007 13:52:06 +0200
Subject: [gnutls-dev] Starting Guile integration
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87sl9bdfi0.fsf@laas.fr> <87zm3jiyyt.fsf@mocca.josefsson.org>
	<873b1bbxgn.fsf@laas.fr> <873b123c75.fsf@mocca.josefsson.org>
Message-ID: <87myzall3t.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I think that either there actually are some cases were this usage will
> cause problems (perhaps for '...' function prototypes?  Or perhaps the C
> standard regards something in this as undefined, possibly function
> pointers aren't type-compatible in general), or GCC should not have a
> warning mechanism for it.  I'm leaning towards that there actually may
> be some platform where this could cause problems, and that was what
> prompted GCC to add this warning flag.

No no no.  From ISO/IEC 9899:1999 (aka. C99), Section 6.7.5.3,
Paragraph 14:

  The empty list in a function declarator that is not part of a
  definition of that function specifies that no information about the
  number or types of the parameters is supplied.124)

In other words, if F is declared as "extern int f ();", then it may
rightfully be passed any number of arguments.

This mechanism is different from the ellipsis though (Paragraph 9): such
functions are not treated differently from functions with full
prototypes; therefore, the "regular" calling conventions are used when
invoking them rather than that of variadic functions.

That said, this feature is reminiscent from older revisions of the
standard and Footnote 124 reads:

  The use of function declarators with empty parentheses (not
  prototype-format parameter type declarators) is an obsolescent
  feature.

Thus, in the longer term, Guile will probably have to avoid it.


Besides, most of the warnings made available by GCC do not relate to
anything mandated by the standard.

Thanks,
Ludo'.




From simon at josefsson.org  Fri Jun  8 15:53:49 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 15:53:49 +0200
Subject: [gnutls-dev] GnuTLS 1.7.12
Message-ID: <878xau1riq.fsf@mocca.josefsson.org>

Note that the GnuTLS 1.7.x branch is NOT what you want for your stable
system.  It is intended for developers and experienced users.

This release closes one of the milestones before the next stable
release, namely:

* Integrate Guile bindings.

Many thanks to Ludovic Court?s for this contribution!

There are three remaining work items before the next stable release:

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

* Make sure the stuff in the GIT repository (i.e., all recent work) is
  available through CVS, either through back-ports to the old server or
  a git-cvsserver approach.

Below is the regular release announcement...

* Version 1.7.12 (released 2007-06-08)

** Guile bindings for GnuTLS have been included.
Contributed by Ludovic Court?s <ludovic.courtes at laas.fr>.  There is a
new chapter 'Guile Bindings' in the manual.

** Have PKCS8 parser return better error codes.
Reported by Nate Nielsen <nielsen-list at memberwebs.com>, see
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001653.html> and
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001654.html>.

** Fix mem leak for sessions with client authentication via certificates.
Reported by Andrew W. Nosenko <andrew.w.nosenko at gmail.com>, see
<http://lists.gnupg.org/pipermail/gnutls-dev/2007-April/001539.html>.

** Fix mem leaks.
Reported by Dennis Vshivkov <walrus at amur.ru>, see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333050>.  Added
self-test tests/parse_ca.c to test regressions.

** Fix build failures related to missing images in manual.
Reported by Andreas Metzler <ametzler at downhill.at.eu.org>.

** Update gnulib files.

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

Here are the compressed sources (4.6MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.12.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.7.12.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.12.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.7.12.tar.bz2.sig

Here are the SHA-1 and SHA-224 checksums:

b024c4e74e8bcee8e56409feff19d7bcf459d692  gnutls-1.7.12.tar.bz2
894e7e148a8a1baf0bf23c78241cff972aed6d08  gnutls-1.7.12.tar.bz2.sig

a3f85879e4f249ba57a8e3f213adbb773cf760cd3a1bc7e7dded137e  gnutls-1.7.12.tar.bz2
8556d171171504a35f892ae58a5ca4cef115e889dca91920c321eb4c  gnutls-1.7.12.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon


From simon at josefsson.org  Fri Jun  8 15:55:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 15:55:39 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87myzall3t.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 08
	Jun 2007 13:52:06 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87sl9bdfi0.fsf@laas.fr> <87zm3jiyyt.fsf@mocca.josefsson.org>
	<873b1bbxgn.fsf@laas.fr> <873b123c75.fsf@mocca.josefsson.org>
	<87myzall3t.fsf@laas.fr>
Message-ID: <874pli1rfo.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I think that either there actually are some cases were this usage will
>> cause problems (perhaps for '...' function prototypes?  Or perhaps the C
>> standard regards something in this as undefined, possibly function
>> pointers aren't type-compatible in general), or GCC should not have a
>> warning mechanism for it.  I'm leaning towards that there actually may
>> be some platform where this could cause problems, and that was what
>> prompted GCC to add this warning flag.
>
> No no no.  From ISO/IEC 9899:1999 (aka. C99), Section 6.7.5.3,
> Paragraph 14:
>
>   The empty list in a function declarator that is not part of a
>   definition of that function specifies that no information about the
>   number or types of the parameters is supplied.124)
>
> In other words, if F is declared as "extern int f ();", then it may
> rightfully be passed any number of arguments.
>
> This mechanism is different from the ellipsis though (Paragraph 9): such
> functions are not treated differently from functions with full
> prototypes; therefore, the "regular" calling conventions are used when
> invoking them rather than that of variadic functions.

Ah, I see.  Thanks for the pointer.

> That said, this feature is reminiscent from older revisions of the
> standard and Footnote 124 reads:
>
>   The use of function declarators with empty parentheses (not
>   prototype-format parameter type declarators) is an obsolescent
>   feature.
>
> Thus, in the longer term, Guile will probably have to avoid it.

Yup.

/Simon


From simon at josefsson.org  Fri Jun  8 15:58:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 15:58:55 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <878xau1riq.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 08 Jun 2007 15:53:49 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
Message-ID: <87zm3azgww.fsf@mocca.josefsson.org>

Darn, I forgot to run 'make check'.  There are some failures:

make  check-TESTS
make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
PASS: anonymous-auth.scm
PASS: session-record-port.scm
PASS: pkcs-import-export.scm
guile: uncaught throw to gnutls-error: (#<gnutls-error-enum GnuTLS internal error.> import-openpgp-public-key)
FAIL: openpgp-keys.scm
guile: uncaught throw to gnutls-error: (#<gnutls-error-enum Error loading the keyring.> import-openpgp-keyring)
FAIL: openpgp-keyring.scm
guile: uncaught throw to gnutls-error: (#<gnutls-error-enum GnuTLS internal error.> import-openpgp-public-key)
FAIL: openpgp-auth.scm
PASS: srp-base64.scm
PASS: errors.scm
PASS: x509-certificates.scm
PASS: x509-auth.scm
===================================
3 of 10 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/jas/src/gnutls/guile/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/jas/src/gnutls/guile/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/jas/src/gnutls/guile'
make: *** [check-recursive] Error 1
jas at mocca:~/src/gnutls$

Can you reproduce this, Ludovic?

/Simon


From ludovic.courtes at laas.fr  Fri Jun  8 14:34:50 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 08 Jun 2007 14:34:50 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org>
Message-ID: <871wgmlj4l.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Darn, I forgot to run 'make check'.  There are some failures:

[...]

> Can you reproduce this, Ludovic?

Yes.  The issue is that `libguile-gnutls{,-extra}-v-0.so' is linked
against the system-wide `libgnutls{,-extra}.so' instead of the recently
built one.  And it turns out that the system-wide version that you have
is a buggy one.  ;-)  I guess the tests don't even run when GnuTLS is
not already installed.

I'll fix this later this afternoon cause I cannot do it conveniently
right now.

Thanks,
Ludovic.



From simon at josefsson.org  Fri Jun  8 16:39:02 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 08 Jun 2007 16:39:02 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <871wgmlj4l.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Fri, 08
	Jun 2007 14:34:50 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
Message-ID: <87myzazf21.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Darn, I forgot to run 'make check'.  There are some failures:
>
> [...]
>
>> Can you reproduce this, Ludovic?
>
> Yes.  The issue is that `libguile-gnutls{,-extra}-v-0.so' is linked
> against the system-wide `libgnutls{,-extra}.so' instead of the recently
> built one.  And it turns out that the system-wide version that you have
> is a buggy one.  ;-)  I guess the tests don't even run when GnuTLS is
> not already installed.
>
> I'll fix this later this afternoon cause I cannot do it conveniently
> right now.

Ah, makes sense.  Thanks for taking care of it.

/Simon


From ludo at chbouib.org  Fri Jun  8 19:58:25 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 08 Jun 2007 19:58:25 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
Message-ID: <87wsyexr9a.fsf@chbouib.org>

Hi,

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Yes.  The issue is that `libguile-gnutls{,-extra}-v-0.so' is linked
> against the system-wide `libgnutls{,-extra}.so' instead of the recently
> built one.  And it turns out that the system-wide version that you have
> is a buggy one.  ;-)  I guess the tests don't even run when GnuTLS is
> not already installed.

The solution consists in passing `libgnutls.la' and `libgnutls-extra.la'
first in the `LDFLAGS' of `libguile-gnutls' and `libguile-gnutls-extra'
so that the RPATH is in the right order (it took me a while to figure it
out).

The fix is in my repository.

I'd rather send patches by email for such cases but it seems that the
only way to send the actual patch, the log, and the commit ancestry
information is with `git-format-patch' which creates a new message.  Or
is there another solution?

Thanks,
Ludovic.



From ludo at chbouib.org  Fri Jun  8 20:02:38 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 08 Jun 2007 20:02:38 +0200
Subject: [gnutls-dev] I like git
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87abvdaz1b.fsf@chbouib.org> <87y7iu1xh3.fsf@mocca.josefsson.org>
	<87tzti1vvt.fsf_-_@mocca.josefsson.org>
Message-ID: <87d506xr29.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I'm so starting to like git.  I started by adding your repository as a
> branch:
>
> cg-branch-add guile http://www.laas.fr/~lcourtes/software/gnutls.git

I guess this basically creates `.git/remotes/guile'.

> Then I can update your stuff as easy as:
>
> cg-fetch guile
>
> I can review your changes by using:
>
> git-log -p master..guile
>
> If I want to try and build your stuff before pulling it in, I can do:
>
> git-checkout guile
>
> Then I can revert and pull your changes in with:
>
> git-checkout master
> git-merge guile
>
> The logs are fully preserved.

Cool, thanks for the summary.

Glad we're starting to learn more about it!  ;-)

Ludovic.



From simon at josefsson.org  Mon Jun 11 10:32:41 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 10:32:41 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87wsyexr9a.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Fri, 08 Jun 2007 19:58:25 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org>
Message-ID: <87r6oi3n86.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>
>> Yes.  The issue is that `libguile-gnutls{,-extra}-v-0.so' is linked
>> against the system-wide `libgnutls{,-extra}.so' instead of the recently
>> built one.  And it turns out that the system-wide version that you have
>> is a buggy one.  ;-)  I guess the tests don't even run when GnuTLS is
>> not already installed.
>
> The solution consists in passing `libgnutls.la' and `libgnutls-extra.la'
> first in the `LDFLAGS' of `libguile-gnutls' and `libguile-gnutls-extra'
> so that the RPATH is in the right order (it took me a while to figure it
> out).

Yeah, I think there is something weird going on with libtool that
requires the ordering to be right.

> The fix is in my repository.

Did you forget to push it to the public server?  I can't find anything
new to fetch.

> I'd rather send patches by email for such cases but it seems that the
> only way to send the actual patch, the log, and the commit ancestry
> information is with `git-format-patch' which creates a new message.  Or
> is there another solution?

You can use `git-format-patch --stdout' to avoid creating a file.
Including what is generated by g-f-p in another e-mail should work, no?

Although I don't know how to apply such a patch, and using 'git-fetch'
is pretty easy for me.  But maybe I can learn something new.

/Simon


From simon at josefsson.org  Mon Jun 11 10:35:56 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 10:35:56 +0200
Subject: [gnutls-dev] I like git
In-Reply-To: <87d506xr29.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Fri, 08 Jun 2007 20:02:38 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <878xb3lwia.fsf@mocca.josefsson.org>
	<87abvdaz1b.fsf@chbouib.org> <87y7iu1xh3.fsf@mocca.josefsson.org>
	<87tzti1vvt.fsf_-_@mocca.josefsson.org>
	<87d506xr29.fsf@chbouib.org>
Message-ID: <87myz63n2r.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I'm so starting to like git.  I started by adding your repository as a
>> branch:
>>
>> cg-branch-add guile http://www.laas.fr/~lcourtes/software/gnutls.git
>
> I guess this basically creates `.git/remotes/guile'.

Actually it creates .git/branches/guile.  I'm not sure it was a good
idea to make it a branch, it seems the 'guile' branch shows up at
repo.or.cz too.  That seems somewhat confusing, although perhaps it is
OK, and allows others to pull your changes from the repo.or.cz
repository too.  On the other hand, that will not scale very well if
every third-party branch I pull from is pushed to repo.or.cz as well...

/Simon


From simon at josefsson.org  Mon Jun 11 10:57:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 10:57:37 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87r6oi3n86.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 11 Jun 2007 10:32:41 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
Message-ID: <87d5023m2m.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> The fix is in my repository.
>
> Did you forget to push it to the public server?  I can't find anything
> new to fetch.

I found it now, thanks.

It fixed some of the self-tests, but one is still failing:

make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
PASS: anonymous-auth.scm
PASS: session-record-port.scm
PASS: pkcs-import-export.scm
PASS: openpgp-keys.scm
guile: uncaught throw to gnutls-error: (#<gnutls-error-enum Error loading the keyring.> import-openpgp-keyring)
FAIL: openpgp-keyring.scm
PASS: openpgp-auth.scm
PASS: srp-base64.scm
PASS: errors.scm
PASS: x509-certificates.scm
PASS: x509-auth.scm
===================================
1 of 10 tests failed
Please report to bug-gnutls at gnu.org
===================================

Ideas?

I first thought it might be that I'm using old OpenCDK, so I upgraded to
0.6.3 in GnuTLS, but it made no difference.

I'll see if I can debug this myself...

/Simon


From simon at josefsson.org  Mon Jun 11 11:19:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 11:19:07 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87d5023m2m.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 11 Jun 2007 10:57:37 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
Message-ID: <874ple3l2s.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> I'll see if I can debug this myself...

It is related to -rpath problems... if I remove the installed copy of
libgnutls, libgnutls-extra, it works.  It seems to prefer to link
$prefix/lib/libgnutls.so over $builddir/lib/.libs/libgnutls.so.

This should really be debugged fully, and possibly reported to the
libtool team, since I've encountered this before and the fix is often
not logical, and therefor may indicate a libtool bug.

/Simon


From simon at josefsson.org  Mon Jun 11 11:25:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 11:25:36 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <874ple3l2s.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 11 Jun 2007 11:19:07 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org>
Message-ID: <87zm36267j.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> I'll see if I can debug this myself...
>
> It is related to -rpath problems... if I remove the installed copy of
> libgnutls, libgnutls-extra, it works.  It seems to prefer to link
> $prefix/lib/libgnutls.so over $builddir/lib/.libs/libgnutls.so.
>
> This should really be debugged fully, and possibly reported to the
> libtool team, since I've encountered this before and the fix is often
> not logical, and therefor may indicate a libtool bug.

I may have fixed it, by using *_LIBADD instead of *_LDFLAGS to specify
the dependent libraries.

/Simon


From simon at josefsson.org  Mon Jun 11 14:22:35 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 14:22:35 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87vee8d1n0.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Fri, 01 Jun 2007 01:17:07 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org>
Message-ID: <87abv6r88k.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> For some reason, `make' now fails here in `doc/reference':
>
>   $ make -C doc/reference/
>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>   gtk-doc: Scanning header files
>   [...]
>   gtk-doc: Compiling scanner
>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>   [...]
>
> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
> Unfortunately, I wasn't able to pinpoint the root of the problem.
> Re-running `autoreconf' and `configure' didn't help.  Any hint?

Remove 'gnutls.types' in that directory.  The file is sometimes
generated by the gtk-doc-tools (but not always!) and if it is present,
gtk-doc will use different tools.

This is probably not the proper fix, but I'm not sure why this
happens..  I'll report it as a gtk-doc-tools bug.

/Simon


From simon at josefsson.org  Mon Jun 11 14:39:27 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 14:39:27 +0200
Subject: [gnutls-dev] Starting Guile integration
In-Reply-To: <87abv6r88k.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 11 Jun 2007 14:22:35 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
Message-ID: <87sl8ypsw0.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> ludo at chbouib.org (Ludovic Court?s) writes:
>
>> For some reason, `make' now fails here in `doc/reference':
>>
>>   $ make -C doc/reference/
>>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>>   gtk-doc: Scanning header files
>>   [...]
>>   gtk-doc: Compiling scanner
>>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>>   [...]
>>
>> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
>> Unfortunately, I wasn't able to pinpoint the root of the problem.
>> Re-running `autoreconf' and `configure' didn't help.  Any hint?
>
> Remove 'gnutls.types' in that directory.  The file is sometimes
> generated by the gtk-doc-tools (but not always!) and if it is present,
> gtk-doc will use different tools.
>
> This is probably not the proper fix, but I'm not sure why this
> happens..  I'll report it as a gtk-doc-tools bug.

I believe I have fixed this in git master now.  At least 'make
distcheck' passes, which it didn't do before.

/Simon


From simon at josefsson.org  Mon Jun 11 15:11:49 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 15:11:49 +0200
Subject: [gnutls-dev] GnuTLS 1.7.13
Message-ID: <87ir9upre2.fsf@mocca.josefsson.org>

Note that the GnuTLS 1.7.x branch is NOT what you want for your stable
system.  It is intended for developers and experienced users.

There are three remaining work items before the next stable release, and
I expect the last two to be solved during this week.

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

* Make sure the stuff in the GIT repository (i.e., all recent work) is
  available through CVS, either through back-ports to the old server or
  a git-cvsserver approach.

Below is the regular release announcement...

* Version 1.7.13 (released 2007-06-11)

** OpenCDK copy updated to version 0.6.3.

** Build fixes for GnuTLS Guile bindings.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

** Build fix for GTK-DOC manual.

** Update gnulib files.

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

Here are the compressed sources (4.6MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.13.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.7.13.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.13.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.7.13.tar.bz2.sig

Here are the SHA-1 and SHA-224 checksums:

0ce4eda21292d0281f2931dec3498830ce683dbf  gnutls-1.7.13.tar.bz2
f9d8cf96fd7bff80fbaf0d69d3b3a9c8786b14ea  gnutls-1.7.13.tar.bz2.sig

65380e916a05a4b74e246319ef621c7dbf251661083df3fba97552d9  gnutls-1.7.13.tar.bz2
888b0ba30a82d088097917ef65a88d5273b104db5a3ec445e041ca56  gnutls-1.7.13.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070611/bce4c6af/attachment.pgp 

From ludo at chbouib.org  Mon Jun 11 18:53:59 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 11 Jun 2007 18:53:59 +0200
Subject: [gnutls-dev] Problems with gtk-doc
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
Message-ID: <87r6oiqvo8.fsf_-_@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> ludo at chbouib.org (Ludovic Court?s) writes:
>
>> For some reason, `make' now fails here in `doc/reference':
>>
>>   $ make -C doc/reference/
>>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>>   gtk-doc: Scanning header files
>>   [...]
>>   gtk-doc: Compiling scanner
>>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>>   [...]
>>
>> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
>> Unfortunately, I wasn't able to pinpoint the root of the problem.
>> Re-running `autoreconf' and `configure' didn't help.  Any hint?
>
> Remove 'gnutls.types' in that directory.  The file is sometimes
> generated by the gtk-doc-tools (but not always!) and if it is present,
> gtk-doc will use different tools.

It worked!

It may indeed qualify as a `gtk-doc-tools' bug.  ;-)

> I believe I have fixed this in git master now.  At least 'make
> distcheck' passes, which it didn't do before.

I can't see any change related to that in the repo at `repo.or.cz'.  Did
you forget to push it?

Now, I'm still unable to run `distcheck' because PDF generation fails [0].
I believe the issue is that several runs are needed to get it right but
make stops after the first one (which fails).  But then, how can it work
on your computer and not on mine?

Thanks!

Ludovic.

[0] http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001678.html



From ludo at chbouib.org  Mon Jun 11 19:00:54 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 11 Jun 2007 19:00:54 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org>
Message-ID: <87wsyapgs9.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> It is related to -rpath problems... if I remove the installed copy of
> libgnutls, libgnutls-extra, it works.  It seems to prefer to link
> $prefix/lib/libgnutls.so over $builddir/lib/.libs/libgnutls.so.

It appears to be already fixed here:

  $ objdump -p .libs/libguile-gnutls{,-extra}-v-0.so | grep PATH
    RPATH       /home/ludo/src/gnutls/lib/.libs:/usr/local/lib
    RPATH       /home/ludo/src/gnutls/guile/src/.libs:/home/ludo/src/gnutls/lib/.libs:/home/ludo/src/gnutls/libextra/.libs:/usr/local/lib
  $ objdump -p ../../libextra/.libs/libgnutls-extra.so | grep PATH
    RPATH       /home/ludo/src/gnutls/lib/.libs:/usr/local/lib

IOW, the `.libs' directories all appear _before_ `/usr/local/lib', which
is exactly what we want.

> I may have fixed it, by using *_LIBADD instead of *_LDFLAGS to specify
> the dependent libraries.

This shouldn't make any difference (I did try it also while chasing the
bug  ;-)).

Thanks,
Ludovic.



From simon at josefsson.org  Mon Jun 11 21:50:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 21:50:45 +0200
Subject: [gnutls-dev] Problems with gtk-doc
In-Reply-To: <87r6oiqvo8.fsf_-_@chbouib.org> ("Ludovic =?iso-8859-1?Q?Cour?=
	=?iso-8859-1?Q?t=E8s=22's?= message of
	"Mon, 11 Jun 2007 18:53:59 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
	<87r6oiqvo8.fsf_-_@chbouib.org>
Message-ID: <87tztenucq.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> ludo at chbouib.org (Ludovic Court?s) writes:
>>
>>> For some reason, `make' now fails here in `doc/reference':
>>>
>>>   $ make -C doc/reference/
>>>   make: Entering directory `/home/ludo/src/gnutls/doc/reference'
>>>   gtk-doc: Scanning header files
>>>   [...]
>>>   gtk-doc: Compiling scanner
>>>   gnutls-scan.c:5:25: error: glib-object.h: No such file or directory
>>>   [...]
>>>
>>> Clearly, it lacks `pkg-config glib-2.0 --cflags` as CFLAGS.
>>> Unfortunately, I wasn't able to pinpoint the root of the problem.
>>> Re-running `autoreconf' and `configure' didn't help.  Any hint?
>>
>> Remove 'gnutls.types' in that directory.  The file is sometimes
>> generated by the gtk-doc-tools (but not always!) and if it is present,
>> gtk-doc will use different tools.
>
> It worked!
>
> It may indeed qualify as a `gtk-doc-tools' bug.  ;-)
>
>> I believe I have fixed this in git master now.  At least 'make
>> distcheck' passes, which it didn't do before.
>
> I can't see any change related to that in the repo at `repo.or.cz'.  Did
> you forget to push it?

Yes, I did.  Please try it now.  I think I want a post-commit hook that
pushes everything to the public repository...  I don't see why I ever
would want to commit anything and not push it to the public server
directly.  The only reason would be if I'm offline, but then the push
would simply fail.  I wonder of I'm missing some git understanding.

> Now, I'm still unable to run `distcheck' because PDF generation fails [0].
> I believe the issue is that several runs are needed to get it right but
> make stops after the first one (which fails).  But then, how can it work
> on your computer and not on mine?
>
> Thanks!
>
> Ludovic.
>
> [0] http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001678.html

The underful/overful \hbox warnings are harmless.  Can you post the
entire log?  I suspect you need to install the 'tetex-extra' package.

/Simon


From simon at josefsson.org  Mon Jun 11 21:52:21 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 21:52:21 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87wsyapgs9.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon, 11 Jun 2007 19:00:54 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
Message-ID: <87ps42nua2.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> It is related to -rpath problems... if I remove the installed copy of
>> libgnutls, libgnutls-extra, it works.  It seems to prefer to link
>> $prefix/lib/libgnutls.so over $builddir/lib/.libs/libgnutls.so.
>
> It appears to be already fixed here:
>
>   $ objdump -p .libs/libguile-gnutls{,-extra}-v-0.so | grep PATH
>     RPATH       /home/ludo/src/gnutls/lib/.libs:/usr/local/lib
>     RPATH       /home/ludo/src/gnutls/guile/src/.libs:/home/ludo/src/gnutls/lib/.libs:/home/ludo/src/gnutls/libextra/.libs:/usr/local/lib
>   $ objdump -p ../../libextra/.libs/libgnutls-extra.so | grep PATH
>     RPATH       /home/ludo/src/gnutls/lib/.libs:/usr/local/lib
>
> IOW, the `.libs' directories all appear _before_ `/usr/local/lib', which
> is exactly what we want.

Yup.

>> I may have fixed it, by using *_LIBADD instead of *_LDFLAGS to specify
>> the dependent libraries.
>
> This shouldn't make any difference (I did try it also while chasing the
> bug  ;-)).

It may not have been the immediate cause of making it work, but at least
it seems to work now.  And using _LIBADD instead of _LDFLAGS appears to
be more correct anyway.

/Simon


From ludo at chbouib.org  Mon Jun 11 22:44:00 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 11 Jun 2007 22:44:00 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org>
Message-ID: <87wsyanrvz.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> It may not have been the immediate cause of making it work, but at least
> it seems to work now.  And using _LIBADD instead of _LDFLAGS appears to
> be more correct anyway.

Right, but it actually breaks the RPATH ordering here:

  $ objdump -p .libs/libguile-gnutls{,-extra}-v-0.so | grep PATH
    RPATH       /usr/local/lib:/home/ludo/src/gnutls/lib/.libs
    RPATH       /usr/local/lib:/home/ludo/src/gnutls/lib/.libs:/home/ludo/src/gnutls/libextra/.libs:/home/ludo/src/gnutls/guile/src/.libs

Does it behave similarly on your machine?

I don't think the relative order of `_LDFLAGS' and `_LIBADD' is
documented in Libtool, so I think we'd better avoid mixing them.  Using
only `_LDFLAGS' is valid and allows us to really get control over the
order of libraries on the linker's command-line and in RPATH.

Thanks,
Ludovic.



From ludo at chbouib.org  Mon Jun 11 22:50:12 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 11 Jun 2007 22:50:12 +0200
Subject: [gnutls-dev] Problems with gtk-doc
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
	<87r6oiqvo8.fsf_-_@chbouib.org>
	<87tztenucq.fsf@mocca.josefsson.org>
Message-ID: <871wginrln.fsf@chbouib.org>

Hey,

Simon Josefsson <simon at josefsson.org> writes:

> Yes, I did.  Please try it now.

I just did (see my other post).

> I think I want a post-commit hook that pushes everything to the public
> repository...  I don't see why I ever would want to commit anything
> and not push it to the public server directly.  The only reason would
> be if I'm offline, but then the push would simply fail.  I wonder of
> I'm missing some git understanding.

Personally, I manually `rsync' the `.git' directory periodically.  A
commit hook would be helpful, indeed.

> The underful/overful \hbox warnings are harmless.  Can you post the
> entire log?  I suspect you need to install the 'tetex-extra' package.

Unfortunately, the `texlive' packages don't want to be installed
currently (in Debian sid).

I've put the log at http://www.laas.fr/~lcourtes/tmp/gnutls.log .
It's not crystal-clear, though.

Thanks,
Ludovic.



From ludo at chbouib.org  Mon Jun 11 22:56:52 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 11 Jun 2007 22:56:52 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org>
Message-ID: <87k5uamcq3.fsf@chbouib.org>

A non-text attachment was scrubbed...
Name: ,,diff
Type: text/x-patch
Size: 1947 bytes
Desc: The patch
Url : /pipermail/attachments/20070611/99caab9c/attachment.bin 

From simon at josefsson.org  Mon Jun 11 23:18:10 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 23:18:10 +0200
Subject: [gnutls-dev] Problems with gtk-doc
In-Reply-To: <871wginrln.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon, 11 Jun 2007 22:50:12 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
	<87r6oiqvo8.fsf_-_@chbouib.org>
	<87tztenucq.fsf@mocca.josefsson.org> <871wginrln.fsf@chbouib.org>
Message-ID: <87d502nqb1.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

>> The underful/overful \hbox warnings are harmless.  Can you post the
>> entire log?  I suspect you need to install the 'tetex-extra' package.
>
> Unfortunately, the `texlive' packages don't want to be installed
> currently (in Debian sid).
>
> I've put the log at http://www.laas.fr/~lcourtes/tmp/gnutls.log .
> It's not crystal-clear, though.

The problem is that the feymr10 font is missing, and it is indeed part
of tetex-extra.  I don't know texlive though.  Maybe texinfo needs to be
modified to use it.

/Simon

/home/ludo/src/gnutls/gnutls-1.7.13/doc/signatures.texi:14: Font @thiseurofont=
feymr10 at 11.0pt not loadable: Metric (TFM) file not found.
<to be read again> 
                   @thiseurofont 
@euro ->{@eurofont 
                   e}
l.14 message of donating 1 @euro
                                {} to Greenpeace and find out that he
? 
Missing character: There is no e in font nullfont!
/home/ludo/src/gnutls/gnutls-1.7.13/doc/signatures.texi:15: Font @thiseurofont=
feymr10 at 11.0pt not loadable: Metric (TFM) file not found.
<to be read again> 
                   @thiseurofont 
@euro ->{@eurofont 
                   e}
l.15 donated 1.000.000 @euro
                            {} to Bad Inc.
? 
Missing character: There is no e in font nullfont!
[25] [26]


From simon at josefsson.org  Mon Jun 11 20:55:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 20:55:20 +0200
Subject: [gnutls-dev] GNUTLS configure is buggered
In-Reply-To: <466D80F6.2030309@enterprise.bidmc.harvard.edu> (Kristofer
	T. Karas's message of "Mon, 11 Jun 2007 13:05:58 -0400")
References: <466D80F6.2030309@enterprise.bidmc.harvard.edu>
Message-ID: <87y7iqnwx3.fsf@mocca.josefsson.org>

"Kristofer T. Karas" <ktk at enterprise.bidmc.harvard.edu> writes:

> Hi,
>
> Just wanted to report that the "configure" script in gnutls versions
> 1.7.12 and 1.7.13 is broken.  (See the output of make on a Slackware
> gnu/linux system, below.)
>
> It seems that configure performs a number of tests to identify what
> features the c compiler supports (gcc 3.4.6 in this case) and it
> attempts to do so by setting AM_CFLAGS to the command-line option in
> question.  However, AM_CFLAGS is not used by $ac_compile, resulting in a
> "true" result for every single test performed.

Hi!  Thanks for the report.  I have reverted the recent
s/CFLAGS/AM_CFLAGS/ change for the -Wno-pointer-sign test, since it is
not needed there.

I couldn't find any other test in configure.in that set AM_CFLAGS and
then tested whether it worked or not, though.  Please test whether
tomorrow's snapshot works for you.

Regards,
Simon

> Example:
>   configure:9496: checking if gcc supports -Wno-pointer-sign
>   configure:9521: gcc -std=gnu99 -c  -D_REENTRANT -D_THREAD_SAFE  conftest.c >&5
>   configure:9527: $? = 0
>   configure:9541: result: yes
>
> And when attempting to make, we get:
>
> /bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../intl  -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -pipe    -D_REENTRANT -D_THREAD_SAFE -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c -o dummy.lo dummy.c
>  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../intl -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -pipe -D_REENTRANT -D_THREAD_SAFE -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.c  -fPIC -DPIC -o .libs/dummy.o
> cc1: error: unrecognized command line option "-Wno-pointer-sign"
> make[3]: *** [dummy.lo] Error 1
>
> Regards,
> Kris


From simon at josefsson.org  Tue Jun 12 08:24:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Jun 2007 08:24:37 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87wsyanrvz.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon, 11 Jun 2007 22:44:00 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
Message-ID: <874pldofkq.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> It may not have been the immediate cause of making it work, but at least
>> it seems to work now.  And using _LIBADD instead of _LDFLAGS appears to
>> be more correct anyway.
>
> Right, but it actually breaks the RPATH ordering here:
>
>   $ objdump -p .libs/libguile-gnutls{,-extra}-v-0.so | grep PATH
>     RPATH       /usr/local/lib:/home/ludo/src/gnutls/lib/.libs
>     RPATH       /usr/local/lib:/home/ludo/src/gnutls/lib/.libs:/home/ludo/src/gnutls/libextra/.libs:/home/ludo/src/gnutls/guile/src/.libs
>
> Does it behave similarly on your machine?

No:

jas at mocca:~/src/gnutls$ objdump -p guile/src/.libs/libguile-gnutls-*.so|grep PATH
  RPATH       /home/jas/src/gnutls/lib/.libs:/home/jas/src/gnutls/libextra/.libs:/home/jas/src/gnutls/guile/src/.libs:/usr/local/lib
  RPATH       /home/jas/src/gnutls/lib/.libs:/usr/local/lib
jas at mocca:~/src/gnutls$

Did you do a clean build?

> I don't think the relative order of `_LDFLAGS' and `_LIBADD' is
> documented in Libtool, so I think we'd better avoid mixing them.  Using
> only `_LDFLAGS' is valid and allows us to really get control over the
> order of libraries on the linker's command-line and in RPATH.

Still, libtool manual recommends to use LIBADD for library dependencies,
so if that doesn't work, we should report it as a bug.

Btw, which libtool version are you using?  I think libtool is the one
tool that doesn't have version-checks in configure.in.

/Simon


From ludo at chbouib.org  Tue Jun 12 10:10:44 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 12 Jun 2007 10:10:44 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org>
Message-ID: <87odjlk2yj.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Did you do a clean build?

Yes.

The link command here is:

  /bin/sh ../../libtool --tag=CC --mode=link ccache gcc -std=gnu99
  -D_REENTRANT -D_THREAD_SAFE [... CFLAGS ...] -I../../lgl -I../../lgl
  -I/usr/local/include -pthread -D_REENTRANT -D_THREAD_SAFE
  -Wno-pointer-sign -pthread -lguile -lltdl -L/usr/local/lib -lgmp
  -lcrypt -lm -lltdl -o libguile-gnutls-v-0.la -rpath /usr/local/lib
  libguile_gnutls_v_0_la-core.lo libguile_gnutls_v_0_la-errors.lo
  libguile_gnutls_v_0_la-utils.lo ../../lib/libgnutls.la
  ../../lgl/liblgnu.la

That is, `_LDFLAGS' appear before `_LIBADD', which we don't want.  Is it
the same at your place?

>> I don't think the relative order of `_LDFLAGS' and `_LIBADD' is
>> documented in Libtool, so I think we'd better avoid mixing them.  Using
>> only `_LDFLAGS' is valid and allows us to really get control over the
>> order of libraries on the linker's command-line and in RPATH.
>
> Still, libtool manual recommends to use LIBADD for library dependencies,
> so if that doesn't work, we should report it as a bug.

It's not that it doesn't work, just that the relative order of
`_LDFLAGS' and `_LIBADD' is not specified.

> Btw, which libtool version are you using?  I think libtool is the one
> tool that doesn't have version-checks in configure.in.

I'm using Debian's package, version 1.5.22-4.

Thanks,
Ludovic.



From ludo at chbouib.org  Tue Jun 12 10:29:27 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 12 Jun 2007 10:29:27 +0200
Subject: [gnutls-dev] Problems with gtk-doc
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
	<87r6oiqvo8.fsf_-_@chbouib.org>
	<87tztenucq.fsf@mocca.josefsson.org>
	<871wginrln.fsf@chbouib.org> <87d502nqb1.fsf@mocca.josefsson.org>
Message-ID: <878xapk23c.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> The problem is that the feymr10 font is missing, and it is indeed part
> of tetex-extra.  I don't know texlive though.

Thanks for the hint.  After a bit of trial and error, I installed the
following packages (the `tetex-extra' transitional package is not
currently installable but individual `texlive' packages are):

  texlive-latex-base
  texlive-generic-recommended
  texlive-fonts-recommended

And it all works fine!

Thanks,
Ludovic.



From simon at josefsson.org  Tue Jun 12 15:38:38 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Jun 2007 15:38:38 +0200
Subject: [gnutls-dev] Problems with gtk-doc
In-Reply-To: <878xapk23c.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 12 Jun 2007 10:29:27 +0200")
References: <87myzmhqxz.fsf@chbouib.org> <87k5upyprk.fsf@mocca.josefsson.org>
	<87vee8d1n0.fsf@chbouib.org> <87abv6r88k.fsf@mocca.josefsson.org>
	<87r6oiqvo8.fsf_-_@chbouib.org>
	<87tztenucq.fsf@mocca.josefsson.org>
	<871wginrln.fsf@chbouib.org> <87d502nqb1.fsf@mocca.josefsson.org>
	<878xapk23c.fsf@chbouib.org>
Message-ID: <87r6oh8f8h.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> The problem is that the feymr10 font is missing, and it is indeed part
>> of tetex-extra.  I don't know texlive though.
>
> Thanks for the hint.  After a bit of trial and error, I installed the
> following packages (the `tetex-extra' transitional package is not
> currently installable but individual `texlive' packages are):
>
>   texlive-latex-base
>   texlive-generic-recommended
>   texlive-fonts-recommended
>
> And it all works fine!

I installed those packages here too, to make the switch from tetex to
texlive, and it seems to work fine here too.

/Simon


From simon at josefsson.org  Tue Jun 12 15:46:01 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Jun 2007 15:46:01 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87odjlk2yj.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 12 Jun 2007 10:10:44 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
Message-ID: <87myz58ew6.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Did you do a clean build?
>
> Yes.
>
> The link command here is:
>
>   /bin/sh ../../libtool --tag=CC --mode=link ccache gcc -std=gnu99
>   -D_REENTRANT -D_THREAD_SAFE [... CFLAGS ...] -I../../lgl -I../../lgl
>   -I/usr/local/include -pthread -D_REENTRANT -D_THREAD_SAFE
>   -Wno-pointer-sign -pthread -lguile -lltdl -L/usr/local/lib -lgmp
>   -lcrypt -lm -lltdl -o libguile-gnutls-v-0.la -rpath /usr/local/lib
>   libguile_gnutls_v_0_la-core.lo libguile_gnutls_v_0_la-errors.lo
>   libguile_gnutls_v_0_la-utils.lo ../../lib/libgnutls.la
>   ../../lgl/liblgnu.la
>
> That is, `_LDFLAGS' appear before `_LIBADD', which we don't want.  Is it
> the same at your place?

I think I get the same:

/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -I/usr/local/include  -I/usr/local/include -Wno-strict-prototypes -I../../lgl -I../../lgl  -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -lguile -lltdl  -lgmp -lcrypt -lm -lltdl  -o libguile-gnutls-v-0.la -rpath /usr/local/lib libguile_gnutls_v_0_la-core.lo libguile_gnutls_v_0_la-errors.lo libguile_gnutls_v_0_la-utils.lo ../../lib/libgnutls.la ../../lgl/liblgnu.la

Still, the paths look right for me:

jas at mocca:~/src/gnutls/guile/src$ objdump -p .libs/libguile-gnutls-*.so|grep PATH
  RPATH       /home/jas/src/gnutls/lib/.libs:/home/jas/src/gnutls/libextra/.libs:/home/jas/src/gnutls/guile/src/.libs:/usr/local/lib
  RPATH       /home/jas/src/gnutls/lib/.libs:/usr/local/lib
jas at mocca:~/src/gnutls/guile/src$

I also did a clean build (from raw checkout sources, via 'gitco') to
double check.

Maybe we need to compare more.  Here is the complete output from
make+rm+make:

jas at mocca:~/src/gnutls/guile/src$ make
make  all-am
make[1]: Entering directory `/home/jas/src/gnutls/guile/src'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/jas/src/gnutls/guile/src'
jas at mocca:~/src/gnutls/guile/src$ rm libguile-gnutls-v-0.la
jas at mocca:~/src/gnutls/guile/src$ make
make  all-am
make[1]: Entering directory `/home/jas/src/gnutls/guile/src'
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -I/usr/local/include  -I/usr/local/include -Wno-strict-prototypes -I../../lgl -I../../lgl  -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -lguile -lltdl  -lgmp -lcrypt -lm -lltdl  -o libguile-gnutls-v-0.la -rpath /usr/local/lib libguile_gnutls_v_0_la-core.lo libguile_gnutls_v_0_la-errors.lo libguile_gnutls_v_0_la-utils.lo ../../lib/libgnutls.la ../../lgl/liblgnu.la
rm -fr  .libs/libguile-gnutls-v-0.a .libs/libguile-gnutls-v-0.la .libs/libguile-gnutls-v-0.lai .libs/libguile-gnutls-v-0.so .libs/libguile-gnutls-v-0.so.0 .libs/libguile-gnutls-v-0.so.0.0.0
gcc -std=gnu99 -shared  .libs/libguile_gnutls_v_0_la-core.o .libs/libguile_gnutls_v_0_la-errors.o .libs/libguile_gnutls_v_0_la-utils.o -Wl,--whole-archive ../../lgl/.libs/liblgnu.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/jas/src/gnutls/lib/.libs -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib /usr/lib/libguile.so /usr/lib/libgmp.so -lcrypt -lm /usr/lib/libltdl.so ../../lib/.libs/libgnutls.so -L/usr/local/lib /usr/local/lib/libgcrypt.so -lnsl /usr/local/lib/libgpg-error.so  -Wl,-soname -Wl,libguile-gnutls-v-0.so.0 -o .libs/libguile-gnutls-v-0.so.0.0.0
(cd .libs && rm -f libguile-gnutls-v-0.so.0 && ln -s libguile-gnutls-v-0.so.0.0.0 libguile-gnutls-v-0.so.0)
(cd .libs && rm -f libguile-gnutls-v-0.so && ln -s libguile-gnutls-v-0.so.0.0.0 libguile-gnutls-v-0.so)
rm -fr .libs/libguile-gnutls-v-0.lax
mkdir .libs/libguile-gnutls-v-0.lax
rm -fr .libs/libguile-gnutls-v-0.lax/liblgnu.a
mkdir .libs/libguile-gnutls-v-0.lax/liblgnu.a
(cd .libs/libguile-gnutls-v-0.lax/liblgnu.a && ar x /home/jas/src/gnutls/guile/src/../../lgl/.libs/liblgnu.a)
ar cru .libs/libguile-gnutls-v-0.a  libguile_gnutls_v_0_la-core.o libguile_gnutls_v_0_la-errors.o libguile_gnutls_v_0_la-utils.o  .libs/libguile-gnutls-v-0.lax/liblgnu.a/asnprintf.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/printf-args.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/gc-libgcrypt.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/dummy.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/read-file.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/vasnprintf.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/gc-pbkdf2-sha1.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/md2.o .libs/libguile-gnutls-v-0.lax/liblgnu.a/printf-parse.o
ranlib .libs/libguile-gnutls-v-0.a
rm -fr .libs/libguile-gnutls-v-0.lax
creating libguile-gnutls-v-0.la
(cd .libs && rm -f libguile-gnutls-v-0.la && ln -s ../libguile-gnutls-v-0.la libguile-gnutls-v-0.la)
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99 -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -I/usr/local/include  -I/usr/local/include -Wno-strict-prototypes -I../../lgl -I../../lgl  -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -lguile -lltdl  -lgmp -lcrypt -lm -lltdl  -o libguile-gnutls-extra-v-0.la -rpath /usr/local/lib libguile_gnutls_extra_v_0_la-extra.lo ../../lib/libgnutls.la ../../libextra/libgnutls-extra.la ./libguile-gnutls-v-0.la ../../lgl/liblgnu.la
rm -fr  .libs/libguile-gnutls-extra-v-0.a .libs/libguile-gnutls-extra-v-0.la .libs/libguile-gnutls-extra-v-0.lai .libs/libguile-gnutls-extra-v-0.so .libs/libguile-gnutls-extra-v-0.so.0 .libs/libguile-gnutls-extra-v-0.so.0.0.0
gcc -std=gnu99 -shared  .libs/libguile_gnutls_extra_v_0_la-extra.o -Wl,--whole-archive ../../lgl/.libs/liblgnu.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/jas/src/gnutls/lib/.libs -Wl,--rpath -Wl,/home/jas/src/gnutls/libextra/.libs -Wl,--rpath -Wl,/home/jas/src/gnutls/guile/src/.libs -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib /usr/lib/libguile.so /usr/lib/libgmp.so -lcrypt -lm /usr/lib/libltdl.so ../../lib/.libs/libgnutls.so ../../libextra/.libs/libgnutls-extra.so ./.libs/libguile-gnutls-v-0.so -L/usr/local/lib /usr/local/lib/libgcrypt.so -lnsl /usr/local/lib/libgpg-error.so  -Wl,-soname -Wl,libguile-gnutls-extra-v-0.so.0 -o .libs/libguile-gnutls-extra-v-0.so.0.0.0
(cd .libs && rm -f libguile-gnutls-extra-v-0.so.0 && ln -s libguile-gnutls-extra-v-0.so.0.0.0 libguile-gnutls-extra-v-0.so.0)
(cd .libs && rm -f libguile-gnutls-extra-v-0.so && ln -s libguile-gnutls-extra-v-0.so.0.0.0 libguile-gnutls-extra-v-0.so)
rm -fr .libs/libguile-gnutls-extra-v-0.lax
mkdir .libs/libguile-gnutls-extra-v-0.lax
rm -fr .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a
mkdir .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a
(cd .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a && ar x /home/jas/src/gnutls/guile/src/../../lgl/.libs/liblgnu.a)
ar cru .libs/libguile-gnutls-extra-v-0.a  libguile_gnutls_extra_v_0_la-extra.o  .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/asnprintf.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/printf-args.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/gc-libgcrypt.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/dummy.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/read-file.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/vasnprintf.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/gc-pbkdf2-sha1.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/md2.o .libs/libguile-gnutls-extra-v-0.lax/liblgnu.a/printf-parse.o
ranlib .libs/libguile-gnutls-extra-v-0.a
rm -fr .libs/libguile-gnutls-extra-v-0.lax
creating libguile-gnutls-extra-v-0.la
(cd .libs && rm -f libguile-gnutls-extra-v-0.la && ln -s ../libguile-gnutls-extra-v-0.la libguile-gnutls-extra-v-0.la)
make[1]: Leaving directory `/home/jas/src/gnutls/guile/src'
jas at mocca:~/src/gnutls/guile/src$

>> Still, libtool manual recommends to use LIBADD for library dependencies,
>> so if that doesn't work, we should report it as a bug.
>
> It's not that it doesn't work, just that the relative order of
> `_LDFLAGS' and `_LIBADD' is not specified.

I don't think that should matter -- libtool should make sure *.la's are
linked properly.  If it has to re-order -rpath's to do that properly if
the order isn't specified, then libtool has to do that.

>> Btw, which libtool version are you using?  I think libtool is the one
>> tool that doesn't have version-checks in configure.in.
>
> I'm using Debian's package, version 1.5.22-4.

Same here.  Curious.

Btw, do your /etc/ld.so.conf contain /usr/local/lib?

/Simon


From simon at josefsson.org  Tue Jun 12 15:51:02 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Jun 2007 15:51:02 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <87k5uamcq3.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon, 11 Jun 2007 22:56:52 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87k5uamcq3.fsf@chbouib.org>
Message-ID: <87ir9t8ent.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> BTW, attached is a tiny patch that cleans up a few little things in
> `guile/tests'.
>
> I guess `git-applypatch' and `git-mailinfo' are the way to go...  :-)

After reading the man pages for those tools, I decided to go with
'git-am --signoff < ,,diff'.  It was quite painless.  Thanks for the
patch, applied.

/Simon


From ludo at chbouib.org  Tue Jun 12 17:18:32 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 12 Jun 2007 17:18:32 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org>
Message-ID: <874pldi4l3.fsf@chbouib.org>

Simon Josefsson <simon at josefsson.org> writes:

> Still, the paths look right for me:

I think I got it (I hope so!):

  * On my machine, Guile is installed in `/usr/local/'.  Thus,
    `GUILE_LDFLAGS' contain `-L /usr/local/lib', which leads Libtool to
    add `/usr/local/lib' to RPATH.

  * On your machine, Guile is installed in `/usr', so this does not
    happen.  And a `-L /usr/local/lib' to your Libtool link command-line
    and you'll make the same observations as I do.

Unless I'm mistaken, the fix is to revert your `_LIBADD' patch and get
back to something along the lines of:

  libXXX_LDFLAGS = $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
                   $(GUILE_LDFLAGS)

which makes sure that third-party libs (here, Guile) appear last.

Thanks,
Ludovic.



From home at alexhudson.com  Wed Jun 13 18:07:12 2007
From: home at alexhudson.com (Alex Hudson)
Date: Wed, 13 Jun 2007 17:07:12 +0100
Subject: [gnutls-dev] Speed of random data generation
Message-ID: <1181750832.3138.98.camel@laptop.alexhudson.com>


Hi everyone.

I'm a developer on a project called Bongo
(http://www.bongo-project.org/), which uses GNUTLS to implement SSL/TLS
encryption on various connections. 

Bongo is actually composed of a variety of daemons (we call them agents,
but..), and part of the setup process is to create the various
encryption data these agents need to use GNUTLS, e.g:

      * we save a random seed;
      * we create Diffie-Hellman parameters using
        gnutls_dh_params_{init|generate2}, and save that to a file;
      * we create RSA parameters using a similar process;
      * we create a public/private keyset for the various server
        sockets.

Now, the problem we have is that during setup, it can take a long time
to create all that data. The problem seems to be entirely entropy
starvation - and is particularly bad on headless server-type equipment.
One user had to wait over a day for the process to finish, for most it's
nothing like that slow, but can easily take a half hour.

I have a couple of questions:

      * Does it sound like we're doing something wrong? Originally, we
        didn't create much of this data at install time, but did it at
        runtime - and that was terribly, terribly bad, like some kind of
        entropy vampire. So, we know this is a big improvement - it's
        just still really bad, specifically on headless hardware.
      * Are there any improvements we can make? E.g., is there some way
        of deriving the data in a different order or something, so that
        it's not using so much entropy? I know we can ask people to
        install hardware RNG drivers and rngd or something, but that's
        again hardware-dependent.

Our project did use OpenSSL at one stage, and that seemed to work fine.
But, I'm wary of meddling in things I don't understand - and the choice
of strength of random data is not really something I feel I grasp well.
However, I would be happy to look into e.g., creating DH/RSA params from
a PRNG or something if that is advisable?

Many thanks,

Alex Hudson.



From ludo at chbouib.org  Wed Jun 13 19:42:39 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 13 Jun 2007 19:42:39 +0200
Subject: [gnutls-dev] [PATCH] Fix use of uninitialized variable in
	`gnutls_certificate_set_openpgp_key_mem ()'
Message-ID: <87wsy792eo.fsf@chbouib.org>

* libextra/gnutls_openpgp.c (stream_to_datum): Check whether INP is NULL
  rather than checking BUF (which is not initialized yet).
---
 libextra/gnutls_openpgp.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libextra/gnutls_openpgp.c b/libextra/gnutls_openpgp.c
index ddbbfc9..7ed57da 100644
--- a/libextra/gnutls_openpgp.c
+++ b/libextra/gnutls_openpgp.c
@@ -528,7 +528,7 @@ stream_to_datum (cdk_stream_t inp, gnutls_datum_t * raw)
   uint8_t *buf;
   size_t buflen;
 
-  if (!buf || !raw)
+  if (!inp || !raw)
     {
       gnutls_assert ();
       return GNUTLS_E_INVALID_REQUEST;
-- 
1.4.4.4




From ametzler at downhill.at.eu.org  Wed Jun 13 19:45:39 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 13 Jun 2007 19:45:39 +0200
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <1181750832.3138.98.camel@laptop.alexhudson.com>
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
Message-ID: <20070613174539.GA4058@downhill.g.la>

On 2007-06-13 Alex Hudson <home at alexhudson.com> wrote:
[...]
>       * we create Diffie-Hellman parameters using
>         gnutls_dh_params_{init|generate2}, and save that to a file;
>       * we create RSA parameters using a similar process;
>       * we create a public/private keyset for the various server
>         sockets.

> Now, the problem we have is that during setup, it can take a long time
> to create all that data. The problem seems to be entirely entropy
> starvation - and is particularly bad on headless server-type equipment.
[...]
> Our project did use OpenSSL at one stage, and that seemed to work fine.

Hello,
OpenSSL usually is built to use /dev/urandom instead of /dev/random
which does not block if you are out of entropy.

OpenSSL also simply seems pulls less bytes from the device for doing
the same thing. "certtool --generate-dh-params --bits 1024" almost
completely depletes the entropy pool, (down from 3596 to 143 bytes[1]
according to /proc/sys/kernel/random/entropy_avail, while the
equivalen "openssl gendh 1024" only takes 237 bytes but takes a little
bit more of raw computing power.

cu andreas
[1] No idea whether the unit actually *is* bytes. ;-)
-- 
`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 chbouib.org  Wed Jun 13 19:46:36 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 13 Jun 2007 19:46:36 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87k5uamcq3.fsf@chbouib.org>
	<87ir9t8ent.fsf@mocca.josefsson.org>
Message-ID: <874plb9283.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> After reading the man pages for those tools, I decided to go with
> 'git-am --signoff < ,,diff'.  It was quite painless.  Thanks for the
> patch, applied.

Cool.

I just sent a couple of patches but I copied (part of) the output of
`git-format-patch' in-line instead of attaching it.  Since I'm posting
through Gmane, I can't just "git-format-patch --stdout | mail gnutls-dev"
so this is not very convenient.

I can't seem to find a convenient interface for use with Gnus,
unfortunately.

Thanks,
Ludovic.



From ludo at chbouib.org  Wed Jun 13 19:41:57 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 13 Jun 2007 19:41:57 +0200
Subject: [gnutls-dev] [PATCH] Fix off-by-one in TLS 1.2 handshake.
Message-ID: <873b0vah0a.fsf@chbouib.org>

* lib/auth_cert.c (_gnutls_gen_cert_server_cert_req): Before invoking
  `gnutls_malloc ()', increment SIZE when using TLS 1.2 so that the
  allocated buffer is large-enough to contain the list of supported
  hashes.  Don't change SIZE later on.
---
 lib/auth_cert.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/lib/auth_cert.c b/lib/auth_cert.c
index 9114f09..f91c71c 100644
--- a/lib/auth_cert.c
+++ b/lib/auth_cert.c
@@ -1417,6 +1417,11 @@ _gnutls_gen_cert_server_cert_req (gnutls_session_t session, opaque ** data)
       session->internals.ignore_rdn_sequence == 0)
     size += cred->x509_rdn_sequence.size;
 
+  if (ver == GNUTLS_TLS1_2)
+    /* Need at least one byte to announce the number of supported hash
+       functions (see below).  */
+    size += 1;
+
   (*data) = gnutls_malloc (size);
   pdata = (*data);
 
@@ -1436,7 +1441,7 @@ _gnutls_gen_cert_server_cert_req (gnutls_session_t session, opaque ** data)
     {
       /* Supported hashes (nothing for now -- FIXME). */
       *pdata = 0;
-      pdata++, size++;
+      pdata++;
     }
 
   if (session->security_parameters.cert_type == GNUTLS_CRT_X509 &&
-- 
1.4.4.4




From twoaday at gmx.net  Wed Jun 13 21:08:05 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 13 Jun 2007 21:08:05 +0200
Subject: [gnutls-dev] [PATCH] Fix use of uninitialized variable
 in	`gnutls_certificate_set_openpgp_key_mem ()'
In-Reply-To: <87wsy792eo.fsf@chbouib.org>
References: <87wsy792eo.fsf@chbouib.org>
Message-ID: <46704095.3080207@gmx.net>

Ludovic Court?s wrote:
> * libextra/gnutls_openpgp.c (stream_to_datum): Check whether INP is NULL
>   rather than checking BUF (which is not initialized yet).

Thanks. I fixed it in the CVS.

But I'm not sure if the CVS is used any longer. I currently have no git
installed and thus I still use the CVS repository. Is this okay?


	Timo


From home at alexhudson.com  Wed Jun 13 22:54:54 2007
From: home at alexhudson.com (Alex Hudson)
Date: Wed, 13 Jun 2007 21:54:54 +0100
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <20070613174539.GA4058@downhill.g.la>
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
Message-ID: <1181768094.3138.106.camel@laptop.alexhudson.com>

Hey Andreas,

On Wed, 2007-06-13 at 19:45 +0200, Andreas Metzler wrote:
> OpenSSL usually is built to use /dev/urandom instead of /dev/random
> which does not block if you are out of entropy.

Ah, ok. Does GNUTLS _always_ use /dev/random, or does it depend on what
you're doing? And is that documented, do you know?

> OpenSSL also simply seems pulls less bytes from the device for doing
> the same thing. "certtool --generate-dh-params --bits 1024" almost
> completely depletes the entropy pool, (down from 3596 to 143 bytes[1]
> according to /proc/sys/kernel/random/entropy_avail, while the
> equivalen "openssl gendh 1024" only takes 237 bytes but takes a little
> bit more of raw computing power.

>From having looked around the web, people seem to talk about various
different solutions, like symlinking /dev/random to /dev/urandom (in
fact, one of our developers does this as well, because his machine
simply doesn't generate enough entropy and he can't do anything :)

I really don't want to be telling people to do that, but similarly,
waiting hours etc. is too much, especially since most people wanting to
use this software will likely want to use it on headless equipment. It
seems on modern Linux, the only randomness is going to come from disk
IO, and if the server has a lot of RAM it seems to be that the entropy
being generated could be basically zero.

Cheers,

Alex.



From simon at josefsson.org  Thu Jun 14 08:46:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 08:46:42 +0200
Subject: [gnutls-dev] CVS gnutls/libextra
In-Reply-To: <E1HyY5Z-0000Fh-TE@trithemius.gnupg.org> (CVS User's message of
	"Wed, 13 Jun 2007 21:01:05 +0200")
References: <E1HyY5Z-0000Fh-TE@trithemius.gnupg.org>
Message-ID: <87d4zzghil.fsf@mocca.josefsson.org>

Hi Timo!  I noticed your commit in gnutls CVS.  GnuTLS has changed to
use git for development, see:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1829
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2075
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2078

Running git-cvsimport seems to fail, and I'm not sure it is worth the
time to keep importing stuff from the CVS tree any longer.

See http://git.or.cz for documentation on how to use git.

What you can do is to clone the gnutls git repository and ask me to pull
from it, or post patches to the gnutls-dev mailing list and I'll commit
it.  Ludovic has done this for the guile-gnutls changes, and it has
worked rather well.

/Simon

"CVS User twoaday" <twoaday at gnutls.org> writes:

> Update of /cvs/gnutls/gnutls/libextra
> In directory trithemius:/tmp/cvs-serv839
>
> Modified Files:
> 	gnutls_openpgp.c 
> Log Message:
> Check if INP is NULL, not BUF.
> Noted by Ludovic.
>
>
> --- /cvs/gnutls/gnutls/libextra/gnutls_openpgp.c	2007/04/20 12:35:22	1.109
> +++ /cvs/gnutls/gnutls/libextra/gnutls_openpgp.c	2007/06/13 19:01:05	1.110
> @@ -528,7 +528,7 @@
>    uint8_t *buf;
>    size_t buflen;
>  
> -  if (!buf || !raw)
> +  if (!inp || !raw)
>      {
>        gnutls_assert ();
>        return GNUTLS_E_INVALID_REQUEST;
> @@ -539,7 +539,10 @@
>    cdk_free (buf);
>    
>    if (!buflen)
> -    return GNUTLS_E_INTERNAL_ERROR;
> +    {  
> +      gnutls_assert ();
> +      return GNUTLS_E_INTERNAL_ERROR;
> +    }  
>    return 0;
>  }


From simon at josefsson.org  Thu Jun 14 09:11:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 09:11:07 +0200
Subject: [gnutls-dev] CVS gnutls/libextra
In-Reply-To: <87d4zzghil.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 14 Jun 2007 08:46:42 +0200")
References: <E1HyY5Z-0000Fh-TE@trithemius.gnupg.org>
	<87d4zzghil.fsf@mocca.josefsson.org>
Message-ID: <87odjjf1tg.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Running git-cvsimport seems to fail, and I'm not sure it is worth the
> time to keep importing stuff from the CVS tree any longer.

In case someone knows why this happens, here is how it fails:

I first update the cvs repository:

LOCAL_CVS=/home/jas/self/private-cvs/gnutls
rsync --delete -e ssh -av cvs.gnupg.org:/cvs/gnutls/ $LOCAL_CVS

then I run git-cvsimport:

LOCAL_CVS=/home/jas/self/private-cvs/gnutls
LOCAL_GIT=/home/jas/self/private-git/gnutls
mkdir -p $LOCAL_GIT
cat<<EOF > /tmp/foo
wkoch:Werner Koch <wk at gnupg.org>
nmav:Nikos Mavrogiannopoulos <nmav at gnutls.org>
fiorinaf:Fabio Fiorina <fiorinaf at gnutls.org>
twoaday:Timo Schulz <twoaday at gnutls.org>
admcd:Andrew McDonald <admcd at gnutls.org>
jas:Simon Josefsson <simon at josefsson.org>
EOF
git-cvsimport -A /tmp/foo -k -d $LOCAL_CVS -C $LOCAL_GIT gnutls

Here $LOCAL_GIT is where my git repository is stored.  It is not a
checked out git repository, just a raw one.  The repository was created
by the exact same commands as above.

The output is below.

Perhaps I should ask on the git list...

/Simon

+ LOCAL_CVS=/home/jas/self/private-cvs/gnutls
+ LOCAL_GIT=/home/jas/self/private-git/gnutls
+ mkdir -p /home/jas/self/private-git/gnutls
+ cat
+ git-cvsimport -A /tmp/foo -k -d /home/jas/self/private-cvs/gnutls -C /home/jas/self/private-git/gnutls gnutls
.cvscopying: needs update
.cvsignore: needs update
.cvsusers: needs update
AUTHORS: needs update
COPYING: needs update
COPYING.LIB: needs update
ChangeLog: needs update
ChangeLog.1: needs update
GNUmakefile: needs update
Makefile.am: needs update
README: needs update
THANKS: needs update
build-aux/.cvsignore: needs update
build-aux/GNUmakefile: needs update
build-aux/config.rpath: needs update
build-aux/gendocs.sh: needs update
build-aux/link-warning.h: needs update
build-aux/maint.mk: needs update
configure.in: needs update
doc/.cvsignore: needs update
doc/Makefile.am: needs update
doc/README.CODING_STYLE: needs update
doc/README.CVS: needs update
doc/README.autoconf: needs update
doc/TODO: needs update
doc/arch/certificate-user-use-case.dia: needs update
doc/arch/certificate-user-use-case.eps: needs update
doc/arch/certificate-user-use-case.pdf: needs update
doc/arch/certificate-user-use-case.png: needs update
doc/arch/client-server-use-case.dia: needs update
doc/arch/client-server-use-case.eps: needs update
doc/arch/client-server-use-case.pdf: needs update
doc/arch/client-server-use-case.png: needs update
doc/arch/extensions_st.dia: needs update
doc/arch/extensions_st.eps: needs update
doc/arch/extensions_st.pdf: needs update
doc/arch/extensions_st.png: needs update
doc/arch/handshake-sequence.dia: needs update
doc/arch/handshake-sequence.eps: needs update
doc/arch/handshake-sequence.pdf: needs update
doc/arch/handshake-sequence.png: needs update
doc/arch/handshake-state.dia: needs update
doc/arch/handshake-state.eps: needs update
doc/arch/handshake-state.pdf: needs update
doc/arch/handshake-state.png: needs update
doc/arch/mod_auth_st.dia: needs update
doc/arch/mod_auth_st.eps: needs update
doc/arch/mod_auth_st.pdf: needs update
doc/arch/mod_auth_st.png: needs update
doc/arch/objects.dia: needs update
doc/arch/objects.eps: needs update
doc/arch/objects.pdf: needs update
doc/arch/objects.png: needs update
doc/certtool.cfg: needs update
doc/examples/.cvsignore: needs update
doc/examples/Makefile.am: needs update
doc/examples/ex-alert.c: needs update
doc/examples/ex-cert-select.c: needs update
doc/examples/ex-client-authz.c: needs update
doc/examples/ex-client-resume.c: needs update
doc/examples/ex-client-srp.c: needs update
doc/examples/ex-client-tlsia.c: needs update
doc/examples/ex-client1.c: needs update
doc/examples/ex-client2.c: needs update
doc/examples/ex-crq.c: needs update
doc/examples/ex-pkcs12.c: needs update
doc/examples/ex-rfc2818.c: needs update
doc/examples/ex-serv-anon.c: needs update
doc/examples/ex-serv-authz.c: needs update
doc/examples/ex-serv-export.c: needs update
doc/examples/ex-serv-pgp.c: needs update
doc/examples/ex-serv-srp.c: needs update
doc/examples/ex-serv1.c: needs update
doc/examples/ex-session-info.c: needs update
doc/examples/ex-verify.c: needs update
doc/examples/ex-x509-info.c: needs update
doc/examples/tcp.c: needs update
doc/fdl.texi: needs update
doc/gendocs_template: needs update
doc/gnutls-logo.eps: needs update
doc/gnutls-logo.pdf: needs update
doc/gnutls-logo.png: needs update
doc/gnutls.texi: needs update
doc/gpl.texi: needs update
doc/internals.dia: needs update
doc/internals.eps: needs update
doc/internals.pdf: needs update
doc/internals.png: needs update
doc/internals.texi: needs update
doc/layers.dia: needs update
doc/layers.eps: needs update
doc/layers.pdf: needs update
doc/layers.png: needs update
doc/lgpl.texi: needs update
doc/manpages/.cvsignore: needs update
doc/manpages/Makefile.am: needs update
doc/manpages/certtool.1: needs update
doc/manpages/gnutls-cli-debug.1: needs update
doc/manpages/gnutls-cli.1: needs update
doc/manpages/gnutls-serv.1: needs update
doc/manpages/psktool.1: needs update
doc/manpages/srptool.1: needs update
doc/my-bib-macros.texi: needs update
doc/pgp1.dia: needs update
doc/pgp1.eps: needs update
doc/pgp1.pdf: needs update
doc/pgp1.png: needs update
doc/protocol/draft-SP800-52.pdf: needs update
doc/protocol/draft-badra-hajjeh-mtls-00.txt: needs update
doc/protocol/draft-badra-hajjeh-mtls-01.txt: needs update
doc/protocol/draft-badra-tls-express-00.txt: needs update
doc/protocol/draft-badra-tls-key-exchange-00.txt: needs update
doc/protocol/draft-badra-tls-password-00.txt: needs update
doc/protocol/draft-badra-tls-password-ext-00.txt: needs update
doc/protocol/draft-benaloh-pct-00.txt: needs update
doc/protocol/draft-benaloh-pct-01.txt: needs update
doc/protocol/draft-chudov-cryptopro-cptls-02.txt: needs update
doc/protocol/draft-eronen-tls-psk-00.txt: needs update
doc/protocol/draft-freier-ssl-version3-02.txt: needs update
doc/protocol/draft-funk-tls-inner-application-extension-00.txt: needs update
doc/protocol/draft-funk-tls-inner-application-extension-01.txt: needs update
doc/protocol/draft-funk-tls-inner-application-extension-02.txt: needs update
doc/protocol/draft-funk-tls-inner-application-extension-03.txt: needs update
doc/protocol/draft-hajjeh-tls-identity-protection-00.txt: needs update
doc/protocol/draft-hajjeh-tls-sign-00.txt: needs update
doc/protocol/draft-hajjeh-tls-sign-01.txt: needs update
doc/protocol/draft-hajjeh-tls-sign-02.txt: needs update
doc/protocol/draft-hickman-netscape-ssl-00.txt: needs update
doc/protocol/draft-housley-evidence-extns-01.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-00.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-01.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-03.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-04.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-05.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-06.txt: needs update
doc/protocol/draft-housley-tls-authz-extns-07.txt: needs update
doc/protocol/draft-ietf-tls-56-bit-ciphersuites-01.txt: needs update
doc/protocol/draft-ietf-tls-ctr-01.txt: needs update
doc/protocol/draft-ietf-tls-ecc-04.txt: needs update
doc/protocol/draft-ietf-tls-ecc-07.txt: needs update
doc/protocol/draft-ietf-tls-ecc-09.txt: needs update
doc/protocol/draft-ietf-tls-ecc-10.txt: needs update
doc/protocol/draft-ietf-tls-ecc-11.txt: needs update
doc/protocol/draft-ietf-tls-ecc-new-mac-00.txt: needs update
doc/protocol/draft-ietf-tls-emailaddr-00.txt: needs update
doc/protocol/draft-ietf-tls-kerb-01.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-06.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-07.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-08.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-09.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-10.txt: needs update
doc/protocol/draft-ietf-tls-openpgp-keys-11.txt: needs update
doc/protocol/draft-ietf-tls-psk-01.txt: needs update
doc/protocol/draft-ietf-tls-psk-03.txt: needs update
doc/protocol/draft-ietf-tls-psk-04.txt: needs update
doc/protocol/draft-ietf-tls-psk-05.txt: needs update
doc/protocol/draft-ietf-tls-psk-06.txt: needs update
doc/protocol/draft-ietf-tls-psk-09.txt: needs update
doc/protocol/draft-ietf-tls-psk-null-01.txt: needs update
doc/protocol/draft-ietf-tls-psk-null-02.txt: needs update
doc/protocol/draft-ietf-tls-psk-null-03.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-06.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-08.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-09.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-10.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-12.txt: needs update
doc/protocol/draft-ietf-tls-rfc2246-bis-13.txt: needs update
doc/protocol/draft-ietf-tls-rfc3546bis-00.txt: needs update
doc/protocol/draft-ietf-tls-rfc3546bis-01.txt: needs update
doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt: needs update
doc/protocol/draft-ietf-tls-rfc4346-bis-02.txt: needs update
doc/protocol/draft-ietf-tls-rfc4346-bis-03.txt: needs update
doc/protocol/draft-ietf-tls-sharedkeys-02.txt: needs update
doc/protocol/draft-ietf-tls-srp-00.txt: needs update
doc/protocol/draft-ietf-tls-srp-01.txt: needs update
doc/protocol/draft-ietf-tls-srp-02.txt: needs update
doc/protocol/draft-ietf-tls-srp-03.txt: needs update
doc/protocol/draft-ietf-tls-srp-04.txt: needs update
doc/protocol/draft-ietf-tls-srp-05.txt: needs update
doc/protocol/draft-ietf-tls-srp-06.txt: needs update
doc/protocol/draft-ietf-tls-srp-07.txt: needs update
doc/protocol/draft-ietf-tls-srp-08.txt: needs update
doc/protocol/draft-ietf-tls-srp-09.txt: needs update
doc/protocol/draft-ietf-tls-srp-10.txt: needs update
doc/protocol/draft-ietf-tls-srp-11.txt: needs update
doc/protocol/draft-ietf-tls-srp-12.txt: needs update
doc/protocol/draft-ietf-tls-srp-13.txt: needs update
doc/protocol/draft-ietf-tls-ssl-mods-00.txt: needs update
doc/protocol/draft-ietf-tls-suiteb-00.txt: needs update
doc/protocol/draft-lee-tls-seed-01.txt: needs update
doc/protocol/draft-modadugu-tls-ctr-00.txt: needs update
doc/protocol/draft-nir-tee-pm-00.txt: needs update
doc/protocol/draft-otto-tls-sigma-ciphersuite-00.txt: needs update
doc/protocol/draft-rescorla-dtls-02.txt: needs update
doc/protocol/draft-rescorla-dtls-03.txt: needs update
doc/protocol/draft-rescorla-dtls-04.txt: needs update
doc/protocol/draft-rescorla-dtls-05.txt: needs update
doc/protocol/draft-rescorla-tls-extractor-00.txt: needs update
doc/protocol/draft-rescorla-tls-opaque-prf-input-00.txt: needs update
doc/protocol/draft-rescorla-tls-suiteb-00.txt: needs update
doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt: needs update
doc/protocol/draft-salowey-tls-ticket-02.txt: needs update
doc/protocol/draft-salowey-tls-ticket-03.txt: needs update
doc/protocol/draft-salowey-tls-ticket-04.txt: needs update
doc/protocol/draft-salowey-tls-ticket-05.txt: needs update
doc/protocol/draft-salowey-tls-ticket-06.txt: needs update
doc/protocol/draft-salowey-tls-ticket-07.txt: needs update
doc/protocol/draft-santesson-tls-gssapi-01.txt: needs update
doc/protocol/draft-santesson-tls-supp-00.txt: needs update
doc/protocol/draft-santesson-tls-supp-01.txt: needs update
doc/protocol/draft-santesson-tls-supp-02.txt: needs update
doc/protocol/draft-santesson-tls-ume-00.txt: needs update
doc/protocol/draft-santesson-tls-ume-01.txt: needs update
doc/protocol/draft-santesson-tls-ume-02.txt: needs update
doc/protocol/draft-santesson-tls-ume-04.txt: needs update
doc/protocol/draft-santesson-tls-ume-05.txt: needs update
doc/protocol/draft-santesson-tls-ume-06.txt: needs update
doc/protocol/draft-santesson-tls-ume-07.txt: needs update
doc/protocol/rfc1422.txt: needs update
doc/protocol/rfc1423.txt: needs update
doc/protocol/rfc2246.txt: needs update
doc/protocol/rfc2253.txt: needs update
doc/protocol/rfc2279.txt: needs update
doc/protocol/rfc2313.txt: needs update
doc/protocol/rfc2440.txt: needs update
doc/protocol/rfc2631.txt: needs update
doc/protocol/rfc2712.txt: needs update
doc/protocol/rfc2817.txt: needs update
doc/protocol/rfc2818.txt: needs update
doc/protocol/rfc2945.txt: needs update
doc/protocol/rfc2985.txt: needs update
doc/protocol/rfc2986.txt: needs update
doc/protocol/rfc3039.txt: needs update
doc/protocol/rfc3268.txt: needs update
doc/protocol/rfc3279.txt: needs update
doc/protocol/rfc3280.txt: needs update
doc/protocol/rfc3546.txt: needs update
doc/protocol/rfc3749.txt: needs update
doc/protocol/rfc3943.txt: needs update
doc/protocol/rfc4132.txt: needs update
doc/protocol/rfc4158.txt: needs update
doc/protocol/rfc4162.txt: needs update
doc/protocol/rfc4279.txt: needs update
doc/protocol/rfc4346.txt: needs update
doc/protocol/rfc4347.txt: needs update
doc/protocol/rfc4366.txt: needs update
doc/protocol/rfc4507.txt: needs update
doc/protocol/rfc4680.txt: needs update
doc/protocol/rfc4681.txt: needs update
doc/protocol/rfc4785.txt: needs update
doc/protocol/rrc2.doc: needs update
doc/protocol/ssl-version2.txt: needs update
doc/protocol/tls-numbers.txt: needs update
doc/protocol/x509guide.txt: needs update
doc/reference/.cvsignore: needs update
doc/reference/Makefile.am: needs update
doc/reference/gnutls-docs.sgml: needs update
doc/reference/tmpl/.cvsignore: needs update
doc/reference/tmpl/gnutls-unused.sgml: needs update
doc/scripts/.cvsignore: needs update
doc/scripts/Makefile.am: needs update
doc/scripts/gdoc: needs update
doc/scripts/sort2.pl: needs update
doc/signatures.texi: needs update
doc/x509-1.dia: needs update
doc/x509-1.eps: needs update
doc/x509-1.pdf: needs update
doc/x509-1.png: needs update
gl/.cvsignore: needs update
gl/Makefile.am: needs update
gl/error.c: needs update
gl/error.h: needs update
gl/gai_strerror.c: needs update
gl/getaddrinfo.c: needs update
gl/getaddrinfo.h: needs update
gl/getdelim.c: needs update
gl/getdelim.h: needs update
gl/getline.c: needs update
gl/getline.h: needs update
gl/gettext.h: needs update
gl/gnulib.mk: needs update
gl/inet_ntop.c: needs update
gl/inet_ntop.h: needs update
gl/inet_pton.c: needs update
gl/inet_pton.h: needs update
gl/m4/absolute-header.m4: needs update
gl/m4/arpa_inet_h.m4: needs update
gl/m4/error.m4: needs update
gl/m4/extensions.m4: needs update
gl/m4/getaddrinfo.m4: needs update
gl/m4/getdelim.m4: needs update
gl/m4/getline.m4: needs update
gl/m4/gnulib-cache.m4: needs update
gl/m4/gnulib-common.m4: needs update
gl/m4/gnulib-comp.m4: needs update
gl/m4/gnulib-tool.m4: needs update
gl/m4/inet_ntop.m4: needs update
gl/m4/inet_pton.m4: needs update
gl/m4/lib-ld.m4: needs update
gl/m4/lib-link.m4: needs update
gl/m4/lib-prefix.m4: needs update
gl/m4/netinet_in_h.m4: needs update
gl/m4/onceonly_2_57.m4: needs update
gl/m4/readline.m4: needs update
gl/m4/socklen.m4: needs update
gl/m4/sockpfaf.m4: needs update
gl/m4/stdarg.m4: needs update
gl/m4/stdbool.m4: needs update
gl/m4/strdup.m4: needs update
gl/m4/string_h.m4: needs update
gl/m4/sys_socket_h.m4: needs update
gl/netinet_in_.h: needs update
gl/override/doc/gendocs_template.diff: needs update
gl/override/doc/gpl.texi.diff: needs update
gl/override/doc/lgpl.texi.diff: needs update
gl/progname.c: needs update
gl/progname.h: needs update
gl/readline.c: needs update
gl/readline.h: needs update
gl/stdbool_.h: needs update
gl/strdup.c: needs update
gl/string_.h: needs update
gl/sys_socket_.h: needs update
gl/version-etc-fsf.c: needs update
gl/version-etc.c: needs update
gl/version-etc.h: needs update
gtk-doc.make: needs update
includes/.cvsignore: needs update
includes/Makefile.am: needs update
includes/gnutls/.cvsignore: needs update
includes/gnutls/compat.h: needs update
includes/gnutls/extra.h: needs update
includes/gnutls/gnutls.h.in: needs update
includes/gnutls/gnutlsxx.h: needs update
includes/gnutls/openpgp.h: needs update
includes/gnutls/openssl.h: needs update
includes/gnutls/pkcs12.h: needs update
includes/gnutls/x509.h: needs update
lgl/.cvsignore: needs update
lgl/Makefile.am: needs update
lgl/alloca_.h: needs update
lgl/arcfour.c: needs update
lgl/arcfour.h: needs update
lgl/arctwo.c: needs update
lgl/arctwo.h: needs update
lgl/asnprintf.c: needs update
lgl/asprintf.c: needs update
lgl/des.c: needs update
lgl/des.h: needs update
lgl/dummy.c: needs update
lgl/float+.h: needs update
lgl/float_.h: needs update
lgl/fseeko.c: needs update
lgl/gc-gnulib.c: needs update
lgl/gc-libgcrypt.c: needs update
lgl/gc-pbkdf2-sha1.c: needs update
lgl/gc.h: needs update
lgl/getdelim.c: needs update
lgl/getdelim.h: needs update
lgl/getline.c: needs update
lgl/getline.h: needs update
lgl/getpass.c: needs update
lgl/getpass.h: needs update
lgl/gettext.h: needs update
lgl/hmac-md5.c: needs update
lgl/hmac-sha1.c: needs update
lgl/hmac.h: needs update
lgl/m4/absolute-header.m4: needs update
lgl/m4/alloca.m4: needs update
lgl/m4/arcfour.m4: needs update
lgl/m4/arctwo.m4: needs update
lgl/m4/codeset.m4: needs update
lgl/m4/des.m4: needs update
lgl/m4/eoverflow.m4: needs update
lgl/m4/extensions.m4: needs update
lgl/m4/float_h.m4: needs update
lgl/m4/fseeko.m4: needs update
lgl/m4/gc-arcfour.m4: needs update
lgl/m4/gc-arctwo.m4: needs update
lgl/m4/gc-des.m4: needs update
lgl/m4/gc-hmac-md5.m4: needs update
lgl/m4/gc-hmac-sha1.m4: needs update
lgl/m4/gc-md2.m4: needs update
lgl/m4/gc-md4.m4: needs update
lgl/m4/gc-md5.m4: needs update
lgl/m4/gc-pbkdf2-sha1.m4: needs update
lgl/m4/gc-random.m4: needs update
lgl/m4/gc-rijndael.m4: needs update
lgl/m4/gc-sha1.m4: needs update
lgl/m4/gc.m4: needs update
lgl/m4/getdelim.m4: needs update
lgl/m4/getline.m4: needs update
lgl/m4/getpass.m4: needs update
lgl/m4/gettext.m4: needs update
lgl/m4/glibc2.m4: needs update
lgl/m4/glibc21.m4: needs update
lgl/m4/gnulib-cache.m4: needs update
lgl/m4/gnulib-common.m4: needs update
lgl/m4/gnulib-comp.m4: needs update
lgl/m4/gnulib-tool.m4: needs update
lgl/m4/hmac-md5.m4: needs update
lgl/m4/hmac-sha1.m4: needs update
lgl/m4/iconv.m4: needs update
lgl/m4/intdiv0.m4: needs update
lgl/m4/intl.m4: needs update
lgl/m4/intldir.m4: needs update
lgl/m4/intmax.m4: needs update
lgl/m4/intmax_t.m4: needs update
lgl/m4/inttypes-pri.m4: needs update
lgl/m4/inttypes_h.m4: needs update
lgl/m4/lcmessage.m4: needs update
lgl/m4/lib-ld.m4: needs update
lgl/m4/lib-link.m4: needs update
lgl/m4/lib-prefix.m4: needs update
lgl/m4/lock.m4: needs update
lgl/m4/longlong.m4: needs update
lgl/m4/md2.m4: needs update
lgl/m4/md4.m4: needs update
lgl/m4/md5.m4: needs update
lgl/m4/memmem.m4: needs update
lgl/m4/memmove.m4: needs update
lgl/m4/memxor.m4: needs update
lgl/m4/minmax.m4: needs update
lgl/m4/nls.m4: needs update
lgl/m4/po.m4: needs update
lgl/m4/printf-posix.m4: needs update
lgl/m4/progtest.m4: needs update
lgl/m4/read-file.m4: needs update
lgl/m4/rijndael.m4: needs update
lgl/m4/sha1.m4: needs update
lgl/m4/size_max.m4: needs update
lgl/m4/snprintf.m4: needs update
lgl/m4/socklen.m4: needs update
lgl/m4/sockpfaf.m4: needs update
lgl/m4/stdbool.m4: needs update
lgl/m4/stdint.m4: needs update
lgl/m4/stdint_h.m4: needs update
lgl/m4/stdio_h.m4: needs update
lgl/m4/string_h.m4: needs update
lgl/m4/strverscmp.m4: needs update
lgl/m4/sys_socket_h.m4: needs update
lgl/m4/sys_stat_h.m4: needs update
lgl/m4/time_h.m4: needs update
lgl/m4/time_r.m4: needs update
lgl/m4/uintmax_t.m4: needs update
lgl/m4/ulonglong.m4: needs update
lgl/m4/unistd_h.m4: needs update
lgl/m4/vasnprintf.m4: needs update
lgl/m4/vasprintf.m4: needs update
lgl/m4/visibility.m4: needs update
lgl/m4/wchar.m4: needs update
lgl/m4/wchar_t.m4: needs update
lgl/m4/wint_t.m4: needs update
lgl/m4/xsize.m4: needs update
lgl/md2.c: needs update
lgl/md2.h: needs update
lgl/md4.c: needs update
lgl/md4.h: needs update
lgl/md5.c: needs update
lgl/md5.h: needs update
lgl/memmem.c: needs update
lgl/memmove.c: needs update
lgl/memxor.c: needs update
lgl/memxor.h: needs update
lgl/minmax.h: needs update
lgl/printf-args.c: needs update
lgl/printf-args.h: needs update
lgl/printf-parse.c: needs update
lgl/printf-parse.h: needs update
lgl/read-file.c: needs update
lgl/read-file.h: needs update
lgl/rijndael-alg-fst.c: needs update
lgl/rijndael-alg-fst.h: needs update
lgl/rijndael-api-fst.c: needs update
lgl/rijndael-api-fst.h: needs update
lgl/sha1.c: needs update
lgl/sha1.h: needs update
lgl/size_max.h: needs update
lgl/snprintf.c: needs update
lgl/stdbool_.h: needs update
lgl/stdint_.h: needs update
lgl/stdio_.h: needs update
lgl/string_.h: needs update
lgl/strverscmp.c: needs update
lgl/strverscmp.h: needs update
lgl/sys_socket_.h: needs update
lgl/sys_stat_.h: needs update
lgl/time_.h: needs update
lgl/time_r.c: needs update
lgl/unistd_.h: needs update
lgl/vasnprintf.c: needs update
lgl/vasnprintf.h: needs update
lgl/vasprintf.c: needs update
lgl/wchar_.h: needs update
lgl/xsize.h: needs update
lib/.cvsignore: needs update
lib/Makefile.am: needs update
lib/auth_anon.c: needs update
lib/auth_anon.h: needs update
lib/auth_cert.c: needs update
lib/auth_cert.h: needs update
lib/auth_dh_common.c: needs update
lib/auth_dh_common.h: needs update
lib/auth_dhe.c: needs update
lib/auth_dhe_psk.c: needs update
lib/auth_psk.c: needs update
lib/auth_psk.h: needs update
lib/auth_psk_passwd.c: needs update
lib/auth_psk_passwd.h: needs update
lib/auth_rsa.c: needs update
lib/auth_rsa_export.c: needs update
lib/auth_srp.c: needs update
lib/auth_srp.h: needs update
lib/auth_srp_passwd.c: needs update
lib/auth_srp_passwd.h: needs update
lib/auth_srp_rsa.c: needs update
lib/auth_srp_sb64.c: needs update
lib/debug.c: needs update
lib/debug.h: needs update
lib/defines.h: needs update
lib/ext_authz.c: needs update
lib/ext_authz.h: needs update
lib/ext_cert_type.c: needs update
lib/ext_cert_type.h: needs update
lib/ext_inner_application.c: needs update
lib/ext_inner_application.h: needs update
lib/ext_max_record.c: needs update
lib/ext_max_record.h: needs update
lib/ext_server_name.c: needs update
lib/ext_server_name.h: needs update
lib/ext_srp.c: needs update
lib/ext_srp.h: needs update
lib/gnutls.asn: needs update
lib/gnutls.pc.in: needs update
lib/gnutls_alert.c: needs update
lib/gnutls_algorithms.c: needs update
lib/gnutls_algorithms.h: needs update
lib/gnutls_anon_cred.c: needs update
lib/gnutls_asn1_tab.c: needs update
lib/gnutls_auth.c: needs update
lib/gnutls_auth.h: needs update
lib/gnutls_auth_int.h: needs update
lib/gnutls_buffer.h: needs update
lib/gnutls_buffers.c: needs update
lib/gnutls_buffers.h: needs update
lib/gnutls_cert.c: needs update
lib/gnutls_cert.h: needs update
lib/gnutls_cipher.c: needs update
lib/gnutls_cipher.h: needs update
lib/gnutls_cipher_int.c: needs update
lib/gnutls_cipher_int.h: needs update
lib/gnutls_compress.c: needs update
lib/gnutls_compress.h: needs update
lib/gnutls_compress_int.c: needs update
lib/gnutls_compress_int.h: needs update
lib/gnutls_constate.c: needs update
lib/gnutls_constate.h: needs update
lib/gnutls_datum.c: needs update
lib/gnutls_datum.h: needs update
lib/gnutls_db.c: needs update
lib/gnutls_db.h: needs update
lib/gnutls_dh.c: needs update
lib/gnutls_dh.h: needs update
lib/gnutls_dh_primes.c: needs update
lib/gnutls_errors.c: needs update
lib/gnutls_errors.h: needs update
lib/gnutls_extensions.c: needs update
lib/gnutls_extensions.h: needs update
lib/gnutls_extra_hooks.c: needs update
lib/gnutls_extra_hooks.h: needs update
lib/gnutls_global.c: needs update
lib/gnutls_global.h: needs update
lib/gnutls_handshake.c: needs update
lib/gnutls_handshake.h: needs update
lib/gnutls_hash_int.c: needs update
lib/gnutls_hash_int.h: needs update
lib/gnutls_helper.c: needs update
lib/gnutls_helper.h: needs update
lib/gnutls_int.h: needs update
lib/gnutls_kx.c: needs update
lib/gnutls_kx.h: needs update
lib/gnutls_mem.c: needs update
lib/gnutls_mem.h: needs update
lib/gnutls_mpi.c: needs update
lib/gnutls_mpi.h: needs update
lib/gnutls_num.c: needs update
lib/gnutls_num.h: needs update
lib/gnutls_pk.c: needs update
lib/gnutls_pk.h: needs update
lib/gnutls_priority.c: needs update
lib/gnutls_psk.c: needs update
lib/gnutls_record.c: needs update
lib/gnutls_record.h: needs update
lib/gnutls_rsa_export.c: needs update
lib/gnutls_rsa_export.h: needs update
lib/gnutls_session.c: needs update
lib/gnutls_session.h: needs update
lib/gnutls_session_pack.c: needs update
lib/gnutls_session_pack.h: needs update
lib/gnutls_sig.c: needs update
lib/gnutls_sig.h: needs update
lib/gnutls_srp.c: needs update
lib/gnutls_srp.h: needs update
lib/gnutls_state.c: needs update
lib/gnutls_state.h: needs update
lib/gnutls_str.c: needs update
lib/gnutls_str.h: needs update
lib/gnutls_supplemental.c: needs update
lib/gnutls_supplemental.h: needs update
lib/gnutls_ui.c: needs update
lib/gnutls_v2_compat.c: needs update
lib/gnutls_v2_compat.h: needs update
lib/gnutls_x509.c: needs update
lib/gnutls_x509.h: needs update
lib/gnutlsxx.cpp: needs update
lib/io_debug.h: needs update
lib/libgnutls-config.in: needs update
lib/libgnutls.m4: needs update
lib/libgnutls.vers: needs update
lib/libgnutlsxx.vers: needs update
lib/minitasn1/.cvsignore: needs update
lib/minitasn1/Makefile.am: needs update
lib/minitasn1/README: needs update
lib/minitasn1/coding.c: needs update
lib/minitasn1/decoding.c: needs update
lib/minitasn1/element.c: needs update
lib/minitasn1/element.h: needs update
lib/minitasn1/errors.c: needs update
lib/minitasn1/errors.h: needs update
lib/minitasn1/gstr.c: needs update
lib/minitasn1/gstr.h: needs update
lib/minitasn1/int.h: needs update
lib/minitasn1/libtasn1.h: needs update
lib/minitasn1/mem.h: needs update
lib/minitasn1/parser_aux.c: needs update
lib/minitasn1/parser_aux.h: needs update
lib/minitasn1/structure.c: needs update
lib/minitasn1/structure.h: needs update
lib/pkix.asn: needs update
lib/pkix_asn1_tab.c: needs update
lib/x509/.cvsignore: needs update
lib/x509/Makefile.am: needs update
lib/x509/common.c: needs update
lib/x509/common.h: needs update
lib/x509/crl.c: needs update
lib/x509/crl_write.c: needs update
lib/x509/crq.c: needs update
lib/x509/crq.h: needs update
lib/x509/dn.c: needs update
lib/x509/dn.h: needs update
lib/x509/dsa.c: needs update
lib/x509/dsa.h: needs update
lib/x509/extensions.c: needs update
lib/x509/extensions.h: needs update
lib/x509/mpi.c: needs update
lib/x509/mpi.h: needs update
lib/x509/output.c: needs update
lib/x509/pkcs12.c: needs update
lib/x509/pkcs12.h: needs update
lib/x509/pkcs12_bag.c: needs update
lib/x509/pkcs12_encr.c: needs update
lib/x509/pkcs7.c: needs update
lib/x509/pkcs7.h: needs update
lib/x509/privkey.c: needs update
lib/x509/privkey.h: needs update
lib/x509/privkey_pkcs8.c: needs update
lib/x509/rfc2818.h: needs update
lib/x509/rfc2818_hostname.c: needs update
lib/x509/sign.c: needs update
lib/x509/sign.h: needs update
lib/x509/verify.c: needs update
lib/x509/verify.h: needs update
lib/x509/x509.c: needs update
lib/x509/x509.h: needs update
lib/x509/x509_write.c: needs update
lib/x509/xml.c: needs update
lib/x509_b64.c: needs update
lib/x509_b64.h: needs update
libextra/.cvsignore: needs update
libextra/Makefile.am: needs update
libextra/gnutls-extra.pc.in: needs update
libextra/gnutls_extra.c: needs update
libextra/gnutls_extra.h: needs update
libextra/gnutls_ia.c: needs update
libextra/gnutls_openpgp.c: needs update
libextra/gnutls_openssl.c: needs update
libextra/libgnutls-extra-config.in: needs update
libextra/libgnutls-extra.m4: needs update
libextra/libgnutls-extra.vers: needs update
libextra/minilzo/.cvsignore: needs update
libextra/minilzo/Makefile.am: needs update
libextra/minilzo/README.LZO: needs update
libextra/minilzo/lzoconf.h: needs update
libextra/minilzo/lzodefs.h: needs update
libextra/minilzo/minilzo.c: needs update
libextra/minilzo/minilzo.h: needs update
libextra/minilzo/testmini.c: needs update
libextra/opencdk/.cvsignore: needs update
libextra/opencdk/Makefile.am: needs update
libextra/opencdk/README: needs update
libextra/opencdk/armor.c: needs update
libextra/opencdk/cipher.c: needs update
libextra/opencdk/compress.c: needs update
libextra/opencdk/context.h: needs update
libextra/opencdk/dummy.c: needs update
libextra/opencdk/filters.h: needs update
libextra/opencdk/kbnode.c: needs update
libextra/opencdk/keydb.c: needs update
libextra/opencdk/literal.c: needs update
libextra/opencdk/main.c: needs update
libextra/opencdk/main.h: needs update
libextra/opencdk/misc.c: needs update
libextra/opencdk/new-packet.c: needs update
libextra/opencdk/opencdk.h: needs update
libextra/opencdk/packet.h: needs update
libextra/opencdk/pubkey.c: needs update
libextra/opencdk/read-packet.c: needs update
libextra/opencdk/seskey.c: needs update
libextra/opencdk/sig-check.c: needs update
libextra/opencdk/stream.c: needs update
libextra/opencdk/stream.h: needs update
libextra/opencdk/types.h: needs update
libextra/opencdk/verify.c: needs update
libextra/opencdk/write-packet.c: needs update
libextra/openpgp/.cvsignore: needs update
libextra/openpgp/Makefile.am: needs update
libextra/openpgp/compat.c: needs update
libextra/openpgp/extras.c: needs update
libextra/openpgp/gnutls_openpgp.h: needs update
libextra/openpgp/openpgp.h: needs update
libextra/openpgp/pgp.c: needs update
libextra/openpgp/pgpverify.c: needs update
libextra/openpgp/privkey.c: needs update
libextra/openpgp/xml.c: needs update
libextra/openssl_compat.c: needs update
libextra/openssl_compat.h: needs update
m4/.cvsignore: needs update
m4/autobuild.m4: needs update
m4/ax_create_stdint_h.m4: needs update
m4/gc_random.m4: needs update
m4/gtk-doc.m4: needs update
m4/libgcrypt.m4: needs update
m4/libtasn1.m4: needs update
maint-cfg.mk: needs update
po/.cvsignore: needs update
po/LINGUAS: needs update
po/Makevars: needs update
po/POTFILES.in: needs update
po/de.po: needs update
po/pl.po: needs update
po/sv.po: needs update
src/.cvsignore: needs update
src/Makefile.am: needs update
src/README: needs update
src/README.srptool: needs update
src/certtool-cfg.c: needs update
src/certtool-cfg.h: needs update
src/certtool-gaa.c: needs update
src/certtool-gaa.h: needs update
src/certtool.c: needs update
src/certtool.gaa: needs update
src/cfg/.cvsignore: needs update
src/cfg/Makefile.am: needs update
src/cfg/cfg+.c: needs update
src/cfg/cfg+.h: needs update
src/cfg/cfgfile.c: needs update
src/cfg/cfgfile.h: needs update
src/cfg/cmdline.c: needs update
src/cfg/cmdline.h: needs update
src/cfg/parse.c: needs update
src/cfg/platon/.cvsignore: needs update
src/cfg/platon/Makefile.am: needs update
src/cfg/platon/str/.cvsignore: needs update
src/cfg/platon/str/Makefile.am: needs update
src/cfg/platon/str/dynfgets.c: needs update
src/cfg/platon/str/dynfgets.h: needs update
src/cfg/platon/str/strctype.c: needs update
src/cfg/platon/str/strctype.h: needs update
src/cfg/platon/str/strdyn.c: needs update
src/cfg/platon/str/strdyn.h: needs update
src/cfg/platon/str/strplus.c: needs update
src/cfg/platon/str/strplus.h: needs update
src/cfg/props.c: needs update
src/cfg/shared.c: needs update
src/cfg/shared.h: needs update
src/cli-gaa.c: needs update
src/cli-gaa.h: needs update
src/cli.c: needs update
src/cli.gaa: needs update
src/common.c: needs update
src/common.h: needs update
src/crypt-gaa.c: needs update
src/crypt-gaa.h: needs update
src/crypt.c: needs update
src/crypt.gaa: needs update
src/errcodes.c: needs update
src/gnutls-http-serv: needs update
src/list.h: needs update
src/openpgp/.cvsignore: needs update
src/openpgp/Makefile.am: needs update
src/openpgp/cli_pub.asc: needs update
src/openpgp/cli_ring.asc: needs update
src/openpgp/cli_ring.gpg: needs update
src/openpgp/cli_sec.asc: needs update
src/openpgp/pub.asc: needs update
src/openpgp/sec.asc: needs update
src/params.pem: needs update
src/pkcs1.asn: needs update
src/prime.c: needs update
src/psk-gaa.c: needs update
src/psk-gaa.h: needs update
src/psk.c: needs update
src/psk.gaa: needs update
src/select.c: needs update
src/serv-gaa.c: needs update
src/serv-gaa.h: needs update
src/serv.c: needs update
src/serv.gaa: needs update
src/srp/.cvsignore: needs update
src/srp/Makefile.am: needs update
src/srp/tpasswd: needs update
src/srp/tpasswd.conf: needs update
src/tests.c: needs update
src/tests.h: needs update
src/tls_test-gaa.c: needs update
src/tls_test-gaa.h: needs update
src/tls_test.c: needs update
src/tls_test.gaa: needs update
src/x509/.cvsignore: needs update
src/x509/Makefile.am: needs update
src/x509/ca.pem: needs update
src/x509/cert-dsa.pem: needs update
src/x509/cert.pem: needs update
src/x509/clicert-dsa.pem: needs update
src/x509/clicert.pem: needs update
src/x509/clikey-dsa.pem: needs update
src/x509/clikey.pem: needs update
src/x509/key-dsa.pem: needs update
src/x509/key.pem: needs update
tests/.cvsignore: needs update
tests/Makefile.am: needs update
tests/anonself.c: needs update
tests/ca.pem: needs update
tests/certder.c: needs update
tests/certificate_set_x509_crl.c: needs update
tests/dhepskself.c: needs update
tests/dn.c: needs update
tests/enc3pkcs8.pem: needs update
tests/gc.c: needs update
tests/hostname-check/.cvsignore: needs update
tests/hostname-check/Makefile.am: needs update
tests/hostname-check/README: needs update
tests/hostname-check/hostname-check.c: needs update
tests/key-id/.cvsignore: needs update
tests/key-id/Makefile.am: needs update
tests/key-id/README: needs update
tests/key-id/ca-gnutls-keyid.pem: needs update
tests/key-id/ca-no-keyid.pem: needs update
tests/key-id/ca-weird-keyid.pem: needs update
tests/key-id/key-ca.pem: needs update
tests/key-id/key-id: needs update
tests/key-id/key-user.pem: needs update
tests/nist-pkits/.cvsignore: needs update
tests/nist-pkits/PKITS.pdf: needs update
tests/nist-pkits/PKITS_data.zip: needs update
tests/nist-pkits/README: needs update
tests/nist-pkits/build-chain: needs update
tests/nist-pkits/gnutls-nist-tests.html: needs update
tests/nist-pkits/gnutls_test_entry: needs update
tests/nist-pkits/pkits: needs update
tests/nist-pkits/pkits_crl: needs update
tests/nist-pkits/pkits_crt: needs update
tests/nist-pkits/pkits_pkcs12: needs update
tests/nist-pkits/pkits_smime: needs update
tests/nist-pkits/pkits_test: needs update
tests/nist-pkits/pkits_test_list_generator.patch: needs update
tests/nist-pkits/pkits_test_list_generator.tgz: needs update
tests/openpgp/Makefile.am: needs update
tests/openpgp/keyring.c: needs update
tests/openpgp_test.c: needs update
tests/openssl.c: needs update
tests/pathlen/.cvsignore: needs update
tests/pathlen/Makefile.am: needs update
tests/pathlen/ca-no-pathlen.pem: needs update
tests/pathlen/no-ca-or-pathlen.pem: needs update
tests/pathlen/pathlen: needs update
tests/pkcs1-padding/.cvsignore: needs update
tests/pkcs1-padding/Makefile.am: needs update
tests/pkcs1-padding/pkcs1-pad: needs update
tests/pkcs1-padding/pkcs1-pad-broken.pem: needs update
tests/pkcs1-padding/pkcs1-pad-broken2.pem: needs update
tests/pkcs1-padding/pkcs1-pad-broken3.pem: needs update
tests/pkcs1-padding/pkcs1-pad-ok.pem: needs update
tests/pkcs1-padding/pkcs1-pad-ok2.pem: needs update
tests/pkcs12-decode/.cvsignore: needs update
tests/pkcs12-decode/Makefile.am: needs update
tests/pkcs12-decode/client.p12: needs update
tests/pkcs12-decode/noclient.p12: needs update
tests/pkcs12-decode/pkcs12: needs update
tests/pkcs12-decode/unclient.p12: needs update
tests/pkcs8-decode/.cvsignore: needs update
tests/pkcs8-decode/Makefile.am: needs update
tests/pkcs8-decode/enc2pkcs8.pem: needs update
tests/pkcs8-decode/encpkcs8.pem: needs update
tests/pkcs8-decode/pkcs8: needs update
tests/pkcs8-decode/unencpkcs8.pem: needs update
tests/pskself.c: needs update
tests/resume.c: needs update
tests/rsa-md5-collision/.cvsignore: needs update
tests/rsa-md5-collision/MD5CollisionCA.cer: needs update
tests/rsa-md5-collision/Makefile.am: needs update
tests/rsa-md5-collision/README: needs update
tests/rsa-md5-collision/TargetCollidingCertificate1.cer: needs update
tests/rsa-md5-collision/TargetCollidingCertificate2.cer: needs update
tests/rsa-md5-collision/mbox: needs update
tests/rsa-md5-collision/rsa-md5-collision: needs update
tests/set_pkcs12_cred.c: needs update
tests/sha2/.cvsignore: needs update
tests/sha2/Makefile.am: needs update
tests/sha2/key-ca.pem: needs update
tests/sha2/key-subca.pem: needs update
tests/sha2/key-subsubca.pem: needs update
tests/sha2/key-user.pem: needs update
tests/sha2/sha2: needs update
tests/simple.c: needs update
tests/test1.pem: needs update
tests/test10.pem: needs update
tests/test13.pem: needs update
tests/test2.pem: needs update
tests/test20.pem: needs update
tests/test21.pem: needs update
tests/test22.pem: needs update
tests/test23.pem: needs update
tests/test24.pem: needs update
tests/test25.pem: needs update
tests/test26.pem: needs update
tests/test3.pem: needs update
tests/tlsia.c: needs update
tests/userid/.cvsignore: needs update
tests/userid/Makefile.am: needs update
tests/userid/userid: needs update
tests/userid/userid.pem: needs update
tests/utils.c: needs update
tests/utils.h: needs update
tests/x509_test.c: needs update
tests/x509paths/.cvsignore: needs update
tests/x509paths/Certificate Path Validation Testing.pdf: needs update
tests/x509paths/README: needs update
tests/x509paths/chain: needs update
tests/x509paths/x509tests.tgz: needs update
fatal: Entry 'ChangeLog' would be overwritten by merge. Cannot merge.
Merge with strategy recursive failed.
Could not merge origin into the current branch.


From simon at josefsson.org  Thu Jun 14 09:06:44 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 09:06:44 +0200
Subject: [gnutls-dev] [PATCH] Fix use of uninitialized variable in
	`gnutls_certificate_set_openpgp_key_mem ()'
In-Reply-To: <87wsy792eo.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 13 Jun 2007 19:42:39 +0200")
References: <87wsy792eo.fsf@chbouib.org>
Message-ID: <87wsy7f20r.fsf@mocca.josefsson.org>

Thanks, applied.

For some reason, 'git-am' seems to have garbled your name in git-log.  I
saved the e-mail as UTF-8, and used 'git-am -s < foo' to apply the
patch.  I wonder if this is a git bug... my locale is UTF-8, so I think
it should work.

/Simon

ludo at chbouib.org (Ludovic Court?s) writes:

> * libextra/gnutls_openpgp.c (stream_to_datum): Check whether INP is NULL
>   rather than checking BUF (which is not initialized yet).
> ---
>  libextra/gnutls_openpgp.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libextra/gnutls_openpgp.c b/libextra/gnutls_openpgp.c
> index ddbbfc9..7ed57da 100644
> --- a/libextra/gnutls_openpgp.c
> +++ b/libextra/gnutls_openpgp.c
> @@ -528,7 +528,7 @@ stream_to_datum (cdk_stream_t inp, gnutls_datum_t * raw)
>    uint8_t *buf;
>    size_t buflen;
>  
> -  if (!buf || !raw)
> +  if (!inp || !raw)
>      {
>        gnutls_assert ();
>        return GNUTLS_E_INVALID_REQUEST;
> -- 
> 1.4.4.4


From simon at josefsson.org  Thu Jun 14 09:07:10 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 09:07:10 +0200
Subject: [gnutls-dev] [PATCH] Fix off-by-one in TLS 1.2 handshake.
In-Reply-To: <873b0vah0a.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 13 Jun 2007 19:41:57 +0200")
References: <873b0vah0a.fsf@chbouib.org>
Message-ID: <87sl8vf201.fsf@mocca.josefsson.org>

Thanks, applied.

ludo at chbouib.org (Ludovic Court?s) writes:

> * lib/auth_cert.c (_gnutls_gen_cert_server_cert_req): Before invoking
>   `gnutls_malloc ()', increment SIZE when using TLS 1.2 so that the
>   allocated buffer is large-enough to contain the list of supported
>   hashes.  Don't change SIZE later on.
> ---
>  lib/auth_cert.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/lib/auth_cert.c b/lib/auth_cert.c
> index 9114f09..f91c71c 100644
> --- a/lib/auth_cert.c
> +++ b/lib/auth_cert.c
> @@ -1417,6 +1417,11 @@ _gnutls_gen_cert_server_cert_req (gnutls_session_t session, opaque ** data)
>        session->internals.ignore_rdn_sequence == 0)
>      size += cred->x509_rdn_sequence.size;
>  
> +  if (ver == GNUTLS_TLS1_2)
> +    /* Need at least one byte to announce the number of supported hash
> +       functions (see below).  */
> +    size += 1;
> +
>    (*data) = gnutls_malloc (size);
>    pdata = (*data);
>  
> @@ -1436,7 +1441,7 @@ _gnutls_gen_cert_server_cert_req (gnutls_session_t session, opaque ** data)
>      {
>        /* Supported hashes (nothing for now -- FIXME). */
>        *pdata = 0;
> -      pdata++, size++;
> +      pdata++;
>      }
>  
>    if (session->security_parameters.cert_type == GNUTLS_CRT_X509 &&
> -- 
> 1.4.4.4


From ludovic.courtes at laas.fr  Thu Jun 14 10:15:47 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 14 Jun 2007 10:15:47 +0200
Subject: [gnutls-dev] [PATCH] Fix use of uninitialized variable
	in	`gnutls_certificate_set_openpgp_key_mem ()'
References: <87wsy792eo.fsf@chbouib.org> <46704095.3080207@gmx.net>
Message-ID: <87wsy73qa4.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> But I'm not sure if the CVS is used any longer. I currently have no git
> installed and thus I still use the CVS repository. Is this okay?

I think Simon no longer uses it.  From his previous messages on this
topic, the idea is to eventually use `git-cvsserver' to set up a CVS
proxy to the Git repository.

Thanks,
Ludovic.



From simon at josefsson.org  Thu Jun 14 11:11:32 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 11:11:32 +0200
Subject: [gnutls-dev] Guile needs 1.8?
Message-ID: <87k5u6dhob.fsf@mocca.josefsson.org>

I just installed gnucash on my machine, which for some reason depends on
guile-1.6-dev, and that caused guile-1.8-dev that I had installed before
to be removed.  GnuTLS stopped building:

make[4]: Entering directory `/home/jas/src/gnutls/guile/src'
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../.. -I.  -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -I/usr/local/include  -I/usr/local/include -Wno-strict-prototypes -I../../lgl -I../../lgl  -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -MT libguile_gnutls_v_0_la-core.lo -MD -MP -MF .deps/libguile_gnutls_v_0_la-core.Tpo -c -o libguile_gnutls_v_0_la-core.lo `test -f 'core.c' || echo './'`core.c
mkdir .libs
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I. -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -I/usr/local/include -I/usr/local/include -Wno-strict-prototypes -I../../lgl -I../../lgl -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -MT libguile_gnutls_v_0_la-core.lo -MD -MP -MF .deps/libguile_gnutls_v_0_la-core.Tpo -c core.c  -fPIC -DPIC -o .libs/libguile_gnutls_v_0_la-core.o
In file included from core.c:27:
enums.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'scm_t_bits'
enums.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SCM'
enums.h: In function 'scm_to_gnutls_cipher':
enums.h:14: error: 'scm_tc16_gnutls_cipher_enum' undeclared (first use in this function)
enums.h:14: error: (Each undeclared identifier is reported only once
enums.h:14: error: for each function it appears in.)
enums.h: In function 'scm_from_gnutls_cipher':
enums.h:22: error: 'scm_gnutls_cipher_enum_values' undeclared (first use in this function)
...

If guile-1.8-dev is required, would it be possible for configure to test
for this?  Ludovic?

/Simon


From ludovic.courtes at laas.fr  Thu Jun 14 15:53:50 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 14 Jun 2007 15:53:50 +0200
Subject: [gnutls-dev] Guile needs 1.8?
References: <87k5u6dhob.fsf@mocca.josefsson.org>
Message-ID: <87lkemwsk1.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> If guile-1.8-dev is required, would it be possible for configure to test
> for this?  Ludovic?

Yes, 1.8 is required.  I'd expect the `guile-snarf' detection to fail
with 1.6, though.

I'll add a more reliable test anyway.

Thanks,
Ludovic.



From wk at gnupg.org  Thu Jun 14 18:36:51 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jun 2007 18:36:51 +0200
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <20070613174539.GA4058@downhill.g.la> (Andreas Metzler's message
	of "Wed, 13 Jun 2007 19:45:39 +0200")
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
Message-ID: <87sl8u5w7w.fsf@wheatstone.g10code.de>

On Wed, 13 Jun 2007 19:45, ametzler at downhill.at.eu.org said:

> OpenSSL also simply seems pulls less bytes from the device for doing
> the same thing. "certtool --generate-dh-params --bits 1024" almost
> completely depletes the entropy pool, (down from 3596 to 143 bytes[1]
> according to /proc/sys/kernel/random/entropy_avail, while the

That is indeed a lot.  gnutls uses libgcrypt and luibcgrypt rquires that
its internal random pool gets filled with enough high quality random;
i.e. 600 bytes.  That should be sufficient for creating a secret prime
but it depends on how it is implemented.  


Salam-Shalom,

   Werner




From simon at josefsson.org  Thu Jun 14 18:50:41 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 14 Jun 2007 18:50:41 +0200
Subject: [gnutls-dev] Guile needs 1.8?
In-Reply-To: <87lkemwsk1.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 14
	Jun 2007 15:53:50 +0200")
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
Message-ID: <87zm328opq.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> If guile-1.8-dev is required, would it be possible for configure to test
>> for this?  Ludovic?
>
> Yes, 1.8 is required.  I'd expect the `guile-snarf' detection to fail
> with 1.6, though.

It seems to be part of 1.6 too:

jas at mocca:~$ dpkg -S /usr/bin/guile-snarf
guile-1.6-dev: /usr/bin/guile-snarf
jas at mocca:~$ guile-snarf
/* cpp arguments:  */
i486-linux-gnu-gcc: no input files
jas at mocca:~$

> I'll add a more reliable test anyway.

Thanks.  Perhaps a test for the feature that seems to break things here?
SCM_API, scm_t_bits, or whatever it might have been.

/Simon


From wk at gnupg.org  Thu Jun 14 18:50:43 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 14 Jun 2007 18:50:43 +0200
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <1181768094.3138.106.camel@laptop.alexhudson.com> (Alex Hudson's
	message of "Wed, 13 Jun 2007 21:54:54 +0100")
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
	<1181768094.3138.106.camel@laptop.alexhudson.com>
Message-ID: <87odji5vks.fsf@wheatstone.g10code.de>

On Wed, 13 Jun 2007 22:54, home at alexhudson.com said:

> different solutions, like symlinking /dev/random to /dev/urandom (in
> fact, one of our developers does this as well, because his machine
> simply doesn't generate enough entropy and he can't do anything :)

Libgcrypt tries to be as safe as possible and thus it is slow by
default.  Having a random seed file definitely helps but when creating
key material using a random level of GCRY_VERY_STRONG_RANDOM it requires
that half the pool is updated with /dev/random bytes.

For an embedded platform it might make sense to build libgcrypt with the
names of the random devices both set to /dev/urandom.  It depends on
your application.

Libgcrypt has a feature which might be helpful:

        gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

This is used early at program startup to degrade the require random for
key generation down to the standard level.  We use this only for the
regression tests but it is an official feature.

Libgcrypt 1.3 yields better performance in the prime number generation
by saving unused pime candidates[1].  This should also have a positive
effect on the amount of random required.


Shalom-Salam,

   Werner


[1] In Libgcrypt primes are composed from smaller primes and these
smaller primes are saved for later use.




From ametzler at downhill.at.eu.org  Thu Jun 14 19:12:42 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 14 Jun 2007 19:12:42 +0200
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <1181768094.3138.106.camel@laptop.alexhudson.com>
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
	<1181768094.3138.106.camel@laptop.alexhudson.com>
Message-ID: <20070614171242.GA3713@downhill.g.la>

On 2007-06-13 Alex Hudson <home at alexhudson.com> wrote:
> On Wed, 2007-06-13 at 19:45 +0200, Andreas Metzler wrote:
> > OpenSSL usually is built to use /dev/urandom instead of /dev/random
> > which does not block if you are out of entropy.

> Ah, ok. Does GNUTLS _always_ use /dev/random, or does it depend on what
> you're doing? And is that documented, do you know?
[...]

Hello,
as Werner noted it is not gnutls itself but libgcrypt that does the
actual reading from /dev/random. Afaict libgcrypt only uses
/dev/urandom if /dev/random is not readable.
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 home at alexhudson.com  Thu Jun 14 19:19:00 2007
From: home at alexhudson.com (Alex Hudson)
Date: Thu, 14 Jun 2007 18:19:00 +0100
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <87odji5vks.fsf@wheatstone.g10code.de>
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
	<1181768094.3138.106.camel@laptop.alexhudson.com>
	<87odji5vks.fsf@wheatstone.g10code.de>
Message-ID: <1181841540.3138.136.camel@laptop.alexhudson.com>

Hi Werner,

Thank you very much for your helpful response.

On Thu, 2007-06-14 at 18:50 +0200, Werner Koch wrote:
> For an embedded platform it might make sense to build libgcrypt with the
> names of the random devices both set to /dev/urandom.  It depends on
> your application.

I think our main problem is that many servers will behave a bit like
embedded devices in terms of lack of randomness: some of them rarely do
disk i/o, which seems to be their only source of real entropy. However,
in our situation, we want our software to work on standard GNU/Linux
distributions, so we can't really ship our own libgcrypt without
creating worse problems.

> Libgcrypt has a feature which might be helpful:
> 
>         gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
> 
> This is used early at program startup to degrade the require random for
> key generation down to the standard level.  We use this only for the
> regression tests but it is an official feature.

I hadn't seen this before, thanks. However, in the manual it does say:

        "This command activates the use of a highly-insecure, but fast
        PRNG. It can only be used at initialization time. The only
        useful applications for this are certain regression tests."

If we used GNUTLS with this turned on, would GNUTLS be working in much
the same way as OpenSSL does (wrt. cert generation, etc.), or would it
be a worse position? 

It sounds like this is an option we could offer our users, but I'd like
to make clear the actual risk this poses. From my point of view, the
risk is that the PRNG is predictable and therefore the certs. created
could be guessed. To me, that doesn't sound like a big risk (it would
probably be easier to steal the mail server), but the manual statement
is very strong ("highly-insecure"). Is the manual being very paranoid,
or is there a real risk here?

Thanks again,

Alex.



From wk at gnupg.org  Fri Jun 15 09:28:01 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 15 Jun 2007 09:28:01 +0200
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <1181841540.3138.136.camel@laptop.alexhudson.com> (Alex Hudson's
	message of "Thu, 14 Jun 2007 18:19:00 +0100")
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
	<1181768094.3138.106.camel@laptop.alexhudson.com>
	<87odji5vks.fsf@wheatstone.g10code.de>
	<1181841540.3138.136.camel@laptop.alexhudson.com>
Message-ID: <87d4zx4qym.fsf@wheatstone.g10code.de>

On Thu, 14 Jun 2007 19:19, home at alexhudson.com said:

> in our situation, we want our software to work on standard GNU/Linux
> distributions, so we can't really ship our own libgcrypt without
> creating worse problems.

I guessed that.

> I hadn't seen this before, thanks. However, in the manual it does say:
>
>         "This command activates the use of a highly-insecure, but fast
>         PRNG. It can only be used at initialization time. The only
>         useful applications for this are certain regression tests."
>
> If we used GNUTLS with this turned on, would GNUTLS be working in much
> the same way as OpenSSL does (wrt. cert generation, etc.), or would it
> be a worse position? 

Actually it will still read a little bit form /dev/random for initial
seeding but then degrade the quality level to GCRY_STRONG_RANDOM (1).
grep fro "quick_test" in cipher/random.c:

  int
  _gcry_quick_random_gen( int onoff )
  {
    int last;
  
    /* No need to lock it here because we are only initializing.  A
       prerequisite of the entire code is that it has already been
       initialized before any possible concurrent access */
    read_random_source(0,0,0); /* init */
    last = quick_test;
    if( onoff != -1 )
      quick_test = onoff;
    return faked_rng? 1 : last;
  }

That is just to enable this mode.  faked_rng will only be true on
systems without any entropie source and print prominet warnings.

  int
  _gcry_random_is_faked()
  {
    if( !is_initialized )
      initialize();
    return (faked_rng || quick_test);
  }

Well this function will return true if quik_test has been enbaled and
that is the reason for the wording in the manual.


  static byte *
  get_random_bytes ( size_t nbytes, int level, int secure)
  {
    byte *buf, *p;
    int err;
  
    /* First a hack to avoid the strong random using 
       our regression test suite. */
    if (quick_test && level > 1)
      level = 1;
  
Thus you can see that we only degrade the level in the quick random
mode.

  void
  gcry_randomize (void *buffer, size_t length, enum gcry_random_level level)
  {
    byte *p;
    int err;
  
    /* Make sure we are initialized. */
    if (!is_initialized)
      initialize ();
  
    /* Handle our hack used for regression tests of Libgcrypt. */
    if( quick_test && level > 1 )
      level = 1;
  

Same as above.

> is very strong ("highly-insecure"). Is the manual being very paranoid,
> or is there a real risk here?

The whole problem is that we don't have any good estimation of
/dev/random's quality.  I still have some doubts.  In former times it
was quite stable code whichhas not been touches very often but since
Linux 2.3 (iirc) there have been numerous changes with very differnt
outcvome on the available entropie.  A real solid report on /dev/random
is still missing and I doubt that the NSA folks will publish their
results. 

But well, that is not spexial to libgcrypt as OpenSSL woull be affected
as well. 

My conclusion is that the quick random mode is not worse than what
OpenSSL has.  I will change the manual to reflect this statement.

But wait:

I just checked some _old_ GNUTLS code and it seems that it does not use
GCRY_VERY_STRONG_RANDOM for the prime generation.  So the quick mode
won't help you at all.  Actually I can find only
../libextra/gnutls_openssl.c which uses GCRY_VERY_STRONG_RANDOM in
RAND_bytes - do you use the OpenSSL emulation?


Shalom-Salam,

   Werner








From home at alexhudson.com  Fri Jun 15 10:59:43 2007
From: home at alexhudson.com (Alex Hudson)
Date: Fri, 15 Jun 2007 09:59:43 +0100
Subject: [gnutls-dev] Speed of random data generation
In-Reply-To: <87d4zx4qym.fsf@wheatstone.g10code.de>
References: <1181750832.3138.98.camel@laptop.alexhudson.com>
	<20070613174539.GA4058@downhill.g.la>
	<1181768094.3138.106.camel@laptop.alexhudson.com>
	<87odji5vks.fsf@wheatstone.g10code.de>
	<1181841540.3138.136.camel@laptop.alexhudson.com>
	<87d4zx4qym.fsf@wheatstone.g10code.de>
Message-ID: <1181897984.3164.15.camel@laptop.alexhudson.com>

Werner,

Thanks again for a very informative e-mail.

On Fri, 2007-06-15 at 09:28 +0200, Werner Koch wrote:
> > is very strong ("highly-insecure"). Is the manual being very paranoid,
> > or is there a real risk here?
> 
> The whole problem is that we don't have any good estimation of
> /dev/random's quality.  I still have some doubts.  In former times it
> was quite stable code whichhas not been touches very often but since
> Linux 2.3 (iirc) there have been numerous changes with very differnt
> outcvome on the available entropie.  A real solid report on /dev/random
> is still missing and I doubt that the NSA folks will publish their
> results. 

Are you talking about /dev/urandom here, or /dev/random? 

> My conclusion is that the quick random mode is not worse than what
> OpenSSL has.  I will change the manual to reflect this statement.

That's useful to know - I feel more comfortable offering it as an option
on that basis.

> But wait:
> 
> I just checked some _old_ GNUTLS code and it seems that it does not use
> GCRY_VERY_STRONG_RANDOM for the prime generation.  So the quick mode
> won't help you at all.  Actually I can find only
> ../libextra/gnutls_openssl.c which uses GCRY_VERY_STRONG_RANDOM in
> RAND_bytes - do you use the OpenSSL emulation?

No. We did try the OpenSSL emulation when we first used GNUTLS, but to
be honest we didn't experience much success. We didn't care too much
about OpenSSL compatibility, so we went GNUTLS-native.

I did some testing with part of our crypto generation. I did this on my
laptop, which has plenty of entropy, but ..ENABLE_QUICK_RANDOM made an
obvious difference.

The code I ran is this:

	gnutls_global_init();

	// data 1

	gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE);

	// data 2

	// DH params
	gnutls_dh_params_init(&dh_params);
	gnutls_dh_params_generate2(dh_params, 1024);
	gnutls_dh_params_export_pkcs3 (dh_params, GNUTLS_X509_FMT_PEM, &dhdata,
&dsize);

	// data 3
	
	// RSA params
	gnutls_rsa_params_init(&rsa_params);
	gnutls_rsa_params_generate2(rsa_params, 512);
	gnutls_dh_params_export_pkcs3 (rsa_params, GNUTLS_X509_FMT_PEM,
&rsadata, &dsize);

	// data 4

At those points I marked 'data', I did:
	
	gcry_control(GCRYCTL_DUMP_RANDOM_STATS, NULL);

And the results were:

(without QUICK_RANDOM):

1	random usage: poolsize=600 mixed=2 polls=5/1 added=11/692
	              outmix=1 getlvl1=1/1 getlvl2=0/0
2	random usage: poolsize=600 mixed=3 polls=5/1 added=11/692
	              outmix=2 getlvl1=1/1 getlvl2=0/0
3	random usage: poolsize=600 mixed=49 polls=5/29 added=179/3268
	              outmix=30 getlvl1=29/755 getlvl2=0/0
4	random usage: poolsize=600 mixed=54 polls=5/31 added=227/3752
	              outmix=32 getlvl1=29/755 getlvl2=2/64

(with QUICK_RANDOM):

1	random usage: poolsize=600 mixed=2 polls=0/1 added=11/720
	              outmix=1 getlvl1=1/1 getlvl2=0/0
2	random usage: poolsize=600 mixed=3 polls=0/1 added=11/720
	              outmix=2 getlvl1=1/1 getlvl2=0/0
3	random usage: poolsize=600 mixed=58 polls=0/29 added=179/3296
	              outmix=30 getlvl1=29/755 getlvl2=0/0
4	random usage: poolsize=600 mixed=62 polls=0/31 added=191/3480
	              outmix=32 getlvl1=31/819 getlvl2=0/0

On the first run, it _noticably_ depleted my entropy. I can't tell
exactly how much it read, but I had "3600" (bytes? bits?) to begin with,
and it quickly dropped to nothing. The process then stalled while it
waited for more entropy.

On the second run, the value in entropy_available didn't drop below 3500
(though I had only a 2 second watch on the value, my entropy doesn't
fill up _that_ fast - I don't think it could have been much lower than
3300 in any event).

This is using gnutls-1.4 as shipped in Fedora Core 6 - it really did
seem to make a big difference. Perhaps there is a bug somewhere which is
resulting in GNUTLS asking for stronger random numbers?

Cheers,

Alex.



From ametzler at downhill.at.eu.org  Sat Jun 16 11:59:25 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 16 Jun 2007 11:59:25 +0200
Subject: [gnutls-dev] gnutls-cli: segfaults when doing starttls against
	smtp.hispeed.ch
Message-ID: <20070616095925.GA4253@downhill.g.la>

Hello,
This is debian bug http://bugs.debian.org/429183

----- Forwarded message from Marc Haber <mh+debian-bugs at zugschlus.de> -----
From: Marc Haber <mh+debian-bugs at zugschlus.de>
To: Debian Bug Tracking System <submit at bugs.debian.org>
Message-ID: <20070616084459.14190.41815.reportbug at scyw00225.scy001.de>
Date: Sat, 16 Jun 2007 10:44:59 +0200

Package: gnutls-bin
Version: 1.6.3-1
Severity: normal
File: /usr/bin/gnutls-cli

Hi,

$ gnutls-cli -p 25 -s smtp.hispeed.ch
Resolving 'smtp.hispeed.ch'...
Connecting to '213.46.255.24:25'...

- Simple Client Mode:

220 smtp.hispeed.ch ESMTP server (InterMail vM.7.08.02.00 201-2186-121-20061213) ready Sat, 16 Jun 2007 10:42:25 +0200
EHLO zugschlus.de
250-smtp.hispeed.ch
250-HELP
250-XREMOTEQUEUE
250-ETRN
250-AUTH=LOGIN PLAIN
250-AUTH LOGIN PLAIN
250-PIPELINING
250-DSN
250-8BITMIME
250-STARTTLS
250 SIZE 15360000
STARTTLS
220 Ready to start TLS
*** Starting TLS handshake
*** Fatal error: A record packet with illegal version was received.
*** Handshake has failed
Segmentation fault
$

The "record packet with illegal version was received" sounds familiar
and might be a bug already known, but gnutls-cli should definetely not
segfault in this situation.

Greetings
Marc
----- End forwarded message -----


This applies to at least 1.4.x, 1.6.3 and 1.7.9. Exim built against
gnutls wil not crash when delivering against smtp.hispeed.ch, however
it will not be able to make use of TLS

| initialized GnuTLS session
| LOG: MAIN
|   TLS error on connection to smtp.hispeed.ch [213.46.255.24] (gnutls_handshake): A TLS fatal alert has been received.
| ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address is not NULL
| 213.46.255.24 in hosts_require_tls? no (option unset)
| LOG: MAIN
|   TLS session failure: delivering unencrypted to smtp.hispeed.ch [213.46.255.24] (not in hosts_require_tls)

Sadly a backtrace is not helpful, and OpenSSL does not have any
problems with this host.
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 chbouib.org  Sun Jun 17 19:56:19 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 17 Jun 2007 19:56:19 +0200
Subject: [gnutls-dev] Guile needs 1.8?
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org>
Message-ID: <87myyy4g8s.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> I'll add a more reliable test anyway.

See attached patch: It basically uses Guile's `version' procedure to
check whether we are using 1.8 or later.

> Perhaps a test for the feature that seems to break things here?
> SCM_API, scm_t_bits, or whatever it might have been.

No.  Those types and macros are actually defined in 1.6 as well.  It
just turned out that for some reason their definitions were not visible.

Anyway, such a feature test wouldn't help since 1.6 and 1.8 are
significantly different API-wise.

BTW, I think it should be possible to install both Debian packages
side-by-side, except the `-dev' packages.

Thanks,
Ludovic.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-sure-Guile-is-1.8-or-later.patch
Type: text/x-patch
Size: 2148 bytes
Desc: The patch
Url : /pipermail/attachments/20070617/d08681e0/attachment.bin 

From simon at josefsson.org  Mon Jun 18 16:11:57 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 18 Jun 2007 16:11:57 +0200
Subject: [gnutls-dev] Public git repository
Message-ID: <87sl8ptkr6.fsf@mocca.josefsson.org>

Hi!  (If you make a project-specific reply, please remove CC's.)

There is now a public gitweb repository of my projects:

http://git.josefsson.org/

Unfortunately, I couldn't get the 'git-cvsserver' read-only CVS server
working, and can't prioritize to spend more time debugging it.  If
someone else knows how to set up git-cvsserver and wants to offer a
read-only cvs server for the git repository, that would be very much
appreciated.

/Simon


From ludo at chbouib.org  Mon Jun 18 21:28:03 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 18 Jun 2007 21:28:03 +0200
Subject: [gnutls-dev] Public git repository
References: <87sl8ptkr6.fsf@mocca.josefsson.org>
Message-ID: <87lkehyse4.fsf@chbouib.org>

Hi!

Simon Josefsson <simon at josefsson.org> writes:

> There is now a public gitweb repository of my projects:
>
> http://git.josefsson.org/

The last change sets in the GnuTLS repository available from there are
older than (and different from) those visible at `repo.or.cz' and recent
tags such as `gnutls_1_7_13' are missing.  Is there something wrong or
am I missing something?

Thanks,
Ludovic.



From simon at josefsson.org  Tue Jun 19 11:26:27 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 19 Jun 2007 11:26:27 +0200
Subject: [gnutls-dev] Public git repository
In-Reply-To: <87lkehyse4.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon, 18 Jun 2007 21:28:03 +0200")
References: <87sl8ptkr6.fsf@mocca.josefsson.org> <87lkehyse4.fsf@chbouib.org>
Message-ID: <87abuwqoqk.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi!
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> There is now a public gitweb repository of my projects:
>>
>> http://git.josefsson.org/
>
> The last change sets in the GnuTLS repository available from there are
> older than (and different from) those visible at `repo.or.cz' and recent
> tags such as `gnutls_1_7_13' are missing.  Is there something wrong or
> am I missing something?

Hi!  I forgot to push my changes to my local git master (which
git-cvsimport created), that is rsync'ed with git.josefsson.org.  Fixed
now.

I suppose I should rsync my local clone instead -- I'm not sure I will
ever need my local git master that cvs-cvsimport created any more?

Thanks,
Simon


From simon at josefsson.org  Wed Jun 20 16:23:26 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 20 Jun 2007 16:23:26 +0200
Subject: [gnutls-dev] gnutls-cli: segfaults when doing starttls against
	smtp.hispeed.ch
In-Reply-To: <20070616095925.GA4253@downhill.g.la> (Andreas Metzler's message
	of "Sat, 16 Jun 2007 11:59:25 +0200")
References: <20070616095925.GA4253@downhill.g.la>
Message-ID: <87vedipuw1.fsf@mocca.josefsson.org>

Hi!  Thanks for the report.

This is what happens, first the TLS handshake fails in the gnutls
library (I'll return to the reasons for that below), and in cli.c the
following code is responsible for handling this:

      if (FD_ISSET (fileno (stdin), &rset))
	{
	  if (fgets (buffer, MAX_BUF, stdin) == NULL)
	    {
	      if (hd.secure == 0)
		{
		  fprintf (stderr, "*** Starting TLS handshake\n");
		  ret = do_handshake (&hd);
		  if (ret < 0)
		    {
		      fprintf (stderr, "*** Handshake has failed\n");
		      socket_bye (&hd);
		      user_term = 1;
		    }
		}
	      else
		{
		  user_term = 1;
		  break;
		}
	      continue;
	    }

In this case, the '*** Handshake has failed' output has been printed,
and socket_bye() is invoked.  socket_bye() sets socket->fd to -1.  Then
the 'continue' is taken, and the loop resumes:

  for (;;)
    {
      if (starttls_alarmed && !hd.secure)
	{
	  fprintf (stderr, "*** Starting TLS handshake\n");
	  ret = do_handshake (&hd);
	  if (ret < 0)
	    {
	      fprintf (stderr, "*** Handshake has failed\n");
	      socket_bye (&hd);
	      user_term = 1;
	      break;
	    }
	}

      FD_ZERO (&rset);
      FD_SET (fileno (stdin), &rset);
      FD_SET (hd.fd, &rset);

Here, starttls_alarmed is false, so it skips the if case, and invokes
FD_ZERO + FD_SET.  Here hd.fd is still -1, and it seems that FD_SET(-1,
&rset) causes a segmentation fault.  Hence, the solution is:

diff --git a/src/cli.c b/src/cli.c
index f9564bb..74e47b1 100644
--- a/src/cli.c
+++ b/src/cli.c
@@ -802,6 +802,7 @@ after_handshake:
 		      fprintf (stderr, "*** Handshake has failed\n");
 		      socket_bye (&hd);
 		      user_term = 1;
+		      break;
 		    }
 		}
 	      else

Installed in git now.

Now, the interesting part is why the TLS handshake fails.  'gnutls-cli
-d 4711' reveals:

|<3>| HSK[8076500]: SERVER HELLO was received [58 bytes]
|<6>| BUF[REC][HD]: Read 54 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 54 bytes of Data
|<3>| HSK[8076500]: Server's version: 3.3

Thus, the server claims that it supports version 3.3 aka TLS 1.2.
However later on it sends a TLS record message using TLS version 3.1:

|<2>| ASSERT: gnutls_record.c:624
|<4>| REC[8076500]: INVALID VERSION PACKET: (12) 3.1

It even fails to negotiate TLS 1.0:

./gnutls-cli -p 4711 -s localhost -d 4711 --protocols TLS1.0
|<3>| HSK[8076500]: SERVER HELLO was received [58 bytes]
|<3>| HSK[8076500]: Server's version: 3.1
...
|<4>| REC[8076500]: Decrypted Packet[2] Alert(21) with length: 2
|<4>| REC[8076500]: Alert[2|0] - Close notify - was received

TLS 1.1 fails in the same way as TLS 1.2:

./gnutls-cli -p 4711 -s localhost -d 4711 --protocols TLS1.1
|<3>| HSK[8076500]: SERVER HELLO was received [58 bytes]
|<3>| HSK[8076500]: Server's version: 3.2
...
|<2>| ASSERT: gnutls_record.c:624
|<4>| REC[8076500]: INVALID VERSION PACKET: (12) 3.1

Alas, even SSL3.0 does not work:

./gnutls-cli -p 4711 -s localhost -d 4711 --protocols SSL3.0
...
|<3>| HSK[8076500]: SERVER HELLO was received [58 bytes]
|<3>| HSK[8076500]: Server's version: 3.0
...
|<4>| REC[8076500]: Decrypted Packet[2] Alert(21) with length: 2
|<4>| REC[8076500]: Alert[2|0] - Close notify - was received

Possibly, this is a SSL 2.0 only server.  Although it seems the OpenSSL
is able to connect to the server using TLSv1 with the default settings.
However, if I add -ssl3 or -tls1 it fails to negotiate anything.

openssl s_client -debug -connect localhost:4711 -starttls smtp 
CONNECTED(00000003)
read from 0x80c00c0 [0x80c10a8] (4096 bytes => 120 (0x78))
0000 - 32 32 30 20 73 6d 74 70-2e 68 69 73 70 65 65 64   220 smtp.hispeed
0010 - 2e 63 68 20 45 53 4d 54-50 20 73 65 72 76 65 72   .ch ESMTP server
0020 - 20 28 49 6e 74 65 72 4d-61 69 6c 20 76 4d 2e 37    (InterMail vM.7
0030 - 2e 30 38 2e 30 32 2e 30-30 20 32 30 31 2d 32 31   .08.02.00 201-21
0040 - 38 36 2d 31 32 31 2d 32-30 30 36 31 32 31 33 29   86-121-20061213)
0050 - 20 72 65 61 64 79 20 57-65 64 2c 20 32 30 20 4a    ready Wed, 20 J
0060 - 75 6e 20 32 30 30 37 20-31 36 3a 32 30 3a 33 37   un 2007 16:20:37
0070 - 20 2b 30 32 30 30 0d 0a-                           +0200..
write to 0x80c00c0 [0x80c20b0] (25 bytes => 25 (0x19))
0000 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
0010 - 65 6e 74 2e 6e 65 74 0d-0a                        ent.net..
read from 0x80c00c0 [0x80c10a8] (4096 bytes => 175 (0xAF))
0000 - 32 35 30 2d 73 6d 74 70-2e 68 69 73 70 65 65 64   250-smtp.hispeed
0010 - 2e 63 68 0d 0a 32 35 30-2d 48 45 4c 50 0d 0a 32   .ch..250-HELP..2
0020 - 35 30 2d 58 52 45 4d 4f-54 45 51 55 45 55 45 0d   50-XREMOTEQUEUE.
0030 - 0a 32 35 30 2d 45 54 52-4e 0d 0a 32 35 30 2d 41   .250-ETRN..250-A
0040 - 55 54 48 3d 4c 4f 47 49-4e 20 50 4c 41 49 4e 0d   UTH=LOGIN PLAIN.
0050 - 0a 32 35 30 2d 41 55 54-48 20 4c 4f 47 49 4e 20   .250-AUTH LOGIN 
0060 - 50 4c 41 49 4e 0d 0a 32-35 30 2d 50 49 50 45 4c   PLAIN..250-PIPEL
0070 - 49 4e 49 4e 47 0d 0a 32-35 30 2d 44 53 4e 0d 0a   INING..250-DSN..
0080 - 32 35 30 2d 38 42 49 54-4d 49 4d 45 0d 0a 32 35   250-8BITMIME..25
0090 - 30 2d 53 54 41 52 54 54-4c 53 0d 0a 32 35 30 20   0-STARTTLS..250 
00a0 - 53 49 5a 45 20 31 35 33-36 30 30 30 30 0d 0a      SIZE 15360000..
write to 0x80c00c0 [-0x4014f118] (10 bytes => 10 (0xA))
0000 - 53 54 41 52 54 54 4c 53-0d 0a                     STARTTLS..
read from 0x80c00c0 [0x80b9f08] (8192 bytes => 24 (0x18))
0000 - 32 32 30 20 52 65 61 64-79 20 74 6f 20 73 74 61   220 Ready to sta
0010 - 72 74 20 54 4c 53 0d 0a-                          rt TLS..
write to 0x80c00c0 [0x80c1060] (118 bytes => 118 (0x76))
0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00   .t....K... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0   8..5............
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00   ..3..2../.......
0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00   ................
0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80   @...............
0050 - 00 00 03 02 00 80 62 99-68 5f 9d b1 d3 69 20 8b   ......b.h_...i .
0060 - fd 69 5c f9 f2 75 55 e1-74 46 92 c9 79 5b 3f 37   .i\..uU.tF..y[?7
0070 - 98 09 d9 c4 54 36                                 ....T6
read from 0x80c00c0 [0x80c65c0] (7 bytes => 7 (0x7))
0000 - 16 03 01 00 3a 02                                 ....:.
0007 - <SPACES/NULS>
read from 0x80c00c0 [0x80c65c7] (56 bytes => 56 (0x38))
0000 - 00 36 03 01 46 79 37 b5-0d 05 27 6e 65 87 a1 81   .6..Fy7...'ne...
0010 - 0a aa 09 8e a7 cf 69 3c-cb c8 8d ca 9a a9 31 65   ......i<......1e
0020 - 70 7f cb 12 10 4e 75 6c-39 bc 60 33 de d5 7a dc   p....Nul9.`3..z.
0030 - 0d f2 70 75 bd 00 0a                              ..pu...
0038 - <SPACES/NULS>
read from 0x80c00c0 [0x80c65c0] (5 bytes => 5 (0x5))
0000 - 16 03 01 06 6d                                    ....m
read from 0x80c00c0 [0x80c65c5] (1645 bytes => 1380 (0x564))
0000 - 0b 00 06 69 00 06 66 00-03 3c 30 82 03 38 30 82   ...i..f..<0..80.
0010 - 02 a1 a0 03 02 01 02 02-03 07 4c 60 30 0d 06 09   ..........L`0...
0020 - 2a 86 48 86 f7 0d 01 01-05 05 00 30 4e 31 0b 30   *.H........0N1.0
0030 - 09 06 03 55 04 06 13 02-55 53 31 10 30 0e 06 03   ...U....US1.0...
0040 - 55 04 0a 13 07 45 71 75-69 66 61 78 31 2d 30 2b   U....Equifax1-0+
0050 - 06 03 55 04 0b 13 24 45-71 75 69 66 61 78 20 53   ..U...$Equifax S
0060 - 65 63 75 72 65 20 43 65-72 74 69 66 69 63 61 74   ecure Certificat
0070 - 65 20 41 75 74 68 6f 72-69 74 79 30 1e 17 0d 30   e Authority0...0
0080 - 37 30 34 32 30 31 31 34-30 34 39 5a 17 0d 30 39   70420114049Z..09
0090 - 30 34 32 30 31 31 34 30-34 39 5a 30 81 c2 31 0b   0420114049Z0..1.
00a0 - 30 09 06 03 55 04 06 13-02 41 54 31 18 30 16 06   0...U....AT1.0..
00b0 - 03 55 04 0a 13 0f 73 6d-74 70 2e 68 69 73 70 65   .U....smtp.hispe
00c0 - 65 64 2e 63 68 31 13 30-11 06 03 55 04 0b 13 0a   ed.ch1.0...U....
00d0 - 47 54 30 36 33 33 39 38-31 36 31 31 30 2f 06 03   GT06339816110/..
00e0 - 55 04 0b 13 28 53 65 65-20 77 77 77 2e 67 65 6f   U...(See www.geo
00f0 - 74 72 75 73 74 2e 63 6f-6d 2f 72 65 73 6f 75 72   trust.com/resour
0100 - 63 65 73 2f 63 70 73 20-28 63 29 30 37 31 37 30   ces/cps (c)07170
0110 - 35 06 03 55 04 0b 13 2e-44 6f 6d 61 69 6e 20 43   5..U....Domain C
0120 - 6f 6e 74 72 6f 6c 20 56-61 6c 69 64 61 74 65 64   ontrol Validated
0130 - 20 2d 20 51 75 69 63 6b-53 53 4c 20 50 72 65 6d    - QuickSSL Prem
0140 - 69 75 6d 28 52 29 31 18-30 16 06 03 55 04 03 13   ium(R)1.0...U...
0150 - 0f 73 6d 74 70 2e 68 69-73 70 65 65 64 2e 63 68   .smtp.hispeed.ch
0160 - 30 81 9f 30 0d 06 09 2a-86 48 86 f7 0d 01 01 01   0..0...*.H......
0170 - 05 00 03 81 8d 00 30 81-89 02 81 81 00 e4 be 5c   ......0........\
0180 - 82 77 e4 8e f9 6c 79 b7-ab d1 a3 3d ed 37 8a 6e   .w...ly....=.7.n
0190 - 34 2f 37 79 83 8c 80 25-d3 fe 7f 77 10 44 41 dd   4/7y...%...w.DA.
01a0 - 9e 73 84 a9 5b 87 59 ee-d9 e1 7e 48 d9 c5 11 17   .s..[.Y...~H....
01b0 - db be c6 14 63 09 a8 47-33 48 79 81 4c 19 cf 9e   ....c..G3Hy.L...
01c0 - a3 e0 9a 86 f8 26 2d 79-a7 c2 ad 9d d6 70 e4 4e   .....&-y.....p.N
01d0 - ca 3c 6f ca 18 a3 1e 22-a9 48 2a e7 dd 06 ad 1f   .<o....".H*.....
01e0 - 96 e6 0d 38 2e ec 39 cd-31 c8 e4 82 3e 31 d1 82   ...8..9.1...>1..
01f0 - 1b ed c8 6d 43 79 cc a8-6c 2f dd 4c b1 02 03 01   ...mCy..l/.L....
0200 - 00 01 a3 81 ae 30 81 ab-30 0e 06 03 55 1d 0f 01   .....0..0...U...
0210 - 01 ff 04 04 03 02 04 f0-30 1d 06 03 55 1d 0e 04   ........0...U...
0220 - 16 04 14 fa 31 61 e8 de-71 de 3a 0f a8 51 62 e1   ....1a..q.:..Qb.
0230 - 3e ff 12 b7 94 2e 88 30-3a 06 03 55 1d 1f 04 33   >......0:..U...3
0240 - 30 31 30 2f a0 2d a0 2b-86 29 68 74 74 70 3a 2f   010/.-.+.)http:/
0250 - 2f 63 72 6c 2e 67 65 6f-74 72 75 73 74 2e 63 6f   /crl.geotrust.co
0260 - 6d 2f 63 72 6c 73 2f 73-65 63 75 72 65 63 61 2e   m/crls/secureca.
0270 - 63 72 6c 30 1f 06 03 55-1d 23 04 18 30 16 80 14   crl0...U.#..0...
0280 - 48 e6 68 f9 2b d2 b2 95-d7 47 d8 23 20 10 4f 33   H.h.+....G.# .O3
0290 - 98 90 9f d4 30 1d 06 03-55 1d 25 04 16 30 14 06   ....0...U.%..0..
02a0 - 08 2b 06 01 05 05 07 03-01 06 08 2b 06 01 05 05   .+.........+....
02b0 - 07 03 02 30 0d 06 09 2a-86 48 86 f7 0d 01 01 05   ...0...*.H......
02c0 - 05 00 03 81 81 00 78 17-28 5f f4 83 17 a8 e9 1e   ......x.(_......
02d0 - c7 05 3f 71 2c 68 a4 d7-00 ae 2f 8e 32 48 be 16   ..?q,h..../.2H..
02e0 - dc f9 ed 7f cc 24 15 30-39 fe 02 5a 10 8d a9 3e   .....$.09..Z...>
02f0 - 0e c6 7b 4b 19 c9 fe 82-a7 8b c0 2c b6 bb e6 0a   ..{K.......,....
0300 - b8 db 14 86 79 84 7b 96-cb 07 bb d8 80 9a 61 b2   ....y.{.......a.
0310 - 52 ae 5a 44 7f 99 39 b5-e2 5d 72 98 4d b9 f7 88   R.ZD..9..]r.M...
0320 - e3 7b cd 72 98 a4 40 74-5f 97 c3 d5 0c 06 02 5f   .{.r.. at t_......_
0330 - 71 82 c2 d6 45 f4 3c 35-95 70 0b ef fe cc 68 af   q...E.<5.p....h.
0340 - 5a 1b 0b e6 0e 91 00 03-24 30 82 03 20 30 82 02   Z.......$0.. 0..
0350 - 89 a0 03 02 01 02 02 04-35 de f4 cf 30 0d 06 09   ........5...0...
0360 - 2a 86 48 86 f7 0d 01 01-05 05 00 30 4e 31 0b 30   *.H........0N1.0
0370 - 09 06 03 55 04 06 13 02-55 53 31 10 30 0e 06 03   ...U....US1.0...
0380 - 55 04 0a 13 07 45 71 75-69 66 61 78 31 2d 30 2b   U....Equifax1-0+
0390 - 06 03 55 04 0b 13 24 45-71 75 69 66 61 78 20 53   ..U...$Equifax S
03a0 - 65 63 75 72 65 20 43 65-72 74 69 66 69 63 61 74   ecure Certificat
03b0 - 65 20 41 75 74 68 6f 72-69 74 79 30 1e 17 0d 39   e Authority0...9
03c0 - 38 30 38 32 32 31 36 34-31 35 31 5a 17 0d 31 38   80822164151Z..18
03d0 - 30 38 32 32 31 36 34 31-35 31 5a 30 4e 31 0b 30   0822164151Z0N1.0
03e0 - 09 06 03 55 04 06 13 02-55 53 31 10 30 0e 06 03   ...U....US1.0...
03f0 - 55 04 0a 13 07 45 71 75-69 66 61 78 31 2d 30 2b   U....Equifax1-0+
0400 - 06 03 55 04 0b 13 24 45-71 75 69 66 61 78 20 53   ..U...$Equifax S
0410 - 65 6depth=1 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
3 75 72 65 20 43 65-72 74 69 66 69 63 61 74   ecure Certificat
0420 - 65 20 41 75 74 68 6f 72-69 74 79 30 81 9f 30 0d   e Authority0..0.
0430 - 06 09 2a 86 48 86 f7 0d-01 01 01 05 00 03 81 8d   ..*.H...........
0440 - 00 30 81 89 02 81 81 00-c1 5d b1 58 67 08 62 ee   .0.......].Xg.b.
0450 - a0 9a 2d 1f 08 6d 91 14-68 98 0a 1e fe da 04 6f   ..-..m..h......o
0460 - 13 84 62 21 c3 d1 7c ce-9f 05 e0 b8 01 f0 4e 34   ..b!..|.......N4
0470 - ec e2 8a 95 04 64 ac f1-6b 53 5f 05 b3 cb 67 80   .....d..kS_...g.
0480 - bf 42 02 8e fe dd 01 09-ec e1 00 14 4f fc fb f0   .B..........O...
0490 - 0c dd 43 ba 5b 2b e1 1f-80 70 99 15 57 93 16 f1   ..C.[+...p..W...
04a0 - 0f 97 6a b7 c2 68 23 1c-cc 4d 59 30 ac 51 1e 3b   ..j..h#..MY0.Q.;
04b0 - af 2b d6 ee 63 45 7b c5-d9 5f 50 d2 e3 50 0f 3a   .+..cE{.._P..P.:
04c0 - 88 e7 bf 14 fd e0 c7 b9-02 03 01 00 01 a3 82 01   ................
04d0 - 09 30 82 01 05 30 70 06-03 55 1d 1f 04 69 30 67   .0...0p..U...i0g
04e0 - 30 65 a0 63 a0 61 a4 5f-30 5d 31 0b 30 09 06 03   0e.c.a._0]1.0...
04f0 - 55 04 06 13 02 55 53 31-10 30 0e 06 03 55 04 0a   U....US1.0...U..
0500 - 13 07 45 71 75 69 66 61-78 31 2d 30 2b 06 03 55   ..Equifax1-0+..U
0510 - 04 0b 13 24 45 71 75 69-66 61 78 20 53 65 63 75   ...$Equifax Secu
0520 - 72 65 20 43 65 72 74 69-66 69 63 61 74 65 20 41   re Certificate A
0530 - 75 74 68 6f 72 69 74 79-31 0d 30 0b 06 03 55 04   uthority1.0...U.
0540 - 03 13 04 43 52 4c 31 30-1a 06 03 55 1d 10 04 13   ...CRL10...U....
0550 - 30 11 81 0f 32 30 31 38-30 38 32 32 31 36 34 31   0...201808221641
0560 - 35 31 5a 30                                       51Z0
read from 0x80c00c0 [0x80c6b29] (265 bytes => 265 (0x109))
0000 - 0b 06 03 55 1d 0f 04 04-03 02 01 06 30 1f 06 03   ...U........0...
0010 - 55 1d 23 04 18 30 16 80-14 48 e6 68 f9 2b d2 b2   U.#..0...H.h.+..
0020 - 95 d7 47 d8 23 20 10 4f-33 98 90 9f d4 30 1d 06   ..G.# .O3....0..
0030 - 03 55 1d 0e 04 16 04 14-48 e6 68 f9 2b d2 b2 95   .U......H.h.+...
0040 - d7 47 d8 23 20 10 4f 33-98 90 9f d4 30 0c 06 03   .G.# .O3....0...
0050 - 55 1d 13 04 05 30 03 01-01 ff 30 1a 06 09 2a 86   U....0....0...*.
0060 - 48 86 f6 7d 07 41 00 04-0d 30 0b 1b 05 56 33 2e   H..}.A...0...V3.
0070 - 30 63 03 02 06 c0 30 0d-06 09 2a 86 48 86 f7 0d   0c....0...*.H...
0080 - 01 01 05 05 00 03 81 81-00 58 ce 29 ea fc f7 de   .........X.)....
0090 - b5 ce 02 b9 17 b5 85 d1-b9 e3 e0 95 cc 25 31 0d   .............%1.
00a0 - 00 a6 92 6e 7f b6 92 63-9e 50 95 d1 9a 6f e4 11   ...n...c.P...o..
00b0 - de 63 85 6e 98 ee a8 ff-5a c8 d3 55 b2 66 71 57   .c.n....Z..U.fqW
00c0 - de c0 21 eb 3d 2a a7 23-49 01 04 86 42 7b fc ee   ..!.=*.#I...B{..
00d0 - 7f a2 16 52 b5 67 67 d3-40 db 3b 26 58 b2 28 77   ...R.gg. at .;&X.(w
00e0 - 3d ae 14 77 61 d6 fa 2a-66 27 a0 0d fa a7 73 5c   =..wa..*f'....s\
00f0 - ea 70 f1 94 21 65 44 5f-fa fc ef 29 68 a9 a2 87   .p..!eD_...)h...
0100 - 79 ef 79 ef 4f ac 07 77-38                        y.y.O..w8
read from 0x80c00c0 [0x80c65c0] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 04                                    .....
read from 0x80c00c0 [0x80c65c5] (4 bytes => 4 (0x4))
0000 - 0e                                                .
0004 - <SPACES/NULS>
write to 0x80c00c0 [0x80d0828] (139 bytes => 139 (0x8B))
0000 - 16 03 01 00 86 10 00 00-82 00 80 a8 56 74 7c 57   ............Vt|W
0010 - 6e 26 07 eb 36 9d 3b dc-27 7b dc 8e f2 a9 a7 17   n&..6.;.'{......
0020 - 75 6e e4 e0 4e e4 d4 25-c7 08 ee b3 e7 6e 11 24   un..N..%.....n.$
0030 - 7d 0a 1a 0d 9d 0c 91 be-e9 7a 08 fa e9 a8 cc 54   }........z.....T
0040 - 11 f1 c8 69 30 2b 25 a7-b6 40 19 62 f8 50 cf 8b   ...i0+%.. at .b.P..
0050 - da 2d 3e 03 00 3e c6 45-f3 dc 3b 5d 3d 17 68 9a   .->..>.E..;]=.h.
0060 - 05 85 24 19 5a 9e 0e ae-e7 ce 0c 8d 11 b1 61 72   ..$.Z.........ar
0070 - 21 8e d9 bc bf a8 6a 2a-21 97 f4 f9 9a 59 07 77   !.....j*!....Y.w
0080 - 1a 89 5a 89 1a c2 dd 4d-70 ea d2                  ..Z....Mp..
write to 0x80c00c0 [0x80d0828] (6 bytes => 6 (0x6))
0000 - 14 03 01 00 01 01                                 ......
write to 0x80c00c0 [0x80d0828] (45 bytes => 45 (0x2D))
0000 - 16 03 01 00 28 cd 22 90-f1 d6 cb 74 7f d9 0e 30   ....(."....t...0
0010 - ad 7f 77 6f db 0c 1d a8-53 a3 be e5 0d fe eb ae   ..wo....S.......
0020 - 61 02 62 9d 25 69 a5 7d-94 33 36 12               a.b.%i.}.36.
002d - <SPACES/NULS>
read from 0x80c00c0 [0x80c65c0] (5 bytes => 5 (0x5))
0000 - 14 03 01 00 01                                    .....
read from 0x80c00c0 [0x80c65c5] (1 bytes => 1 (0x1))
0000 - 01                                                .
read from 0x80c00c0 [0x80c65c0] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 28                                    ....(
read from 0x80c00c0 [0x80c65c5] (40 bytes => 40 (0x28))
0000 - f5 e3 08 a8 8f e6 3f 39-0e 1a cf bb 42 21 c2 2c   ......?9....B!.,
0010 - 79 13 0c c7 ba 3b c7 e5-77 53 76 de 49 fb f8 6d   y....;..wSv.I..m
0020 - a3 b0 29 2f 62 3c 45 1c-                          ..)/b<E.
---
Certificate chain
 0 s:/C=AT/O=smtp.hispeed.ch/OU=GT06339816/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL Premium(R)/CN=smtp.hispeed.ch
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
 1 s:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDODCCAqGgAwIBAgIDB0xgMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDcwNDIwMTE0MDQ5WhcNMDkwNDIwMTE0MDQ5
WjCBwjELMAkGA1UEBhMCQVQxGDAWBgNVBAoTD3NtdHAuaGlzcGVlZC5jaDETMBEG
A1UECxMKR1QwNjMzOTgxNjExMC8GA1UECxMoU2VlIHd3dy5nZW90cnVzdC5jb20v
cmVzb3VyY2VzL2NwcyAoYykwNzE3MDUGA1UECxMuRG9tYWluIENvbnRyb2wgVmFs
aWRhdGVkIC0gUXVpY2tTU0wgUHJlbWl1bShSKTEYMBYGA1UEAxMPc210cC5oaXNw
ZWVkLmNoMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkvlyCd+SO+Wx5t6vR
oz3tN4puNC83eYOMgCXT/n93EERB3Z5zhKlbh1nu2eF+SNnFERfbvsYUYwmoRzNI
eYFMGc+eo+CahvgmLXmnwq2d1nDkTso8b8oYox4iqUgq590GrR+W5g04Luw5zTHI
5II+MdGCG+3IbUN5zKhsL91MsQIDAQABo4GuMIGrMA4GA1UdDwEB/wQEAwIE8DAd
BgNVHQ4EFgQU+jFh6N5x3joPqFFi4T7/EreULogwOgYDVR0fBDMwMTAvoC2gK4Yp
aHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9zZWN1cmVjYS5jcmwwHwYDVR0j
BBgwFoAUSOZo+SvSspXXR9gjIBBPM5iQn9QwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4GBAHgXKF/0gxeo6R7HBT9xLGik1wCu
L44ySL4W3Pntf8wkFTA5/gJaEI2pPg7Ge0sZyf6Cp4vALLa75gq42xSGeYR7lssH
u9iAmmGyUq5aRH+ZObXiXXKYTbn3iON7zXKYpEB0X5fD1QwGAl9xgsLWRfQ8NZVw
C+/+zGivWhsL5g6R
-----END CERTIFICATE-----
subject=/C=AT/O=smtp.hispeed.ch/OU=GT06339816/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL Premium(R)/CN=smtp.hispeed.ch
issuer=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 2092 bytes and written 343 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DES-CBC3-SHA
    Session-ID: 4E756C39BC6033DED57ADC0DF27075BD
    Session-ID-ctx: 
    Master-Key: 0C76FEF9966C8B0E1558B850506CDF5D05DEBE285DAD0DC72FC2DDCE1DBDE4C5986A361BF73DA25508797CE0CDD9715D
    Key-Arg   : None
    Start Time: 1182349237
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
250 SIZE 15360000.
DONE
write to 0x80c00c0 [0x80cadd0] (29 bytes => 29 (0x1D))
0000 - 15 03 01 00 18 dd c8 3a-dd d3 95 4c 83 1e 12 02   .......:...L....
0010 - 3f a4 63 61 bd d5 0d d0-8d a8 49 9b 3e            ?.ca......I.>

/Simon

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> This is debian bug http://bugs.debian.org/429183
>
> From: Marc Haber <mh+debian-bugs at zugschlus.de>
> To: Debian Bug Tracking System <submit at bugs.debian.org>
> Date: Sat, 16 Jun 2007 10:44:59 +0200
>
> Package: gnutls-bin
> Version: 1.6.3-1
> Severity: normal
> File: /usr/bin/gnutls-cli
>
> Hi,
>
> $ gnutls-cli -p 25 -s smtp.hispeed.ch
> Resolving 'smtp.hispeed.ch'...
> Connecting to '213.46.255.24:25'...
>
> - Simple Client Mode:
>
> 220 smtp.hispeed.ch ESMTP server (InterMail vM.7.08.02.00 201-2186-121-20061213) ready Sat, 16 Jun 2007 10:42:25 +0200
> EHLO zugschlus.de
> 250-smtp.hispeed.ch
> 250-HELP
> 250-XREMOTEQUEUE
> 250-ETRN
> 250-AUTH=LOGIN PLAIN
> 250-AUTH LOGIN PLAIN
> 250-PIPELINING
> 250-DSN
> 250-8BITMIME
> 250-STARTTLS
> 250 SIZE 15360000
> STARTTLS
> 220 Ready to start TLS
> *** Starting TLS handshake
> *** Fatal error: A record packet with illegal version was received.
> *** Handshake has failed
> Segmentation fault
> $
>
> The "record packet with illegal version was received" sounds familiar
> and might be a bug already known, but gnutls-cli should definetely not
> segfault in this situation.
>
> Greetings
> Marc
> ----------
>
>
>
> This applies to at least 1.4.x, 1.6.3 and 1.7.9. Exim built against
> gnutls wil not crash when delivering against smtp.hispeed.ch, however
> it will not be able to make use of TLS
>
> | initialized GnuTLS session
> | LOG: MAIN
> |   TLS error on connection to smtp.hispeed.ch [213.46.255.24] (gnutls_handshake): A TLS fatal alert has been received.
> | ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address is not NULL
> | 213.46.255.24 in hosts_require_tls? no (option unset)
> | LOG: MAIN
> |   TLS session failure: delivering unencrypted to smtp.hispeed.ch [213.46.255.24] (not in hosts_require_tls)
>
> Sadly a backtrace is not helpful, and OpenSSL does not have any
> problems with this host.
> 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  Tue Jun 19 21:45:29 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 19 Jun 2007 21:45:29 +0200
Subject: [gnutls-dev] Public git repository
References: <87sl8ptkr6.fsf@mocca.josefsson.org> <87lkehyse4.fsf@chbouib.org>
	<87abuwqoqk.fsf@mocca.josefsson.org>
Message-ID: <87sl8nwwx2.fsf@chbouib.org>

Hi!

Simon Josefsson <simon at josefsson.org> writes:

> I suppose I should rsync my local clone instead -- I'm not sure I will
> ever need my local git master that cvs-cvsimport created any more?

I'm not sure what the best answer is, but perhaps using `rsync' to send
your local repo on-line is the easiest way (that's what I do).  The
thing is that a cron job is needed to make sure repos remain up-to-date.
;-)

Thanks,
Ludovic.



From ludo at gnu.org  Mon Jun 25 21:25:48 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 25 Jun 2007 21:25:48 +0200
Subject: [gnutls-dev] Guile needs 1.8?
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
Message-ID: <87lke7q1j7.fsf@chbouib.org>

Hi,

ludo at chbouib.org (Ludovic Court?s) writes:

> * configure.in: Make sure Guile is 1.8 or later, using `GUILE_CHECK'.

Just a reminder: it seems that this patch hasn't been applied yet.

Thanks,
Ludovic.



From ludo at gnu.org  Tue Jun 26 00:54:58 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 26 Jun 2007 00:54:58 +0200
Subject: [gnutls-dev] [PATCH] Memory leak in `_gnutls_dsa_verify ()'
Message-ID: <87odj3mypp.fsf@chbouib.org>

A non-text attachment was scrubbed...
Name: 0005-Fixed-memory-leak-in-_gnutls_dsa_verify.patch
Type: text/x-patch
Size: 1024 bytes
Desc: The Git patch
Url : /pipermail/attachments/20070626/b4d16eaf/attachment.bin 

From simon at josefsson.org  Tue Jun 26 09:51:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 09:51:34 +0200
Subject: [gnutls-dev] [PATCH] Memory leak in `_gnutls_dsa_verify ()'
In-Reply-To: <87odj3mypp.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 26 Jun 2007 00:54:58 +0200")
References: <87odj3mypp.fsf@chbouib.org>
Message-ID: <87ejjztapl.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> The patch below fixes a tiny memory leak.

Hi!  Applied, thanks.  Next time, feel free to include a NEWS snippet as
well.  I now added:

** Fix memory leak during DSA signature verification.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

/Simon


From simon at josefsson.org  Tue Jun 26 09:59:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 09:59:42 +0200
Subject: [gnutls-dev] Public git repository
In-Reply-To: <87sl8ptkr6.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 18 Jun 2007 16:11:57 +0200")
References: <87sl8ptkr6.fsf@mocca.josefsson.org>
Message-ID: <87645btac1.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Unfortunately, I couldn't get the 'git-cvsserver' read-only CVS server
> working, and can't prioritize to spend more time debugging it.  If
> someone else knows how to set up git-cvsserver and wants to offer a
> read-only cvs server for the git repository, that would be very much
> appreciated.

That closes one of the goals before the gnutls 1.8 release:

* Make sure the stuff in the GIT repository (i.e., all recent work) is
  available through CVS, either through back-ports to the old server or
  a git-cvsserver approach.

Right now we have two remaining tasks before the next release:

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

I hope to be able to work on the first task during this week.  As for
the second task, there is one paper still missing, I'll check with the
FSF if they have received it yet.

/Simon


From simon at josefsson.org  Tue Jun 26 09:54:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 09:54:47 +0200
Subject: [gnutls-dev] Guile needs 1.8?
In-Reply-To: <87myyy4g8s.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Sun, 17 Jun 2007 19:56:19 +0200")
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
Message-ID: <87abuntak8.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> See attached patch: It basically uses Guile's `version' procedure to
> check whether we are using 1.8 or later.

Hi!  Thanks, applied.

/Simon


From simon at josefsson.org  Tue Jun 26 10:36:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 10:36:31 +0200
Subject: [gnutls-dev] GnuTLS 1.7.14
Message-ID: <87r6nzru28.fsf@mocca.josefsson.org>

Note that the GnuTLS 1.7.x branch is NOT what you want for your stable
system.  It is intended for developers and experienced users.

There are three remaining work items before the next stable release, and
I expect them to be solved during this week.

* Fix sign callback API to be per-credential rather than per-session.

* Check copyright papers for everyone who contributed during the 1.7.x
  phase (I opportunistically installed some fixes after confirming with
  authors that they were sending copyright assignments, although I have
  not verified that the assignment were actually received).

* Update license to (L)GPLv3.

Below is the regular release announcement...

* Version 1.7.14 (released 2007-06-26)

** Don't enable Guile bindings unless we have Guile 1.8 or later.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

** Fix memory leak during DSA signature verification.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

** Fix crash in gnutls-cli when TLS handshake fails.
Reported by Marc Haber <mh+debian-bugs at zugschlus.de> and Andreas
Metzler <ametzler at downhill.at.eu.org> via Debian BTS #429183, see
<http://bugs.debian.org/429183>.

** Minor OpenPGP fixes in stream_to_datum.
Patch from Timo Schulz <twoaday at freakmail.de> and Ludovic Court?s
<ludovic.courtes at laas.fr>.

** Fix off-by-one in TLS 1.2 handshake.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

** Minor Guile binding self-test cleanup.
Patch from Ludovic Court?s <ludovic.courtes at laas.fr>.

** Update gnulib files.

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

Here are the compressed sources (4.6MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.14.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.7.14.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.14.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.7.14.tar.bz2.sig

Here are the SHA-1 and SHA-224 checksums:

0ff2c43fead466681576c2c1cae3bac01bb648f4  gnutls-1.7.14.tar.bz2
1ab2cf7676a619375f39936d2e7fa9a749695495  gnutls-1.7.14.tar.bz2.sig

2bec7018157727542f897d3bc0c2ad73f628dcf534f13fcdf9729480  gnutls-1.7.14.tar.bz2
9b35fc78dad71ebc1db67ab940176f46164f22e90d7c9f351730b447  gnutls-1.7.14.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
Url : /pipermail/attachments/20070626/d4465610/attachment.pgp 

From simon at josefsson.org  Tue Jun 26 11:34:19 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 11:34:19 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
Message-ID: <87myynrrdw.fsf@mocca.josefsson.org>

After making the last release, I tried 'make install', but it failed:

Making install in guile
make[1]: Entering directory `/home/jas/src/gnutls/guile'
Making install in modules
make[2]: Entering directory `/home/jas/src/gnutls/guile/modules'
make[3]: Entering directory `/home/jas/src/gnutls/guile/modules'
make[3]: Nothing to be done for `install-exec-am'.
test -z "/usr/share/guile/site" || /bin/mkdir -p "/usr/share/guile/site"
 /bin/sh /home/jas/src/gnutls/build-aux/install-sh -c -m 644 'gnutls.scm' '/usr/share/guile/site/gnutls.scm'
cp: cannot create regular file `/usr/share/guile/site/_inst.15741_': Permission denied
 /bin/sh /home/jas/src/gnutls/build-aux/install-sh -c -m 644 'gnutls/extra.scm' '/usr/share/guile/site/gnutls/extra.scm'
mkdir: cannot create directory `/usr/share/guile/site/gnutls': Permission denied
mkdir: cannot create directory `/usr/share/guile/site/gnutls': Permission denied
make[3]: *** [install-nobase_dist_guilemoduleDATA] Error 1
make[3]: Leaving directory `/home/jas/src/gnutls/guile/modules'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/jas/src/gnutls/guile/modules'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/jas/src/gnutls/guile'
make: *** [install-recursive] Error 1
jas at mocca:~/src/gnutls$

This doesn't look right to me, 'make install' should never write outside
of $prefix by default; packages that do that is rather annoying at sites
with read-only /usr trees that use AFS or similar.  I'm testing the
patch below.  Ludovic, does it looks right to you?

/Simon

diff --git a/Makefile.am b/Makefile.am
index 14601ab..a55659d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,7 +20,7 @@
 # along with this file; if not, write to the Free Software Foundation,
 # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
-DISTCHECK_CONFIGURE_FLAGS = --enable-gtk-doc --with-guile-site-dir
+DISTCHECK_CONFIGURE_FLAGS = --enable-gtk-doc
 
 SUBDIRS = lgl gl includes lib libextra src
 
diff --git a/configure.in b/configure.in
index 2b392f2..a8d9c74 100644
--- a/configure.in
+++ b/configure.in
@@ -139,15 +139,15 @@ if test "x$opt_guile_bindings" = "xyes"; then
       if test $is_guile_1_8 -eq 0; then
         AC_MSG_RESULT([yes])
 	case "x$with_guile_site_dir" in 
-	     x|xno)
+	     xno)
 		# Use the default $(GUILE_SITE).
 		GUILE_SITE_DIR
 		;;
-	     xyes)
+	     x|xyes)
 		# Automatically derive $(GUILE_SITE) from $(pkgdatadir).  This
 		# hack is used to allow `distcheck' to work (see
 		# `DISTCHECK_CONFIGURE_FLAGS' in the top-level `Makefile.am').
-		GUILE_SITE="${datadir}/guile/site"
+		GUILE_SITE="@datadir@/guile/site"
 		AC_SUBST(GUILE_SITE)
 		;;
 	     *)


From simon at josefsson.org  Tue Jun 26 15:49:57 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 15:49:57 +0200
Subject: [gnutls-dev] FYI, GnuTLS on Windows Vista works
Message-ID: <87k5tqrfju.fsf@mocca.josefsson.org>

I just got my hands on a new laptop running Windows Vista, and I tried
the GnuTLS 1.6.3 Windows Installer on it, and it seemed to work fine.  I
tested both HTTPS and SMTP + STARTTLS via gnutls-cli.

/Simon


From simon at josefsson.org  Tue Jun 26 15:41:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Jun 2007 15:41:17 +0200
Subject: [gnutls-dev] Guile needs 1.8?
In-Reply-To: <87myyy4g8s.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Sun, 17 Jun 2007 19:56:19 +0200")
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
Message-ID: <87645asuiq.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

>>> I'll add a more reliable test anyway.
>
> See attached patch: It basically uses Guile's `version' procedure to
> check whether we are using 1.8 or later.

I noticed now that this didn't work...  on my system, the command
'guile' is 1.8, but the guile-dev package is 1.6.  The test only checks
that the tool is recent enough, but doesn't test the header files (which
were the ones that failed).

jas at mocca:~/src/gnutls$ dpkg -l|grep guile
ii  guile-1.6                                1.6.8-6                         The GNU extension language and Scheme interp
ii  guile-1.6-dev                            1.6.8-6                         Development files for Guile 1.6
ii  guile-1.6-libs                           1.6.8-6                         Main Guile libraries
ii  guile-1.6-slib                           1.6.8-6                         Guile SLIB support
ii  guile-1.8                                1.8.1+1-4                       The GNU extension language and Scheme interp
ii  guile-1.8-libs                           1.8.1+1-4                       Main Guile libraries
ii  guile-g-wrap                             1.9.6-3.1                       scripting interface generator for C - Guile
ii  guile-library                            0.1.2-1                         Library of useful Guile modules
ii  libguile-ltdl-1                          1.6.8-6                         Guile's patched version of libtool's libltdl
jas at mocca:~/src/gnutls$

>> Perhaps a test for the feature that seems to break things here?
>> SCM_API, scm_t_bits, or whatever it might have been.
>
> No.  Those types and macros are actually defined in 1.6 as well.  It
> just turned out that for some reason their definitions were not visible.
>
> Anyway, such a feature test wouldn't help since 1.6 and 1.8 are
> significantly different API-wise.

So, I still think it is better to test for some particular feature in
the guile header files that is required by the guile bindings, which is
available in v1.8 but not in v1.6.  I installed the patch below, what do
you think?

/Simon

commit 6b1da319e3997386458242d50a6a14c71af81873
Author: Simon Josefsson <simon at josefsson.org>
Date:   Tue Jun 26 15:24:15 2007 +0200

    Check that the guile header files is recent enough and that it works.

diff --git a/NEWS b/NEWS
index 5761d8c..3c6c3a6 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,11 @@ See the end for copying conditions.
 
 * Version 1.7.15 (unreleased)
 
+** Test that the Guile header files are recent enough to work.
+Before we just tested that the command line tool 'guile' was recent
+enough, which may not be sufficient if you still have an old
+libguile.h header installed.
+
 ** Guile bindings are now installed under $prefix by default.
 Use --without-guile-site-dir to install it under $pkgdatadir/site/
 where $pkgdatadir is as returned by "guile-config info pkgdatadir".
diff --git a/configure.in b/configure.in
index f38838d..4ff951e 100644
--- a/configure.in
+++ b/configure.in
@@ -311,11 +311,13 @@ if test "x$opt_guile_bindings" = "xyes"; then
       GUILE_PROGS
       GUILE_FLAGS
 
-      AC_MSG_CHECKING([whether GNU Guile 1.8 or later is available])
-      GUILE_CHECK([is_guile_1_8],
-         [(exit (string>=? (version) (number->string 1.8)))])
+      AC_MSG_CHECKING([whether GNU Guile is recent enough])
+      AC_COMPILE_IFELSE(AC_LANG_PROGRAM([
+	#include <libguile.h>
+SCM_API scm_t_bits scm_tc16_gnutls_cipher_enum;]),
+	recent_guile=yes,recent_guile=no)
 
-      if test $is_guile_1_8 -eq 0; then
+      if test "$recent_guile" = yes; then
         AC_MSG_RESULT([yes])
 	case "x$with_guile_site_dir" in 
 	     xno)
@@ -337,7 +339,7 @@ if test "x$opt_guile_bindings" = "xyes"; then
 	esac
       else
         AC_MSG_RESULT([no])
-        AC_MSG_WARN([GNU Guile 1.8 or later is required.  Guile bindings not built.])
+        AC_MSG_WARN([A sufficiently recent GNU Guile not found.  Guile bindings not built.])
         opt_guile_bindings=no
       fi
    fi


From ludo at gnu.org  Tue Jun 26 22:51:18 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 26 Jun 2007 22:51:18 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
References: <87myynrrdw.fsf@mocca.josefsson.org>
Message-ID: <87d4zih22h.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> After making the last release, I tried 'make install', but it failed:

> This doesn't look right to me, 'make install' should never write outside
> of $prefix by default; packages that do that is rather annoying at sites
> with read-only /usr trees that use AFS or similar.

Agreed.

That said, Guile files must go in a directory that is in Guile's "load
path".  The one directory that is known to be in Guile's load path is
`$(GUILE_SITE)', hence the `GUILE_SITE_DIR' M4 macro.

If Guile files goes to some arbitrary directory, e.g.,
`$(pkgdatadir)/guile', then Guile simply won't be able to find them,
unless the user manually updates their `GUILE_LOAD_PATH' environment
variable or add `-L' switches when they run `guile'.

  (To test whether Guile finds the relevant files, just type:

     $ guile
     guile> (use-modules (gnutls) (gnutls extra))

   If no error message gets displayed, then everything's alright.)

Thus, the patch doesn't look right to me.

Now, I'm well aware that this `$(GUILE_SITE)' thing is annoying.  There
were attempts in the past to improve on this on the Guile side but none
of them were fruitful.

AFAICS, Perl, Python and Emacs also have a fixed central `site'
directory (at least, that's how files are laid out in Debian).  Now, if
you have a better idea, I'm all ears.  ;-)

Thanks,
Ludovic.



From ludo at gnu.org  Tue Jun 26 22:35:34 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 26 Jun 2007 22:35:34 +0200
Subject: [gnutls-dev] Guile needs 1.8?
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
	<87645asuiq.fsf@mocca.josefsson.org>
Message-ID: <874pkulai1.fsf@chbouib.org>

A non-text attachment was scrubbed...
Name: ,,configure.patch
Type: text/x-patch
Size: 911 bytes
Desc: The patch
Url : /pipermail/attachments/20070626/a92c9904/attachment.bin 

From simon at josefsson.org  Wed Jun 27 11:39:18 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Jun 2007 11:39:18 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
In-Reply-To: <87d4zih22h.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 26 Jun 2007 22:51:18 +0200")
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
Message-ID: <87tzstpwhl.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> After making the last release, I tried 'make install', but it failed:
>
>> This doesn't look right to me, 'make install' should never write outside
>> of $prefix by default; packages that do that is rather annoying at sites
>> with read-only /usr trees that use AFS or similar.
>
> Agreed.
>
> That said, Guile files must go in a directory that is in Guile's "load
> path".  The one directory that is known to be in Guile's load path is
> `$(GUILE_SITE)', hence the `GUILE_SITE_DIR' M4 macro.
>
> If Guile files goes to some arbitrary directory, e.g.,
> `$(pkgdatadir)/guile', then Guile simply won't be able to find them,
> unless the user manually updates their `GUILE_LOAD_PATH' environment
> variable or add `-L' switches when they run `guile'.
>
>   (To test whether Guile finds the relevant files, just type:
>
>      $ guile
>      guile> (use-modules (gnutls) (gnutls extra))
>
>    If no error message gets displayed, then everything's alright.)
>
> Thus, the patch doesn't look right to me.
>
> Now, I'm well aware that this `$(GUILE_SITE)' thing is annoying.  There
> were attempts in the past to improve on this on the Guile side but none
> of them were fruitful.
>
> AFAICS, Perl, Python and Emacs also have a fixed central `site'
> directory (at least, that's how files are laid out in Debian).  Now, if
> you have a better idea, I'm all ears.  ;-)

Right, it is the same problem as for perl, python, emacs etc and other
similar systems that use a local package repository.  I think the best
we can do is to offer these options:

1: Install GnuTLS guile bindings under our $prefix, and ask users to put
the directory in their load-path.

2: Ask users to configure using
--with-guile-site-dir=/usr/share/guile/site and getting the proper
rights to that directory.

3: Ask users to build using --prefix=/usr

4: Ask users to get their package built from some distribution that does
the right thing (--prefix=/usr).

The majority of users will do #4, and the others should be experienced
enough to be able to do #1-#3 or something different.

Do you think we could add something about this to the manual?  How would
a user append the load-path in Guile?  There is no 'load-path'
variable...  Maybe an example would be useful.

Generally, I think it would be nice if Guile was changed to look into
/usr/local/share/guile/site as well.  Emacs and perl do this by default,
I believe:

jas at mocca:~$ emacs21 --no-site-file -q -eval '(pp load-path)' --batch
("/etc/emacs21" "/etc/emacs" "/usr/local/share/emacs/21.4/site-lisp" "/usr/local/share/emacs/site-lisp" "/usr/share/emacs/21.4/site-lisp" "/usr/share/emacs/21.4/site-lisp/dictionaries-common" "/usr/share/emacs/21.4/site-lisp/gtk-doc-tools" "/usr/share/emacs/21.4/site-lisp/w3m" "/usr/share/emacs/21.4/site-lisp/w3m/shimbun" "/usr/share/emacs/site-lisp" "/usr/share/emacs/21.4/leim" "/usr/share/emacs/21.4/lisp" "/usr/share/emacs/21.4/lisp/toolbar" "/usr/share/emacs/21.4/lisp/textmodes" "/usr/share/emacs/21.4/lisp/progmodes" "/usr/share/emacs/21.4/lisp/play" "/usr/share/emacs/21.4/lisp/obsolete" "/usr/share/emacs/21.4/lisp/net" "/usr/share/emacs/21.4/lisp/mail" "/usr/share/emacs/21.4/lisp/language" "/usr/share/emacs/21.4/lisp/international" "/usr/share/emacs/21.4/lisp/gnus" "/usr/share/emacs/21.4/lisp/eshell" "/usr/share/emacs/21.4/lisp/emulation" "/usr/share/emacs/21.4/lisp/emacs-lisp" "/usr/share/emacs/21.4/lisp/calendar")
jas at mocca:~$

jas at mocca:~$ perl -e 'foreach (@INC) { print "$_\n" }'
/etc/perl
/usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
jas at mocca:~$

/Simon


From simon at josefsson.org  Wed Jun 27 11:48:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Jun 2007 11:48:20 +0200
Subject: [gnutls-dev] Guile needs 1.8?
In-Reply-To: <874pkulai1.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 26 Jun 2007 22:35:34 +0200")
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
	<87645asuiq.fsf@mocca.josefsson.org> <874pkulai1.fsf@chbouib.org>
Message-ID: <87ps3hpw2j.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I noticed now that this didn't work...  on my system, the command
>> 'guile' is 1.8, but the guile-dev package is 1.6.
>
> Hmm, annoying.  I think `guile-1.8-libs' should conflict with
> `guile-1.6-dev', although that'd look strange.

Hi!  I think it is common in Debian to allow multiple versions of
libraries to be installed, and that they don't conflict with *-dev
packages unless the ABI isn't backwards incompatible.  In this case,
doesn't the guile 1.8 libraries support the 1.6 API/ABI?  If that isn't
the case, then I agree with you.

> The reason is that in this case, the Guile M4 macros see
> `guile-config' from 1.6 but see `guile' from 1.8...

My view is that the Guile M4 macros are broken here, the autoconf
approach is to test for the features you need instead of relying on
version information.  Using guile-config to get some necessary
parameters is fine, but then the macros need also check that the setup
is sane.

>>> No.  Those types and macros are actually defined in 1.6 as well.  It
>>> just turned out that for some reason their definitions were not visible.
>>>
>>> Anyway, such a feature test wouldn't help since 1.6 and 1.8 are
>>> significantly different API-wise.
>>
>> So, I still think it is better to test for some particular feature in
>> the guile header files that is required by the guile bindings, which is
>> available in v1.8 but not in v1.6.  I installed the patch below, what do
>> you think?
>
>> +      AC_COMPILE_IFELSE(AC_LANG_PROGRAM([
>> +	#include <libguile.h>
>> +SCM_API scm_t_bits scm_tc16_gnutls_cipher_enum;]),
>> +	recent_guile=yes,recent_guile=no)
>
> This only fails because `SCM_API' is undefined in 1.6.  Well, that's a
> sufficient reason, but not a strong one.

Right, but the GnuTLS guile bindings use and need SCM_API, so that
seemed like a good thing to test for.

> Instead, I prefer the solution below that tries to link against Guile
> and check for a function that appeared in 1.8 and will never appear in
> 1.6.
>
> Does it look ok?

I'm not sure, do the GnuTLS guile bindings uses and require the
scm_from_locale_string function?

To see the advantage of testing for the features you need, consider if
someone backports the SCM_API stuff from guile 1.8 to guile 1.6, but not
scm_from_locale_string.  Then the GnuTLS guile bindings might start to
work with guile 1.6.  I don't know what other features from guile 1.8
gnutls-guile needs, but it may be possible to backport all of them from
1.8 to 1.6.  This might not happen in this case, but there is no big
cost in associated with not assuming that.

/Simon


From simon at josefsson.org  Wed Jun 27 12:27:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Jun 2007 12:27:45 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <874plb9283.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 13 Jun 2007 19:46:36 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87k5uamcq3.fsf@chbouib.org>
	<87ir9t8ent.fsf@mocca.josefsson.org> <874plb9283.fsf@chbouib.org>
Message-ID: <874pktpu8u.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> After reading the man pages for those tools, I decided to go with
>> 'git-am --signoff < ,,diff'.  It was quite painless.  Thanks for the
>> patch, applied.
>
> Cool.
>
> I just sent a couple of patches but I copied (part of) the output of
> `git-format-patch' in-line instead of attaching it.  Since I'm posting
> through Gmane, I can't just "git-format-patch --stdout | mail gnutls-dev"
> so this is not very convenient.

Inline works OK with me.

> I can't seem to find a convenient interface for use with Gnus,
> unfortunately.

For the record, I mark your patch in an email buffer (typically starting
with 'From' on the line that starts with '>From'), then use M-x
shell-command-on-region RET (cd ~/src/gnutls;git-am -s) RET to install
it.

/Simon


From simon at josefsson.org  Wed Jun 27 12:25:09 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Jun 2007 12:25:09 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <874pldi4l3.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue, 12 Jun 2007 17:18:32 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
Message-ID: <878xa5pud6.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Still, the paths look right for me:
>
> I think I got it (I hope so!):
>
>   * On my machine, Guile is installed in `/usr/local/'.  Thus,
>     `GUILE_LDFLAGS' contain `-L /usr/local/lib', which leads Libtool to
>     add `/usr/local/lib' to RPATH.
>
>   * On your machine, Guile is installed in `/usr', so this does not
>     happen.  And a `-L /usr/local/lib' to your Libtool link command-line
>     and you'll make the same observations as I do.
>
> Unless I'm mistaken, the fix is to revert your `_LIBADD' patch and get
> back to something along the lines of:
>
>   libXXX_LDFLAGS = $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
>                    $(GUILE_LDFLAGS)
>
> which makes sure that third-party libs (here, Guile) appear last.

I didn't reply to this mail.  Is this still a problem for you?  I think
it is more correct to use LIBADD rather than LDFLAGS here, so I'd like
to debug why that doesn't work (and possibly report it as a bug) before
making a change.

/Simon


From ludo at gnu.org  Wed Jun 27 22:29:46 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 27 Jun 2007 22:29:46 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
	<878xa5pud6.fsf@mocca.josefsson.org>
Message-ID: <878xa5dttx.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> ludo at chbouib.org (Ludovic Court?s) writes:
>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> Still, the paths look right for me:
>>
>> I think I got it (I hope so!):
>>
>>   * On my machine, Guile is installed in `/usr/local/'.  Thus,
>>     `GUILE_LDFLAGS' contain `-L /usr/local/lib', which leads Libtool to
>>     add `/usr/local/lib' to RPATH.
>>
>>   * On your machine, Guile is installed in `/usr', so this does not
>>     happen.  And a `-L /usr/local/lib' to your Libtool link command-line
>>     and you'll make the same observations as I do.
>>
>> Unless I'm mistaken, the fix is to revert your `_LIBADD' patch and get
>> back to something along the lines of:
>>
>>   libXXX_LDFLAGS = $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
>>                    $(GUILE_LDFLAGS)
>>
>> which makes sure that third-party libs (here, Guile) appear last.
>
> I didn't reply to this mail.  Is this still a problem for you?  I think
> it is more correct to use LIBADD rather than LDFLAGS here, so I'd like
> to debug why that doesn't work (and possibly report it as a bug) before
> making a change.

Well, I had forgotten about it too, but that's still valid.  ;-)

To sum up: on my machine, Guile is installed in `/usr/local/lib', and so
is GnuTLS.  The libtool link command-line looks like:

  -L/usr/local/lib -lguile  ...  ../../lib/libgnutls.la  ... \
  -o libguile-gnutls.la

The first `-L' leads libtool to add `/usr/local/lib' to the RPATH of
`libguile-gnutls.so'; the `../../lib/libgnutls.la' that follows leads
libtool to *append* `../../lib/.libs' to the RPATH.  Consequently, the
`libgnutls.so' and `libguile-gnutls.so' that are picked up at run-time
are those from `/usr/local/lib', *not* the freshly-built ones.

The proposed fix (above) fixes the problem.  That the `XXX_LIBS' vars
would better fit in `XXX_LIBADD' than in `XXX_LDFLAGS' really isn't an
issue: there's nothing in the libtool manual that forbids listing
libtool archives as part of LDFLAGS.

Is that clearer?

Thanks,
Ludovic.



From ludo at gnu.org  Wed Jun 27 22:49:53 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 27 Jun 2007 22:49:53 +0200
Subject: [gnutls-dev] Guile needs 1.8?
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
	<87645asuiq.fsf@mocca.josefsson.org> <874pkulai1.fsf@chbouib.org>
	<87ps3hpw2j.fsf@mocca.josefsson.org>
Message-ID: <87ejjx9l72.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  I think it is common in Debian to allow multiple versions of
> libraries to be installed, and that they don't conflict with *-dev
> packages unless the ABI isn't backwards incompatible.  In this case,
> doesn't the guile 1.8 libraries support the 1.6 API/ABI?

Oh, you're right: 1.8 does support (in deprecated form) the 1.6 API (and
ABI too, I think).

> My view is that the Guile M4 macros are broken here, the autoconf
> approach is to test for the features you need instead of relying on
> version information.

The Guile M4 macros don't check for versions.  I added such a check in
GnuTLS to address your (valid) concerns.

Guile has a versioning policy similar to that of GnuTLS: odd-numbered
branches are unstable and even-numbered branches are stable; there *are*
significant API changes between two subsequent stable branches, although
the previous stable API is still supported (and deprecated).

The switch from 1.6 to 1.8 was such a major change.  New features were
added and the API was overhauled.  The GnuTLS bindings are written
against the 1.8 API.  They also use features that were not available in
1.6 and never will, such as SRFI-4 vectors.  There's no way they could
someday "work" with 1.6.

Therefore, checking for *specific* features (such or such macro or
function) is irrelevant: we really want the whole shebang, not just one
macro.  Checking for `scm_from_locale_string ()' allows us to know that
we really get 1.8 (or some later backward-compatible version): this is
one of the functions that was introduced in 1.8 and that will definitely
never be available in 1.6.

> I'm not sure, do the GnuTLS guile bindings uses and require the
> scm_from_locale_string function?

Yes, they do require this specific function.  But even if they didn't,
that would still make sense to check for it, for the reasons outlined
above.

I hope this clarifies the rationale for the autoconf tests.

Thanks,
Ludovic.



From ludo at gnu.org  Wed Jun 27 23:21:04 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 27 Jun 2007 23:21:04 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
	<87tzstpwhl.fsf@mocca.josefsson.org>
Message-ID: <874pkt6qm7.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Right, it is the same problem as for perl, python, emacs etc and other
> similar systems that use a local package repository.  I think the best
> we can do is to offer these options:
>
> 1: Install GnuTLS guile bindings under our $prefix, and ask users to put
> the directory in their load-path.
>
> 2: Ask users to configure using
> --with-guile-site-dir=/usr/share/guile/site and getting the proper
> rights to that directory.

The idea of having something that purposefully fails by default seems
questionable.  :-)

> 3: Ask users to build using --prefix=/usr

Why?  Isn't it equivalent to removing the `--prefix' option altogether?

> 4: Ask users to get their package built from some distribution that does
> the right thing (--prefix=/usr).
>
> The majority of users will do #4

Fortunately...  ;-)

> Do you think we could add something about this to the manual?  How would
> a user append the load-path in Guile?  There is no 'load-path'
> variable...  Maybe an example would be useful.

It's called `%load-path':

  http://www.gnu.org/software/guile/manual/html_node/Build-Config.html

Rather than writing a Scheme snipped that modifies `%load-path', people
would rather change the `GUILE_LOAD_PATH' environment variable or add
`-L' switches to the Guile command-line.  Having to do one of these is
not convenient, though.

What I initially did was to add `--with-guile-site-dir'.  Its purpose
was two-fold:

  1. Allow `distcheck' to work, by automatically using it (through
     Automake's `DISTCHECK_CONFIGURE_FLAGS').

  2. Allow users who really don't want to install to `$(GUILE_SITE)' and
     who know what they are doing to specify another installation
     directory.

Doesn't it seem reasonable?  Perhaps `--with-guile-site-dir' should be
mentioned in the manual?

> Generally, I think it would be nice if Guile was changed to look into
> /usr/local/share/guile/site as well.

Hmm, not sure if that would help much.  And then why not
`/opt/guile/site' as well, or `/gnu/guile/site', etc.?

Thanks,
Ludovic.



From simon at josefsson.org  Thu Jun 28 11:48:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 28 Jun 2007 11:48:55 +0200
Subject: [gnutls-dev] GnuTLS vs OpenSSL vs NSS
In-Reply-To: <46830907.1080602@REDHAT.COM> (Robert Relyea's message of "Wed,
	27 Jun 2007 18:04:07 -0700")
References: <6738615.19821180139659054.JavaMail.nabble@isper.nabble.com>
	<87irafnsoz.fsf@mocca.josefsson.org> <46830907.1080602@REDHAT.COM>
Message-ID: <87zm2kl88o.fsf@mocca.josefsson.org>

Thanks for the additional information, I updated the page again.

(Although for some reason the gnu.org web pages aren't updated, but the
change is available from http://josefsson.org/gnutls/comparison.html
meanwhile.)

/Simon

Robert Relyea <rrelyea at redhat.com> writes:

> Sigh trying to keep up with email.
>
>
> thanks simon for updating the table..
>
> Simon Josefsson wrote:
>> rrelyea at redhat.com writes:
>>
>>   
>>> Under portability concerns, NSS should read:
>>>
>>> NSS Platform requirements - NSPR* Network requirements - NSPR* thread
>>> safety- NSPR* (uses native platform threads when available, provides
>>> thread implementation if f necessary) Random Seed - set through native
>>> OS API, extra entropy grab from installed PKCS #11 modules,
>>> application can also add entropy on the fly
>>>     
>>
>> Added most of it, but I don't understand the last part -- how is the
>> random seed set through a 'native OS API'?  Does this refer to some NSPR
>> API?  Or what OS APIs do you mean?  I'm not aware of any standard APIs
>> for setting random seeds.
>>   
> There isn't a standard API. For Unix/Linux it uses /dev/urandom if
> available, for Windows it uses CAPI. For all platforms it gets data
> from clock, and tries to open system files. NSS has a set of platform
> dependent functions is uses to determine randomness. You are right,
> they probably should live in NSPR.
>
> bob


From simon at josefsson.org  Thu Jun 28 17:15:59 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 28 Jun 2007 17:15:59 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
In-Reply-To: <874pkt6qm7.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 27 Jun 2007 23:21:04 +0200")
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
	<87tzstpwhl.fsf@mocca.josefsson.org> <874pkt6qm7.fsf@chbouib.org>
Message-ID: <87tzssjej4.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Right, it is the same problem as for perl, python, emacs etc and other
>> similar systems that use a local package repository.  I think the best
>> we can do is to offer these options:
>>
>> 1: Install GnuTLS guile bindings under our $prefix, and ask users to put
>> the directory in their load-path.
>>
>> 2: Ask users to configure using
>> --with-guile-site-dir=/usr/share/guile/site and getting the proper
>> rights to that directory.
>
> The idea of having something that purposefully fails by default seems
> questionable.  :-)

Hm, it wouldn't fail if the user did acquire the proper rights on the
directory, would it?  Some people do './configure && make' as a user,
and then run 'make install' as root.  Then #2 would work.

>> 3: Ask users to build using --prefix=/usr
>
> Why?  Isn't it equivalent to removing the `--prefix' option altogether?

No, the default --prefix us /usr/local.  If the user builds with
--prefix=/usr, the guile paths will be correct.  Although the user will
have the same problem as in #2 regarding write access.

>> Do you think we could add something about this to the manual?  How would
>> a user append the load-path in Guile?  There is no 'load-path'
>> variable...  Maybe an example would be useful.
>
> It's called `%load-path':
>
>   http://www.gnu.org/software/guile/manual/html_node/Build-Config.html
>
> Rather than writing a Scheme snipped that modifies `%load-path', people
> would rather change the `GUILE_LOAD_PATH' environment variable or add
> `-L' switches to the Guile command-line.  Having to do one of these is
> not convenient, though.

Still, if one assumes that one cannot write outside of $prefix (i.e.,
/usr/local), I don't see what else we can do.

> What I initially did was to add `--with-guile-site-dir'.  Its purpose
> was two-fold:
>
>   1. Allow `distcheck' to work, by automatically using it (through
>      Automake's `DISTCHECK_CONFIGURE_FLAGS').
>
>   2. Allow users who really don't want to install to `$(GUILE_SITE)' and
>      who know what they are doing to specify another installation
>      directory.
>
> Doesn't it seem reasonable?

I believe it is more important to not install anything outside of
$prefix by default.  From the GNU coding standards:

   Installers are expected to override these values when calling `make'
(e.g., `make prefix=/usr install' or `configure' (e.g., `configure
--prefix=/usr').  GNU packages should not try to guess which value
should be appropriate for these variables on the system they are being
installed onto: use the default settings specified here so that all GNU
packages behave identically, allowing the installer to achieve any
desired layout.

   These two variables set the root for the installation.  All the other
installation directories should be subdirectories of one of these two,
and nothing should be directly installed into these two directories.

`prefix'
...

> Perhaps `--with-guile-site-dir' should be mentioned in the manual?

Yes, although I now believe it has a slightly different purpose as
described in the NEWS entry:

** Guile bindings are now installed under $prefix by default.
Use --without-guile-site-dir to install it under $pkgdatadir/site/
where $pkgdatadir is as returned by "guile-config info pkgdatadir".
Use --with-guile-site-dir=/your/own/path to specify the path manually.
The default, --with-guile-site-dir, will install the Guile bindings
under $datadir/guile/site.

This really belongs in the manual though.

>> Generally, I think it would be nice if Guile was changed to look into
>> /usr/local/share/guile/site as well.
>
> Hmm, not sure if that would help much.  And then why not
> `/opt/guile/site' as well, or `/gnu/guile/site', etc.?

/usr/local is intended for local additions, so it makes some sense.

/Simon


From ludo at gnu.org  Thu Jun 28 23:08:01 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 28 Jun 2007 23:08:01 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
	<87tzstpwhl.fsf@mocca.josefsson.org> <874pkt6qm7.fsf@chbouib.org>
	<87tzssjej4.fsf@mocca.josefsson.org>
Message-ID: <87lke323f2.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> ludo at gnu.org (Ludovic Court?s) writes:
>
>> Hi,
>>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> Right, it is the same problem as for perl, python, emacs etc and other
>>> similar systems that use a local package repository.  I think the best
>>> we can do is to offer these options:
>>>
>>> 1: Install GnuTLS guile bindings under our $prefix, and ask users to put
>>> the directory in their load-path.
>>>
>>> 2: Ask users to configure using
>>> --with-guile-site-dir=/usr/share/guile/site and getting the proper
>>> rights to that directory.
>>
>> The idea of having something that purposefully fails by default seems
>> questionable.  :-)
>
> Hm, it wouldn't fail if the user did acquire the proper rights on the
> directory, would it?  Some people do './configure && make' as a user,
> and then run 'make install' as root.  Then #2 would work.

Sure, this would work.  By "fails by default", I meant this:

  $ ./configure && make && sudo make install
  $ guile
  guile> (use-modules (gnutls))
  <unnamed port>: no code for module (gnutls)

Users would have to go through the manual or `README' and find out the
right option.

> If the user builds with --prefix=/usr, the guile paths will be
> correct.

But `$(GUILE_SITE)' could be anything outside `/usr'.

> I believe it is more important to not install anything outside of
> $prefix by default.

Well, we definitely have to make a compromise.  I won't fight strongly
against having Guile code installed under `$prefix'.  Nevertheless, I
believe that Guile users will likely be surprised to see that it
"doesn't work out of the box".

BTW, Libtool issues a message at installation-time in this sort of
circumstance:

  ----------------------------------------------------------------------
  Libraries have been installed in:
     /usr/local/lib

  If you ever happen to want to link against installed libraries
  in a given directory, LIBDIR, you must either use libtool, and
  specify the full pathname of the library, or use the `-LLIBDIR'
  flag during linking and do at least one of the following:
     - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
       during execution
     - add LIBDIR to the `LD_RUN_PATH' environment variable
       during linking
     - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
     - have your system administrator add LIBDIR to `/etc/ld.so.conf'

Maybe something similar should be done when installing Guile modules?

For the time being, let's say we can keep you approach and see if we get
feedback.

Thanks,
Ludovic.



From simon at josefsson.org  Fri Jun 29 16:21:08 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 16:21:08 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <878xa5dttx.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 27 Jun 2007 22:29:46 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
	<878xa5pud6.fsf@mocca.josefsson.org> <878xa5dttx.fsf@chbouib.org>
Message-ID: <87k5tmhmej.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> ludo at chbouib.org (Ludovic Court?s) writes:
>>
>>> Simon Josefsson <simon at josefsson.org> writes:
>>>
>>>> Still, the paths look right for me:
>>>
>>> I think I got it (I hope so!):
>>>
>>>   * On my machine, Guile is installed in `/usr/local/'.  Thus,
>>>     `GUILE_LDFLAGS' contain `-L /usr/local/lib', which leads Libtool to
>>>     add `/usr/local/lib' to RPATH.
>>>
>>>   * On your machine, Guile is installed in `/usr', so this does not
>>>     happen.  And a `-L /usr/local/lib' to your Libtool link command-line
>>>     and you'll make the same observations as I do.
>>>
>>> Unless I'm mistaken, the fix is to revert your `_LIBADD' patch and get
>>> back to something along the lines of:
>>>
>>>   libXXX_LDFLAGS = $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
>>>                    $(GUILE_LDFLAGS)
>>>
>>> which makes sure that third-party libs (here, Guile) appear last.
>>
>> I didn't reply to this mail.  Is this still a problem for you?  I think
>> it is more correct to use LIBADD rather than LDFLAGS here, so I'd like
>> to debug why that doesn't work (and possibly report it as a bug) before
>> making a change.
>
> Well, I had forgotten about it too, but that's still valid.  ;-)
>
> To sum up: on my machine, Guile is installed in `/usr/local/lib', and so
> is GnuTLS.  The libtool link command-line looks like:
>
>   -L/usr/local/lib -lguile  ...  ../../lib/libgnutls.la  ... \
>   -o libguile-gnutls.la
>
> The first `-L' leads libtool to add `/usr/local/lib' to the RPATH of
> `libguile-gnutls.so'; the `../../lib/libgnutls.la' that follows leads
> libtool to *append* `../../lib/.libs' to the RPATH.  Consequently, the
> `libgnutls.so' and `libguile-gnutls.so' that are picked up at run-time
> are those from `/usr/local/lib', *not* the freshly-built ones.
>
> The proposed fix (above) fixes the problem.  That the `XXX_LIBS' vars
> would better fit in `XXX_LIBADD' than in `XXX_LDFLAGS' really isn't an
> issue: there's nothing in the libtool manual that forbids listing
> libtool archives as part of LDFLAGS.
>
> Is that clearer?

Thanks.  I've now built installed guile-1.8.1 locally and was able to
reproduce the problem.

I re-read the automake manual on this, and it says:

`maude_LIBADD'
     Extra objects can be added to a _library_ using the `_LIBADD'
     variable.  For instance, this should be used for objects
     determined by `configure' (*note A Library::).

     In the case of libtool libraries, `maude_LIBADD' can also refer to
     other libtool libraries.

`maude_LDADD'
     Extra objects (`*.$(OBJEXT)') and libraries (`*.a', `*.la') can be
     added to a _program_ by listing them in the `_LDADD' variable.
     For instance, this should be used for objects determined by
     `configure' (*note Linking::).

     `_LDADD' and `_LIBADD' are inappropriate for passing
     program-specific linker flags (except for `-l', `-L', `-dlopen'
     and `-dlpreopen').  Use the `_LDFLAGS' variable for this purpose.

     For instance, if your `configure.ac' uses `AC_PATH_XTRA', you
     could link your program against the X libraries like so:

          maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)

     We recommend that you use `-l' and `-L' only when referring to
     third-party libraries, and give the explicit file names of any
     library built by your package.  Doing so will ensure that
     `maude_DEPENDENCIES' (see below) is correctly defined by default.

This suggests to me that we shouldn't use LDFLAGS at all for any -lguile
-L/usr/local/lib stuff, and I installed the following patch.

Does this work for you?

/Simon

commit 1020d967f04532f5f39f2d4906b1f1d7893c58e1
Author: Simon Josefsson <simon at josefsson.org>
Date:   Fri Jun 29 16:16:24 2007 +0200

    Put $(GUILE_FLAGS) in LIBADD, not LDFLAGS.
    Reported by ludo at gnu.org (Ludovic Court?s).

diff --git a/guile/src/Makefile.am b/guile/src/Makefile.am
index 7db4bec..daaab28 100644
--- a/guile/src/Makefile.am
+++ b/guile/src/Makefile.am
@@ -46,18 +46,17 @@ GNULIB_CFLAGS  = -I$(top_builddir)/lgl -I$(top_srcdir)/lgl
 libguile_gnutls_v_0_la_SOURCES = core.c errors.c utils.c
 libguile_gnutls_v_0_la_CFLAGS =			\
   $(AM_CFLAGS) $(GNULIB_CFLAGS) $(GUILE_CFLAGS)
-libguile_gnutls_v_0_la_LDFLAGS = $(GUILE_LDFLAGS)
-libguile_gnutls_v_0_la_LIBADD =			\
-  $(GNUTLS_CORE_LIBS) $(GNULIB_LIBS)
+libguile_gnutls_v_0_la_LIBADD = \
+	$(GNUTLS_CORE_LIBS) $(GNULIB_LIBS) \
+	$(GUILE_LDFLAGS)
 
 libguile_gnutls_extra_v_0_la_SOURCES = extra.c
 libguile_gnutls_extra_v_0_la_CFLAGS =		\
   $(AM_CFLAGS) $(GNULIB_CFLAGS) $(GUILE_CFLAGS)
-libguile_gnutls_extra_v_0_la_LDFLAGS = $(GUILE_LDFLAGS)
 libguile_gnutls_extra_v_0_la_LIBADD =		\
   $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS)	\
   $(builddir)/libguile-gnutls-v-0.la		\
-  $(GNULIB_LIBS)
+  $(GNULIB_LIBS) $(GUILE_LDFLAGS)
 
 AM_CPPFLAGS = -I$(top_builddir) -I$(builddir)
 


From simon at josefsson.org  Fri Jun 29 16:32:28 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 16:32:28 +0200
Subject: [gnutls-dev] Guile needs 1.8?
In-Reply-To: <87ejjx9l72.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Wed, 27 Jun 2007 22:49:53 +0200")
References: <87k5u6dhob.fsf@mocca.josefsson.org> <87lkemwsk1.fsf@laas.fr>
	<87zm328opq.fsf@mocca.josefsson.org> <87myyy4g8s.fsf@chbouib.org>
	<87645asuiq.fsf@mocca.josefsson.org> <874pkulai1.fsf@chbouib.org>
	<87ps3hpw2j.fsf@mocca.josefsson.org> <87ejjx9l72.fsf@chbouib.org>
Message-ID: <87fy4ahlvn.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi!  I think it is common in Debian to allow multiple versions of
>> libraries to be installed, and that they don't conflict with *-dev
>> packages unless the ABI isn't backwards incompatible.  In this case,
>> doesn't the guile 1.8 libraries support the 1.6 API/ABI?
>
> Oh, you're right: 1.8 does support (in deprecated form) the 1.6 API (and
> ABI too, I think).

Ok.

>> My view is that the Guile M4 macros are broken here, the autoconf
>> approach is to test for the features you need instead of relying on
>> version information.
>
> The Guile M4 macros don't check for versions.  I added such a check in
> GnuTLS to address your (valid) concerns.

Thanks.

> Guile has a versioning policy similar to that of GnuTLS: odd-numbered
> branches are unstable and even-numbered branches are stable; there *are*
> significant API changes between two subsequent stable branches, although
> the previous stable API is still supported (and deprecated).
>
> The switch from 1.6 to 1.8 was such a major change.  New features were
> added and the API was overhauled.  The GnuTLS bindings are written
> against the 1.8 API.  They also use features that were not available in
> 1.6 and never will, such as SRFI-4 vectors.  There's no way they could
> someday "work" with 1.6.
>
> Therefore, checking for *specific* features (such or such macro or
> function) is irrelevant: we really want the whole shebang, not just one
> macro.  Checking for `scm_from_locale_string ()' allows us to know that
> we really get 1.8 (or some later backward-compatible version): this is
> one of the functions that was introduced in 1.8 and that will definitely
> never be available in 1.6.
>
>> I'm not sure, do the GnuTLS guile bindings uses and require the
>> scm_from_locale_string function?
>
> Yes, they do require this specific function.  But even if they didn't,
> that would still make sense to check for it, for the reasons outlined
> above.
>
> I hope this clarifies the rationale for the autoconf tests.

Yes, thanks for explaining.  I installed the patch.

/Simon


From simon at josefsson.org  Fri Jun 29 17:06:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 17:06:31 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
In-Reply-To: <87lke323f2.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Thu, 28 Jun 2007 23:08:01 +0200")
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
	<87tzstpwhl.fsf@mocca.josefsson.org> <874pkt6qm7.fsf@chbouib.org>
	<87tzssjej4.fsf@mocca.josefsson.org> <87lke323f2.fsf@chbouib.org>
Message-ID: <87bqeyhkaw.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Sure, this would work.  By "fails by default", I meant this:
>
>   $ ./configure && make && sudo make install
>   $ guile
>   guile> (use-modules (gnutls))
>   <unnamed port>: no code for module (gnutls)
>
> Users would have to go through the manual or `README' and find out the
> right option.

They need to read some instructions anyway, the above won't work unless
the user has also added /usr/local/lib to /etc/ld.so.conf or set
LD_LIBRARY_PATH to where libguile-gnutls-v-0.so is installed.  Otherwise
you get error messages such as:

guile> (use-modules (gnutls))
...
In /usr/local/share/guile/site/gnutls.scm:
 361: 32* [load-extension "libguile-gnutls-v-0" "scm_init_gnutls"]

/usr/share/guile/site/gnutls.scm:361:1: In procedure dynamic-link in expression (load-extension "libguile-gnutls-v-0" "scm_init_gnutls"):
/usr/share/guile/site/gnutls.scm:361:1: file: "libguile-gnutls-v-0", message: "libguile-gnutls-v-0.so: cannot open shared object file: No such file or directory"
ABORT: (misc-error)
guile>

I think the few users that will be affected by this need to read up on
how to install things for their environment, in particular do one of:

1) Set %load-path, and possibly also the run-time linker search path, to
let guile know where the gnutls module is located.

2) Use --with-guile-site-dir=no during installation.

I have added a new section 'Guile Preparations' to the manual, see
below.  What do you think?

>> If the user builds with --prefix=/usr, the guile paths will be
>> correct.
>
> But `$(GUILE_SITE)' could be anything outside `/usr'.

I think the new section covers this case too.

>> I believe it is more important to not install anything outside of
>> $prefix by default.
>
> Well, we definitely have to make a compromise.  I won't fight strongly
> against having Guile code installed under `$prefix'.  Nevertheless, I
> believe that Guile users will likely be surprised to see that it
> "doesn't work out of the box".

The GnuTLS library itself needs similar "load-path" settings: the
-R/usr/local/lib or LD_LIBRARY_PATH setting for the run-time linker.
You need to install GnuTLS into /usr for the library to just "work out
of the box".  Installing it anywhere else, including the default of
/usr/local, requires that users go through extra steps to have it work.
I think this is a pretty common scenario.

> BTW, Libtool issues a message at installation-time in this sort of
> circumstance:
>
>   ----------------------------------------------------------------------
>   Libraries have been installed in:
>      /usr/local/lib
>
>   If you ever happen to want to link against installed libraries
>   in a given directory, LIBDIR, you must either use libtool, and
>   specify the full pathname of the library, or use the `-LLIBDIR'
>   flag during linking and do at least one of the following:
>      - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
>        during execution
>      - add LIBDIR to the `LD_RUN_PATH' environment variable
>        during linking
>      - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
>      - have your system administrator add LIBDIR to `/etc/ld.so.conf'
>
> Maybe something similar should be done when installing Guile modules?

That could be added, although I'm not sure if anyone ever actually reads
such messages.  Still, having things documented in the manual should
provide information for users.

/Simon

diff --git a/doc/guile.texi b/doc/guile.texi
index 502671b..8d4d075 100644
--- a/doc/guile.texi
+++ b/doc/guile.texi
@@ -14,12 +14,88 @@ a large subset thereof is available.
 
 
 @menu
+* Guile Preparations::          Note on installation and environment.
 * Guile API Conventions::       Naming conventions and other idiosyncrasies.
 * Guile Examples::              Quick start.
 * Guile Reference::             The Scheme GnuTLS programming interface.
 @end menu
 
 @c *********************************************************************
+ at node Guile Preparations
+ at section Guile Preparations
+
+The GnuTLS Guile bindings are by default installed under the GnuTLS
+installation directory (e.g., typically
+ at file{/usr/local/share/guile/site/}).  Normally Guile will not find
+the module there without help.  You may experience something like
+this:
+
+ at example
+$ guile
+guile> (use-modules (gnutls))
+<unnamed port>: no code for module (gnutls)
+guile>
+ at end example
+
+There are two ways to solve this.  The first is to make sure that when
+building GnuTLS, the Guile bindings will be installed in the same
+place where Guile looks.  You may do this by using the
+ at code{--with-guile-site-dir} parameter as follows:
+
+ at example
+$ ./configure --with-guile-site-dir=no
+ at end example
+
+This will instruct GnuTLS to attempt to install the Guile bindings
+where Guile will look for them.  It will use @code{guile-config info
+pkgdatadir} to learn the path to use.
+
+If Guile was installed into @code{/usr}, you may also install GnuTLS
+using the same prefix:
+
+ at example
+$ ./configure --prefix=/usr
+ at end example
+
+If you want to specify the path to install the Guile bindings you can
+also specify the path directly:
+
+ at example
+$ ./configure --with-guile-site-dir=/opt/guile/share/guile/site
+ at end example
+
+The second solution requires some more work but may be easier to use
+if you do not have system administrator rights to your machine.  You
+need to instruct Guile so that it finds the GnuTLS Guile bindings.
+Either use the @code{GUILE_LOAD_PATH} environment variable as follows:
+
+ at example
+$ GUILE_LOAD_PATH=/usr/local/share/guile/site guile
+guile> (use-modules (gnutls))
+guile>
+ at end example
+
+If you get an error regarding @file{libguile-gnutls-v-0} similar to:
+
+ at example
+gnutls.scm:361:1: In procedure dynamic-link in expression (load-extension "libguile-gnutls-v-0" "scm_init_gnutls"):
+gnutls.scm:361:1: file: "libguile-gnutls-v-0", message: "libguile-gnutls-v-0.so: cannot open shared object file: No such file or directory"
+ at end example
+
+You will need to modify the run-time linker path, for example as
+follows.
+
+ at example
+$ LD_LIBRARY_PATH=/usr/local/lib GUILE_LOAD_PATH=/usr/local/share/guile/site guile
+guile> (use-modules (gnutls))
+guile>
+ at end example
+
+As another solution, it may be possible to modify the
+ at code{%load-path} variable.
+
+
+ at c *********************************************************************
 @node Guile API Conventions
 @section Guile API Conventions
 


From ludo at gnu.org  Fri Jun 29 20:49:40 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 29 Jun 2007 20:49:40 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
	<878xa5pud6.fsf@mocca.josefsson.org> <878xa5dttx.fsf@chbouib.org>
	<87k5tmhmej.fsf@mocca.josefsson.org>
Message-ID: <877ipmzjcr.fsf@chbouib.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> Thanks.  I've now built installed guile-1.8.1 locally and was able to
> reproduce the problem.

Thanks, cool.

> I re-read the automake manual on this, and it says:
>
> `maude_LIBADD'

[...]

> `maude_LDADD'

[...]

> This suggests to me that we shouldn't use LDFLAGS at all for any -lguile
> -L/usr/local/lib stuff, and I installed the following patch.

The quoted part of the manual does not mention the `maude_LDFLAGS'
variable.  I was suggesting in <874pldi4l3.fsf at chbouib.org> to use
`_LDFLAGS', not `_LIBADD' nor `_LDADD'.

The manual isn't very verbose about `_LDFLAGS' actually:

  `maude_LDFLAGS'
       This variable is used to pass extra flags to the link step of a
       program or a shared library.

Nevertheless, `$(GUILE_LDFLAGS)' probably logically belongs in
`_LDFLAGS' rather than `_LDADD' or `_LIBADD'.

> Does this work for you?

Yes it does!

But using `_LDFLAGS' might be nicer...  :-)

Thanks!

Ludovic.



From ludo at gnu.org  Fri Jun 29 22:45:45 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 29 Jun 2007 22:45:45 +0200
Subject: [gnutls-dev] Guile related 'make install' failure
References: <87myynrrdw.fsf@mocca.josefsson.org> <87d4zih22h.fsf@chbouib.org>
	<87tzstpwhl.fsf@mocca.josefsson.org> <874pkt6qm7.fsf@chbouib.org>
	<87tzssjej4.fsf@mocca.josefsson.org> <87lke323f2.fsf@chbouib.org>
	<87bqeyhkaw.fsf@mocca.josefsson.org>
Message-ID: <87wsxmwkue.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> They need to read some instructions anyway, the above won't work unless
> the user has also added /usr/local/lib to /etc/ld.so.conf or set
> LD_LIBRARY_PATH to where libguile-gnutls-v-0.so is installed.  Otherwise
> you get error messages such as:

Hmm, right.

> I think the few users that will be affected by this need to read up on
> how to install things for their environment, in particular do one of:
>
> 1) Set %load-path, and possibly also the run-time linker search path, to
> let guile know where the gnutls module is located.
>
> 2) Use --with-guile-site-dir=no during installation.
>
> I have added a new section 'Guile Preparations' to the manual, see
> below.  What do you think?

Perfect, thanks for doing it!

Perhaps we could rather put it in an "Obtaining and Installing GnuTLS"
node (or similar), in between "Preface" and "The Library"?  "Guile
Preparations" would just be a sub-node, and I guess additional material
about GnuTLS-core could go in another sub-node (e.g., the information
under the "Compilation Issues" heading of the `README' file).

BTW, that'd also be an opportunity to mention `bug-gnutls at gnu.org'.

> The GnuTLS library itself needs similar "load-path" settings: the
> -R/usr/local/lib or LD_LIBRARY_PATH setting for the run-time linker.
> You need to install GnuTLS into /usr for the library to just "work out
> of the box".  Installing it anywhere else, including the default of
> /usr/local, requires that users go through extra steps to have it work.
> I think this is a pretty common scenario.

Good point.  From that perspective, `GUILE_LOAD_PATH' is actually no
different from `LD_LIBRARY_PATH'.

> That could be added, although I'm not sure if anyone ever actually reads
> such messages.

Well, yeah.  I for one don't read it, but I thought others did.  ;-)

Thanks,
Ludovic.



From simon at josefsson.org  Fri Jun 29 23:35:22 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 23:35:22 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
In-Reply-To: <877ipmzjcr.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Fri, 29 Jun 2007 20:49:40 +0200")
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
	<878xa5pud6.fsf@mocca.josefsson.org> <878xa5dttx.fsf@chbouib.org>
	<87k5tmhmej.fsf@mocca.josefsson.org> <877ipmzjcr.fsf@chbouib.org>
Message-ID: <87ved6a1gl.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

>> I re-read the automake manual on this, and it says:
>>
>> `maude_LIBADD'
>
> [...]
>
>> `maude_LDADD'
>
> [...]
>
>> This suggests to me that we shouldn't use LDFLAGS at all for any -lguile
>> -L/usr/local/lib stuff, and I installed the following patch.
>
> The quoted part of the manual does not mention the `maude_LDFLAGS'
> variable.  I was suggesting in <874pldi4l3.fsf at chbouib.org> to use
> `_LDFLAGS', not `_LIBADD' nor `_LDADD'.

I read this quoted part

     `_LDADD' and `_LIBADD' are inappropriate for passing
     program-specific linker flags (except for `-l', `-L', `-dlopen'
     and `-dlpreopen').  Use the `_LDFLAGS' variable for this purpose.

to imply that -l and -L flags are suitable to use in _LIBADD, and are
unsuitable for use in _LDFLAGS.  It isn't really clearly expressed
though.

> But using `_LDFLAGS' might be nicer...  :-)

Perhaps this could be clarified in the automake/libtool manual...

/Simon


From ludo at gnu.org  Sat Jun 30 11:33:33 2007
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sat, 30 Jun 2007 11:33:33 +0200
Subject: [gnutls-dev] Guile problems in 1.7.12
References: <878xau1riq.fsf@mocca.josefsson.org>
	<87zm3azgww.fsf@mocca.josefsson.org> <871wgmlj4l.fsf@laas.fr>
	<87wsyexr9a.fsf@chbouib.org> <87r6oi3n86.fsf@mocca.josefsson.org>
	<87d5023m2m.fsf@mocca.josefsson.org>
	<874ple3l2s.fsf@mocca.josefsson.org> <87wsyapgs9.fsf@chbouib.org>
	<87ps42nua2.fsf@mocca.josefsson.org> <87wsyanrvz.fsf@chbouib.org>
	<874pldofkq.fsf@mocca.josefsson.org> <87odjlk2yj.fsf@chbouib.org>
	<87myz58ew6.fsf@mocca.josefsson.org> <874pldi4l3.fsf@chbouib.org>
	<878xa5pud6.fsf@mocca.josefsson.org> <878xa5dttx.fsf@chbouib.org>
	<87k5tmhmej.fsf@mocca.josefsson.org> <877ipmzjcr.fsf@chbouib.org>
	<87ved6a1gl.fsf@mocca.josefsson.org>
Message-ID: <87ejjtwzv6.fsf@chbouib.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I read this quoted part
>
>      `_LDADD' and `_LIBADD' are inappropriate for passing
>      program-specific linker flags (except for `-l', `-L', `-dlopen'
>      and `-dlpreopen').  Use the `_LDFLAGS' variable for this purpose.
>
> to imply that -l and -L flags are suitable to use in _LIBADD, and are
> unsuitable for use in _LDFLAGS.

I'd say that it implies the former, not the latter.  Maybe we should
check that with the Automake folks.

Furthermore, we have `GUILE_LDFLAGS', not `GUILE_LIBADD'.

Thanks,
Ludovic.