Debian Bug report logs - #480041
subversion: Breaks client certificate negotiation

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Oleksandr Moskalenko <malex@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: subversion: Breaks client certificate negotiation

Date: Wed, 07 May 2008 12:39:48 -0600

[Message part 1 (text/plain, inline)]

Package: subversion
Version: 1.4.6dfsg1-4
Severity: important


Current subversion linked against libneon27-gnutls fails to nogotiate a
certificate with an apache2 server when accessing a https/webdav svn
repository.

The bug is still present in the latest subversion and libneon27
libneon27                                 0.28.2-2                    An HTTP and WebDAV client library
libneon27-gnutls                          0.28.2-2                    An HTTP and WebDAV client library (GnuTLS enabled)
libneon27-gnutls-dev                      0.28.2-2                    Header and static library files for libneon27 (GnuTLS enabled)

The server runs:

libapache2-svn                      1.4.2dfsg1-2~bpo.1
libsvn0                             1.4.2dfsg1-2~bpo.1
apache2                             2.0.54-5sarge2

Server admin and I narrowed the problem down to this difference between libneon27-gnutls
and libneon27. Both current svn and cadaver clients are linked against

svn:

ldd /usr/bin/svn | egrep '(tls|ssl|neon)'
        libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0xb79d2000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb792f000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb78ea000)

cadaver:
        libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0xb7e7c000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb7c9c000)

They fail with the following error:

svn: PROPFIND request failed on '/svn/trunk/project'
svn: PROPFIND of '/svn/trunk/project': SSL negotiation failed: SSL alert received: Decrypt error (https://www.example.com.au:4430)

Negotiation fails during TLSv1 negotiation before svn, or dav, are ever
involved on the server side.

server has the "SSLRequireSSL" and "SSLVerifyClient require" directives
enabled in its configuration.

Here is a working svn version:

subversion 1.4.4dfsg1-1

ldd /usr/bin/svn | egrep '(tls|ssl|neon)'
        libneon.so.26 => /usr/lib/libneon.so.26 (0xb79ac000)
        libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb79be000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7979000)

tcpdump traces are attached.

Firefox works with the repository flawlessly after importing the certificate.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (950, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/4 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libgnutls26 depends on:
ii  libc6                  2.7-10            GNU C Library: Shared libraries
ii  libgcrypt11            1.4.1-1           LGPL Crypto library - runtime libr
ii  libgpg-error0          1.4-2             library for common error values an
ii  libopencdk10           0.6.6-1           Open Crypto Development Kit (OpenC
ii  libtasn1-3             1.4-1             Manage ASN.1 structures (runtime)
ii  zlib1g                 1:1.2.3.3.dfsg-12 compression library - runtime

libgnutls26 recommends no packages.

-- no debconf information

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (950, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/4 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages subversion depends on:
ii  libapr1                     1.2.12-2     The Apache Portable Runtime Librar
ii  libc6                       2.7-10       GNU C Library: Shared libraries
ii  libsvn1                     1.4.6dfsg1-4 Shared libraries used by Subversio

subversion recommends no packages.

-- no debconf information

[svn_traces.tar.gz (application/x-gzip, attachment)]

Message #10 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Oleksandr Moskalenko <malex@debian.org>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Thu, 8 May 2008 08:29:25 -0500

[Oleksandr Moskalenko]
> Current subversion linked against libneon27-gnutls fails to nogotiate
> a certificate with an apache2 server when accessing a https/webdav
> svn repository.

Thank you for the detailed bug report.  I have two questions.

- You mention cadaver which also uses libneon27-gnutls, but you don't
  say whether cadaver works against your sarge-backports apache.  I
  infer that it does not, but can you confirm that cadaver is failing
  in what appears to be the same way?

- Can you try libsvn1 1.4.6dfsg1-3 from testing?  (Technically you only
  need libsvn1 from that version; if dpkg complains about strict
  dependencies between subversion and libsvn1 versions, you can use
  dpkg --force-depends.  Or you can install both subversion and libsvn1
  from testing.)

  I ask because 1.4.6dfsg1-3 and 1.4.6dfsg1-4 are almost identical
  except for libneon27 / libneon27-gnutls, whereas the version you
  mention (1.4.4dfsg1-1) still used libneon26.

Thanks,
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Message #15 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: gcs@debian.hu

Cc: 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Thu, 8 May 2008 08:39:24 -0500

Laszlo, can you take a look at bug #480041?  libneon27-gnutls fails to
access a subversion repository hosted on sarge with backports, where
libneon26 worked.  I've asked the reporter to try libneon27 (openssl).

Thanks,
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Message #20 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Dmitry Kurochkin" <dmitry.kurochkin@gmail.com>

To: 480041@bugs.debian.org

Subject: subversion: Breaks client certificate negotiation

Date: Sun, 11 May 2008 13:34:28 +0400

Hi!

Latest subversion/1.4.6dfsg1-4 breaks ssl for me too. But in another way:

> svn update
svn: PROPFIND request failed on '/svn/foobar'
svn: PROPFIND of '/svn/foobar': Could not read status line: SSL error:
Rehandshake was requested by the peer. (https://example.com)

I have downgraded to version 1.4.6dfsg1-3 and it works fine now.

Please let me know if you need additional info.

Regards,
  Dmitry

Message #25 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Simon Morlat <simon.morlat@free.fr>

To: 480041@bugs.debian.org

Subject: subversion: Breaks client certificate negotiation

Date: Tue, 27 May 2008 17:07:48 +0200

Hello,

Breaks for me too, in another different way:

smorlat@poulita: svn update
Domaine d'authentification : https://myproject.csd200a.com:443
Fichier du certificat client : <path to p12 certificate>
Domaine d'authentification : https://myproject.csd200a.com:443
Fichier du certificat client : <path to p12 certificate>
Domaine d'authentification : https://myproject.csd200a.com:443
Fichier du certificat client : <path to p12 certificate>
svn: Échec de la requête PROPFIND sur '/svn/myproject/trunk'
svn: PROPFIND de '/svn/myproject/trunk': SSL negotiation failed: SSL error: 
GnuTLS internal error. (https://myproject.csd200a.com)

In other words, it asks me three times for my .p12 file (while it is already 
given in ~/.subversion/servers config file), and ends with this internal 
error.

Everything was working ok before I upgraded my sid yesterday.

The same p12 certificate still works great with firefox/konqueror.

I already try downgrading openssl and libgnutls*, it has no effect on this 
problem. Downgrading subversion is not possible due to missing db4 build-time 
dependancy.

Thanks for your help.

Message #30 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Simon Morlat <simon.morlat@free.fr>

To: 480041@bugs.debian.org

Subject: subversion: Breaks client certificate negotiation

Date: Fri, 30 May 2008 10:28:46 +0200

Hello,

Here is some more information:

I downgraded subversion and libsvn1 to 1.4.2dfsg1-2 (this is the version 
availaible in debian-stable), and installed libneon26 and libneon26-gnutls 
(required by the 1.4.2dfsg1-2), and everything works well now.
It is probable that the bug is not in subversion but rather in libneon27 or 
libneon27-gnutls.

Simon

Message #35 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: 480041@bugs.debian.org, Oleksandr Moskalenko <malex@debian.org>, Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, Simon Morlat <simon.morlat@free.fr>

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 24 Jun 2008 14:18:44 -0500

Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
see if the SSL client certificate problems remain?  I suspect these are
neon and/or gnutls problems, but Subversion 1.4.x did not officially
support neon 0.28, so 1.5.0 may be better.

Thanks.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Message #40 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Oleksandr Moskalenko <malex@debian.org>, Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, Simon Morlat <simon.morlat@free.fr>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 24 Jun 2008 14:35:43 -0500

[Peter Samuelson]
> Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
> see if the SSL client certificate problems remain?

Also, if you're testing 1.5.0 anyway, could you also test the serf
backend?  In ~/.subversion/servers, in the [global] section:

    http-library = serf

Thanks.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Message #45 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Dmitry Kurochkin" <dmitry.kurochkin@gmail.com>

To: "Peter Samuelson" <peter@p12n.org>

Cc: "Oleksandr Moskalenko" <malex@debian.org>, "Simon Morlat" <simon.morlat@free.fr>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 24 Jun 2008 23:42:40 +0400

Hi.

On Tue, Jun 24, 2008 at 11:35 PM, Peter Samuelson <peter@p12n.org> wrote:
>
> [Peter Samuelson]
>> Could you gentlemen test subversion 1.5.0dfsg1-1 from experimental to
>> see if the SSL client certificate problems remain?
>
> Also, if you're testing 1.5.0 anyway, could you also test the serf
> backend?  In ~/.subversion/servers, in the [global] section:
>
>    http-library = serf

It still fails. But with a new error:

> svn update
svn: OPTIONS of 'https://foo.ru/bar': Could not read status line: SSL
error: Rehandshake was requested by the peer. (https://foo.ru)

Serf backend does not help, same error.

Regards,
  Dmitry

>
> Thanks.
> --
> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
>

Message #50 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Dmitry Kurochkin" <dmitry.kurochkin@gmail.com>

To: "Peter Samuelson" <peter@p12n.org>

Cc: "Oleksandr Moskalenko" <malex@debian.org>, "Simon Morlat" <simon.morlat@free.fr>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 24 Jun 2008 23:53:15 +0400

On Tue, Jun 24, 2008 at 11:42 PM, Dmitry Kurochkin
<dmitry.kurochkin@gmail.com> wrote:
> It still fails. But with a new error:
>
>> svn update
> svn: OPTIONS of 'https://foo.ru/bar': Could not read status line: SSL
> error: Rehandshake was requested by the peer. (https://foo.ru)
>
> Serf backend does not help, same error.

Actually, error with serf backend is not the same:

> svn update
svn: Error running context: Internal error

Regards,
  Dmitry

>
> Regards,
>  Dmitry
>
>>
>> Thanks.
>> --
>> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
>>
>

Message #55 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>

Cc: Oleksandr Moskalenko <malex@debian.org>, Simon Morlat <simon.morlat@free.fr>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 24 Jun 2008 19:42:30 -0500

[Message part 1 (text/plain, inline)]

[Dmitry Kurochkin]
> Actually, error with serf backend is not the same:
> 
> > svn update
> svn: Error running context: Internal error

I hate to ask yet another round-trip of testing, but serf 0.2.0 was
recently uploaded to unstable.  If you are still using serf 0.1.2,
could you upgrade and try again?  The package name is 'libserf-0-0'.
Thanks.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Dmitry Kurochkin" <dmitry.kurochkin@gmail.com>

To: "Peter Samuelson" <peter@p12n.org>

Cc: "Oleksandr Moskalenko" <malex@debian.org>, "Simon Morlat" <simon.morlat@free.fr>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Wed, 25 Jun 2008 12:45:29 +0400

On Wed, Jun 25, 2008 at 4:42 AM, Peter Samuelson <peter@p12n.org> wrote:
>
> [Dmitry Kurochkin]
>> Actually, error with serf backend is not the same:
>>
>> > svn update
>> svn: Error running context: Internal error
>
> I hate to ask yet another round-trip of testing, but serf 0.2.0 was
> recently uploaded to unstable.  If you are still using serf 0.1.2,
> could you upgrade and try again?  The package name is 'libserf-0-0'.
> Thanks.

That error is with libserf-0-0 version 0.2.0-1.

Regards,
  Dmitry

> --
> Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFIYZR2Xk7sIRPQRh0RAmFYAKDbVj46pLH1Was84KjhaA5CBUDkVgCdFMMJ
> Ho0uKPrZkI2XXQ9jNiauON4=
> =cTjK
> -----END PGP SIGNATURE-----
>
>

Message #65 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Seamus Allan" <Seamus.Allan@dynamicratings.com>

To: <480041@bugs.debian.org>

Subject: Bug#480041: subversion: Breaks client certificate negotiation

Date: Thu, 26 Jun 2008 14:49:42 +1000

[Message part 1 (text/plain, inline)]

Hi,  I thought I'd drop a line to say that I am having similar issues

(cf svn: OPTIONS of 'https://foo.ru/bar': Could not read status line:
SSL

error: Rehandshake was requested by the peer. (https://foo.ru) )


I am using an Ubuntu package which has been created from the Intrepid
Subversion 1.5.0 package. 

If I build the Subversion package against libneon26-gnutls or
libneon27-gnutls I get the above error. When I build against the Openssl
libneon26 or 27, I do not get the error. The Ubuntu package does not
build against libserf, but I could give it a go if necessary. 

Like above, the server is running an older version of Subversion, which
is built against libneon (/openssl).

This may or may not provide any help?

Cheers
Seamus

[Message part 2 (text/html, inline)]

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Teodor <mteodor@gmail.com>

To: "Seamus Allan" <Seamus.Allan@dynamicratings.com>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Thu, 26 Jun 2008 11:10:42 +0300

On 6/26/08, Seamus Allan <Seamus.Allan@dynamicratings.com> wrote:
>
>   I am using an Ubuntu package which has been created from the Intrepid Subversion 1.5.0 package.

Can you test using the Debian package (v1.5) from experimental? [1]

Thanks


[1]  http://packages.debian.org/source/experimental/subversion

Message #75 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Seamus Allan <seamus.allan@dynamicratings.com>

To: 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Mon, 30 Jun 2008 08:52:24 +1000

> Can you test using the Debian package (v1.5) from experimental? [1]

Not easily, sorry. I am running Ubuntu Hardy (8.04) and the package for
Debian Experimental requires so many new depends that it breaks my
system (I tried this before the ubuntu package came out).

Technically the Ubuntu package I am using is a backport of the Debian
package, but this shouldn't affect the issue at hand.

Cheers
Seamus

Message #80 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Simon Morlat <simon.morlat@free.fr>

To: Peter Samuelson <peter@p12n.org>

Cc: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, Oleksandr Moskalenko <malex@debian.org>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 1 Jul 2008 15:37:44 +0200

Hi,

Using neon backend, it fails with exactly with the same scenario as before 
(repeatly ask me the ssl certificate path).
Using libserf (0.2.0-1) backend, it fails with this error:
svn: Error running context: Appel système interrompu

"Appel système interrompu"="Interrupted system call"

Simon

Le Wednesday 25 June 2008 02:42:30 Peter Samuelson, vous avez écrit :
> [Dmitry Kurochkin]
>
> > Actually, error with serf backend is not the same:
> > > svn update
> >
> > svn: Error running context: Internal error
>
> I hate to ask yet another round-trip of testing, but serf 0.2.0 was
> recently uploaded to unstable.  If you are still using serf 0.1.2,
> could you upgrade and try again?  The package name is 'libserf-0-0'.
> Thanks.

Message #85 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Oleksandr Moskalenko <malex@debian.org>

To: Debian Bug Tracking System <480041@bugs.debian.org>

Subject: subversion: success when using libserf

Date: Thu, 03 Jul 2008 18:06:24 -0600

Package: subversion
Version: 1.5.0dfsg1-2
Followup-For: Bug #480041


I just tried subversion 1.5.0dfsg1-2 with the serf backend provided by
libserf-0-0 0.2.0-1 via http-library = serf as recommended by Peter and was
able to successfully checkout and commit into a https repository. When not
using serf backend I still get an error:

svn: OPTIONS of 'https://......./branches/Version133x/Scribus': SSL negotiation failed: SSL alert received: Decrypt error (https://............)

Regards,

Alex.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (950, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages subversion depends on:
ii  libapr1                  1.2.12-4        The Apache Portable Runtime Librar
ii  libc6                    2.7-12          GNU C Library: Shared libraries
ii  libsasl2-2               2.1.22.dfsg1-21 Cyrus SASL - authentication abstra
ii  libsvn1                  1.5.0dfsg1-2    Shared libraries used by Subversio

subversion recommends no packages.

-- no debconf information

Message #90 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Seamus Allan <seamus.allan@dynamicratings.com>

To: Oleksandr Moskalenko <malex@debian.org>, 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: success when using libserf

Date: Fri, 04 Jul 2008 10:54:48 +1000

On Thu, 2008-07-03 at 18:06 -0600, Oleksandr Moskalenko wrote:
> I just tried subversion 1.5.0dfsg1-2 with the serf backend provided by
> libserf-0-0 0.2.0-1 via http-library = serf as recommended by Peter and was
> able to successfully checkout and commit into a https repository. When not
> using serf backend I still get an error:

Sorry, it's just not entirely clear in your post - was the connection to
your HTTPS repo using SSL client certificates, or just a standard HTTPS
connection?

Cheers

Seamus

Message #95 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Krystian Bacławski" <krystian.baclawski@gmail.com>

To: 480041@bugs.debian.org

Subject: Bug in libneon-gnutls ?

Date: Sun, 13 Jul 2008 13:19:28 +0200

Hi!

I also had this problem. Most probably bug is present in
libneon-gnutls or gnutls library.

Try my quick-and-nasty fix:
# cd /usr/lib/
# mv libneon-gnutls.so.27 libneon-gnutls.so.27.old
# mv libneon-gnutls.so.27.1.2 libneon-gnutls.so.27.1.2.old
# ln -s libneon.so.27 libneon-gnutls.so.27

-- 
Regards
Krystian Bacławski aka Cahir

Message #100 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Philipp Marek <philipp@marek.priv.at>

To: 480041@bugs.debian.org

Subject: Still happens with neon

Date: Wed, 6 Aug 2008 10:26:42 +0200

I'm running with the current experimental versions:

ii  libneon27-gnutls                     0.28.2-3    
ii  libgnutls26                          2.4.1-1      
ii  libneon27-gnutls                     0.28.2-3

but that still doesn't work.

I'm trying to access a https URL that requires a client certificate,
but (according to strace) it is never read; and if read the neon 
debug messages correctly, this is the cause for the re-handshake.

I have my ~/.subversion/servers file configured for this host, so
that the client certificate should be used.


  $ svn ls https://<URL>
  ah_create, for WWW-Authenticate
  Running pre_send hooks
  compress: Initialization.
  Sending request headers:
  OPTIONS <PATH> HTTP/1.1
  Host: <SERVER>
  User-Agent: SVN/1.5.1 (r32289) neon/0.28.2
  Keep-Alive:
  Connection: TE, Keep-Alive
  TE: trailers
  DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
  DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
  DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
  Accept-Encoding: gzip

  Sending request-line and headers:
  Doing DNS lookup on <SERVER>...
  Connecting to <IP>
  Request sent; retry is 0.
  Aborted request (-1): Could not read status line
  sess: Closing connection.
  sess: Connection closed.
  Request ends, status 0 class 0xx, error line:
  Could not read status line: SSL error: Rehandshake was requested by the peer.
  Running destroy hooks.
  Request ends.
  svn: OPTIONS von »<URL>«: Could not read status line: SSL error: Rehandshake was requested by the peer. (<URL>)
  sess: Destroying session.
  sess: Destroying session.


The hack of Krystian Bacławski works, though.

Message #105 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dominique.dumont@hp.com>

To: 480041@bugs.debian.org

Subject: Seems like the bug is gone

Date: Fri, 29 Aug 2008 15:18:08 +0200

Hello

I've just re-tried this morning and I was able to connect with the SVN
server with authentication.

I don't think this is due to new gnutls version. Here's what I have on
my machine:

ii  gnutls-bin                 2.4.1-1     
ii  libgnutls26                2.4.1-1     
ii  libneon26-gnutls           0.26.4-2+b1 
ii  libneon27-gnutls           0.28.2-4    
ii  libneon27-gnutls-dev       0.28.2-4    

In fact, I had to change the certificate file (the old one had
expired). With the new file (with extension .pfx and no longer .p12),
the authenfication is working again.

HTH

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

Message #110 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Flink, Timothy" <flink@hp.com>

To: "480041@bugs.debian.org" <480041@bugs.debian.org>

Subject: Still happening for me

Date: Fri, 29 Aug 2008 16:02:45 +0000

I updated libneon27 and libneon27-gnutls from sid this morning and tried connecting to a SVN server with authentication. However, I'm still seeing the same errors:


flink@flink2:~/code$ svn co https://secure-svn-server.com/svn/blah
Authentication realm: https://secure-svn-server.com:443
Client certificate filename: <path to .p12 key>
Authentication realm: https://secure-svn-server.com:443
Client certificate filename: <path to .p12 key>
Authentication realm: https://secure-svn-server.com:443
Client certificate filename: <path to .p12 key>
svn: OPTIONS of 'https://secure-svn-server.com/svn/blah': SSL negotiation failed: SSL error: GnuTLS internal error. (https://secure-svn-server.com)
flink@flink2:~/code$

svn update is the same.

Here is what I have installed on my system:

ii  subversion                1.5.1dfsg1-1
ii  gnutls-bin                2.4.1-1
ii  libgnutls-dev             2.4.1-1
ii  libgnutls26               2.4.1-1
ii  libneon27                 0.28.2-5
ii  libneon27-gnutls          0.28.2-5
ii  libneon27-gnutls-dev      0.28.2-5
ii  libneon26                 0.26.4-2+b1
ii  libneon26-gnutls          0.26.4-2+b1

Thanks,

Tim Flink

Message #115 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Flink, Timothy" <flink@hp.com>

To: "480041@bugs.debian.org" <480041@bugs.debian.org>

Subject: re: Still happening for me

Date: Fri, 29 Aug 2008 16:07:26 +0000

I'm sorry for the extra email, but I forgot to add that the fix/hack posted by Krystian Bacławski works for me both before and after upgrading packages.

Thanks,

Tim Flink

Message #120 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Dominique Dumont <dominique.dumont@hp.com>

To: "Flink\, Timothy" <flink@hp.com>

Cc: <480041@bugs.debian.org>

Subject: Re: Bug#480041: Still happening for me

Date: Fri, 29 Aug 2008 18:17:12 +0200

"Flink, Timothy" <flink@hp.com> writes:

> flink@flink2:~/code$ svn co https://secure-svn-server.com/svn/blah
> Authentication realm: https://secure-svn-server.com:443
> Client certificate filename: <path to .p12 key>

Re-export your certificate (possibly from IE as I did) so as to get a
.pfx file (and not a .p12 file), change subversion's server config to
point to the new file and retry.

It's now working for me.

HTH

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

Message #125 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Flink, Timothy" <flink@hp.com>

To: "Dumont, Dominique" <dominique.dumont@hp.com>

Cc: "480041@bugs.debian.org" <480041@bugs.debian.org>

Subject: RE: Bug#480041: Still happening for me

Date: Fri, 29 Aug 2008 17:23:16 +0000

Exporting my certificate as .pfx from IE7 worked and I am now able to use svn without Krystian Bacławski's workaround.

Isn't this just another workaround for the original issue, though? While recent implementations of PFX conform to the PKCS#12 spec, aren't they still different than the .p12 keys exported from a Mozilla product (or others)? I know that my .p12 key and the .pfx key files are not the same size even though they are equivalent (I had to import the old .p12 key into IE before I could export it as a .pfx).

Thanks,

Tim Flink

-----Original Message-----
From: Dumont, Dominique
Sent: Friday, August 29, 2008 10:17 AM
To: Flink, Timothy
Cc: 480041@bugs.debian.org
Subject: Re: Bug#480041: Still happening for me

"Flink, Timothy" <flink@hp.com> writes:

> flink@flink2:~/code$ svn co https://secure-svn-server.com/svn/blah
> Authentication realm: https://secure-svn-server.com:443
> Client certificate filename: <path to .p12 key>

Re-export your certificate (possibly from IE as I did) so as to get a
.pfx file (and not a .p12 file), change subversion's server config to
point to the new file and retry.

It's now working for me.

HTH

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

Message #130 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Wright <p.wright@eoveri.com>

To: 480041@bugs.debian.org

Subject: problem narrowed down

Date: Mon, 29 Sep 2008 17:00:04 +0100

I've found a solution that works with libneon27-gnutls. The problem
appears to be that it does not correctly handle having the CA
certificates in the .p12

To extract the PEMs from your current p12:
  openssl pkcs12 -in CURRENT.p12 -nodes -nocerts > private.key.pem
  openssl pkcs12 -in CURRENT.p12 -nodes -nokeys > public.key.pem

Then in public.key.pem I deleted all which weren't my certificate, then
I repackaged it with:
  openssl pkcs12  -export -inkey private.key.pem -in public.key.pem -out
NEW.p12

So it seems the problem is in either with the input that's being passed
to gnutls or with gnutls itself.

Message #135 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Nebojša Ćosić <nebojsa@asnn.org>

To: 480041@bugs.debian.org

Subject: Re: Bug#480041: subversion: Breaks client certificate negotiation

Date: Tue, 14 Oct 2008 00:33:55 +0200

It is definitely gnutls.
I tried to access same https/webdav url using curl (compiled with
gnutls) and had same problems. After recompiling without gnutls
everything worked just fine.
It is not necessarily error in gnutls - it may be just that interface
is different to that used by openssl.
It looks like openssl is handling renegotitaion (rehandshake)
automagically, while when using gnutls one has to initiate process.
On my gentoo machine I am using following:
curl-7.18.2
gnutls-2.2.5, gnutls-2.5.4
neon-0.28.3
subversion-1.5.2
It may be if one set apache to demand certificate for all urls (and
thus avoid renegotiation) that problem would disappear.
-- 

Nebojša

Message #140 received at 480041@bugs.debian.org (full text, mbox, reply):

From: dann frazier <dannf@debian.org>

To: 480041@bugs.debian.org

Subject: similar fedora bug

Date: Mon, 27 Oct 2008 14:12:39 -0600

https://bugzilla.redhat.com/show_bug.cgi?id=445044

-- 
dann frazier

Message #145 received at 480041@bugs.debian.org (full text, mbox, reply):

From: dann frazier <dannf@debian.org>

To: 480041@bugs.debian.org

Subject: gnutls bug

Date: Tue, 28 Oct 2008 10:51:06 -0600

fyi, I've file this bug against gnutls:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833

As explained there, I opened a new bug instead of reassigning this one
because this bug represents a subversion regression which could
theoretically be fixed w/o a fix for #503833 (e.g., by going back to
not using gnutls).

-- 
dann frazier

Message #150 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: 480041@bugs.debian.org, neon@lists.manyfish.co.uk

Subject: PKCS#12 certs with embedded CA certs and GnuTLS

Date: Thu, 30 Oct 2008 19:08:41 +0000

This issue (Debian bug 480041) is almost certainly a neon bug.

I can reproduce the error with a PKCS#12 cert with an embedded CA cert; 
if anybody else seeing this problem can confirm it's fixed with the 
patch below, that would be great.

Regards, Joe

Index: src/ne_gnutls.c
===================================================================
--- src/ne_gnutls.c	(revision 1588)
+++ src/ne_gnutls.c	(working copy)
@@ -974,6 +974,10 @@
             switch (type) {
             case GNUTLS_BAG_PKCS8_KEY:
             case GNUTLS_BAG_PKCS8_ENCRYPTED_KEY:
+                /* Ignore any but the first key encountered; really
+                 * need to match up keyids. */
+                if (*pkey) break;
+
                 gnutls_x509_privkey_init(pkey);
 
                 ret = gnutls_pkcs12_bag_get_data(bag, j, &data);
@@ -986,6 +990,10 @@
                 if (ret < 0) continue;
                 break;
             case GNUTLS_BAG_CERTIFICATE:
+                /* Ignore any but the first cert encountered; again,
+                 * really need to match up keyids. */
+                if (*x5) break;
+
                 gnutls_x509_crt_init(x5);
 
                 ret = gnutls_pkcs12_bag_get_data(bag, j, &data);

Message #155 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: 480041@bugs.debian.org, neon@lists.manyfish.co.uk

Subject: Re: PKCS#12 certs with embedded CA certs and GnuTLS

Date: Thu, 30 Oct 2008 19:24:22 +0000

On Thu, Oct 30, 2008 at 07:08:41PM +0000, Joe Orton wrote:
> This issue (Debian bug 480041) is almost certainly a neon bug.
> 
> I can reproduce the error with a PKCS#12 cert with an embedded CA cert; 
> if anybody else seeing this problem can confirm it's fixed with the 
> patch below, that would be great.

Since there are a variety of different symptoms reported in Debian bug 
480041, I'd like to clarify that the neon patch I've posted here should 
fix the case where SVN fails with the message:

  "SSL negotiation failed: SSL alert received: Decrypt error"

This is distinct from the case where GnuTLS fails to parse particular 
PKCS#12 files, which Dann has reported as:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833

which had been independently reported upstream here:

http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3182

Regards, Joe

Message #162 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: confirming debian #480041: subversion with libneon-gnutls fails if apache's SSLVerifyClient optional is set

Date: Thu, 20 Nov 2008 18:01:57 -0500

[Message part 1 (text/plain, inline)]

I just wanted to confirm this problem:

I'm using the current debian testing (on both client and server),
subversion against an https repository hosted by apache with mod_ssl
and mod_svn.  The client in these scenarios *does not* have an X.509
certificate at all, but uses username/password authentication instead.

If i set up the apache mod_svn authentication like this:

   AuthType Basic
   AuthName "foo"
   AuthUserFile /srv/etc/htpasswd

   Require valid-user

Then a simple svn co works (i get prompted for a username/password if
none is cached, or it just connects if the authentication credentials
are already cached).

However, if i switch the authentication to:

   AuthType Basic
   AuthName "foo"
   AuthUserFile /srv/etc/htpasswd

   SSLVerifyClient optional
   SSLVerifyDepth 1
   SSLUserName SSL_CLIENT_S_DN_CN 

   Require valid-user

Then a checkout fails with:

[0 dkg@squeak ~]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla': Could not read status line: SSL error: Rehandshake was requested by the peer. (https://foo.example.org)
[1 dkg@squeak ~]$ 

On the client side:

[0 dkg@squeak ~]$ dpkg -l libsvn1 libneon27-gnutls libgnutls26 subversion libtasn1-3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libgnutls26    2.6.2-1        the GNU TLS library - runtime library
ii  libneon27-gnut 0.28.2-5       An HTTP and WebDAV client library (GnuTLS en
ii  libsvn1        1.5.1dfsg1-1   Shared libraries used by Subversion
ii  libtasn1-3     1.4-1          Manage ASN.1 structures (runtime)
ii  subversion     1.5.1dfsg1-1   Advanced version control system
[0 dkg@squeak ~]$ 

on the server side:

foo:/# dpkg -l apache2-mpm-worker libapache2-svn libssl0.9.8
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apache2-mpm-wo 2.2.9-10       Apache HTTP Server - high speed threaded mod
ii  libapache2-svn 1.5.1dfsg1-1   Subversion server modules for Apache
ii  libssl0.9.8    0.9.8g-14      SSL shared libraries
foo:/# 

If i leave the server configured with SSLVerifyClient optional, i can
make svn work by doing the following as the superuser (thanks to
Krystian Bacławski for the suggestion):

 cd /usr/lib
 rm libneon-gnutls.so.27
 ln -s libneon.so.27 libneon-gnutls.so.27

In that case, svn (indirectly hooked via libneon into OpenSSL instead
of gnutls) prompts me for a choice of certificate about 6 times, and
then goes ahead and authenticates me via username/password.

So this is clearly either a problem with libneon-gnutls, or with
gnutls itself.

I see the same problem whether i'm using libgnutls26 2.4.2-3 (from
lenny) or 2.6.2-1 (from experimental).

       --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #167 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Thu, 20 Nov 2008 19:02:30 -0500

[Message part 1 (text/plain, inline)]

OK, i'm now sure that debian #480041 is a gnutls problem, and not just
due to something wacky in libneon (though there may be libneon bits as
well).  Here's a way to duplicate the problem without using libneon.

Add the following line to /etc/hosts:

127.0.0.1 fubar.example.org

Generate an X.509 self-signed key/cert pair (or use an existing
key/cert pair -- it doesn't have to be self-signed):

  mkdir /tmp/testing && cd /tmp/testing
  openssl req -newkey rsa:1024 -keyout key.pem -nodes -subj '/CN=fubar.example.org' -x509 > cert.pem

Configure an apache2 virtualhost like this:

--------------------------------
<VirtualHost 127.0.0.1:443>
ServerName fubar.example.org
DocumentRoot /var/www/

SSLEngine on
SSLCertificateFile /tmp/testing/cert.pem
SSLCertificateKeyFile /tmp/testing/key.pem
SSLCACertificateFile /tmp/testing/cert.pem

<Location "/">
 SSLVerifyClient optional
</Location>

</VirtualHost>
--------------------------------

Then run the following command to simulate a web connection:

HTTP_QUERY='GET / http/1.1\r\nHost: fubar.example.org\r\n\r\n'
(sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | gnutls-cli fubar.example.org

The tail of the output looks like this for me:

---------------------------------
  ...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

*** Non fatal error: Rehandshake was requested by the peer.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Server has terminated the connection abnormally.
---------------------------------

The apache2 error log looks like:

[Thu Nov 20 18:55:30 2008] [error] Re-negotiation handshake failed: Not accepted by client!?

Interestingly, if i don't wrap the "SSLVerifyClient optional" line in
the <Location /> tag, the connection goes through cleanly.  I think
this means that the problem appears when the handshake is
re-negotiated after some traffic has already been sent.

Hope this is helpful in debugging the problem.

     --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #172 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Nikos Mavrogiannopoulos <nmav@gnutls.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 09:24:02 +0200

Daniel Kahn Gillmor wrote:
> OK, i'm now sure that debian #480041 is a gnutls problem, and not just
> due to something wacky in libneon (though there may be libneon bits as
> well).  Here's a way to duplicate the problem without using libneon.
[...]
> - Simple Client Mode:
> 
> *** Non fatal error: Rehandshake was requested by the peer.
> *** Fatal error: A TLS fatal alert has been received.
> *** Received alert [10]: Unexpected message
> *** Server has terminated the connection abnormally.
> ---------------------------------

Hello, this does not seem to be a gnutls error. The server merely asks
for renegotiation, gnutls-cli ignores it (legal behavior) and server
does not like it thus sends a fatal alert. However which version of
gnutls-cli is that? Can you try with the latest?

For neon to solve this, it has to perform a handshake after the
rehandshake request has been required.

regards,
Nikos

Message #177 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, GnuTLS development list <gnutls-devel@gnu.org>, 480041@bugs.debian.org

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 08:29:44 +0000

On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote:
> For neon to solve this, it has to perform a handshake after the
> rehandshake request has been required.

Ah, I didn't realise that - OpenSSL will automatically rehandshake 
whenever requested by the server.  So to provide the equivalent 
behaviour with GnuTLS, I have to do something like:

start:
   ret = gnutls_record_send(blah);
   if (ret == GNUTLS_E_REHANDSHAKE) {
       gnutls_handshake(blah);
       goto start;
   }

and similarly with calls to record_recv?

Regards, Joe

Message #182 received at 480041@bugs.debian.org (full text, mbox, reply):

From: "Nikos Mavrogiannopoulos" <nmav@gnutls.org>

To: "Joe Orton" <joe@manyfish.co.uk>

Cc: "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>, "GnuTLS development list" <gnutls-devel@gnu.org>, 480041@bugs.debian.org

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 15:03:49 +0200

Actually you only need to do this test on record_recv(). Note that
usually servers request upgrade in order to receive a client
certificate, thus it might be a good idea to notify or prompt the user
about that.

regards,
Nikos

On Fri, Nov 21, 2008 at 10:29 AM, Joe Orton <joe@manyfish.co.uk> wrote:
> On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote:
>> For neon to solve this, it has to perform a handshake after the
>> rehandshake request has been required.
>
> Ah, I didn't realise that - OpenSSL will automatically rehandshake
> whenever requested by the server.  So to provide the equivalent
> behaviour with GnuTLS, I have to do something like:
>
> start:
>   ret = gnutls_record_send(blah);
>   if (ret == GNUTLS_E_REHANDSHAKE) {
>       gnutls_handshake(blah);
>       goto start;
>   }
>
> and similarly with calls to record_recv?
>
> Regards, Joe
>

Message #187 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, GnuTLS development list <gnutls-devel@gnu.org>, 480041@bugs.debian.org

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 13:20:40 +0000

On Fri, Nov 21, 2008 at 03:03:49PM +0200, Nikos Mavrogiannopoulos wrote:
> Actually you only need to do this test on record_recv().

OK.

> Note that usually servers request upgrade in order to receive a client 
> certificate, thus it might be a good idea to notify or prompt the user 
> about that.

neon already has a callback which does that, yeah.

Daniel, can you try this neon patch?

Index: src/ne_socket.c
===================================================================
--- src/ne_socket.c	(revision 1607)
+++ src/ne_socket.c	(working copy)
@@ -750,13 +750,15 @@
 static ssize_t read_gnutls(ne_socket *sock, char *buffer, size_t len)
 {
     ssize_t ret;
+    int reneg = 1; /* number of rehandshakes allowed */
 
     ret = readable_gnutls(sock, sock->rdtimeout);
     if (ret) return ret;
     
     do {
         ret = gnutls_record_recv(sock->ssl, buffer, len);
-    } while (RETRY_GNUTLS(sock, ret));
+    } while (RETRY_GNUTLS(sock, ret) 
+             || (ret == GNUTLS_E_REHANDSHAKE && reneg-- > 0));
 
     if (ret <= 0)
 	ret = error_gnutls(sock, ret);

Message #192 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 11:54:00 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:

> Hello, this does not seem to be a gnutls error. The server merely asks
> for renegotiation, gnutls-cli ignores it (legal behavior) and server
> does not like it thus sends a fatal alert. However which version of
> gnutls-cli is that? Can you try with the latest?

That was originally tested against debian's 2.4.2-3.  With 2.6.2-1
(from debian experimental), i get the same output:

 ...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

*** Non fatal error: Rehandshake was requested by the peer.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Server has terminated the connection abnormally.

    --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #197 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 11:58:36 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:

> Hello, this does not seem to be a gnutls error. The server merely asks
> for renegotiation, gnutls-cli ignores it (legal behavior) and server
> does not like it thus sends a fatal alert.

Do you think this is exposing a bug in mod_ssl, then?  If it is legal
behavior to ignore a renegotiation, it seems to me that
SSLVerifyClient optional should not cause the server to terminate the
connection if a rehandshake is rejected.  Should we clone this bug, or
open a new report against apache or openssl?

     --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #202 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Joe Orton <joe@manyfish.co.uk>

Cc: 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 12:31:14 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:

> neon already has a callback which does that, yeah.
>
> Daniel, can you try this neon patch?

neon27 FTBFS for me right now (i opened http://bugs.debian.org/506464
to try to figure that out) so it'll probably take me a little while to
try out the patch.  But thanks for offering it, Joe.  If i can get
neon to build properly, i'll give it a shot.

Regards,

         --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #207 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Nikos Mavrogiannopoulos <nmav@gnutls.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 20:54:37 +0200

Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
>> Hello, this does not seem to be a gnutls error. The server merely asks
>> for renegotiation, gnutls-cli ignores it (legal behavior) and server
>> does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

Could you first send me a capture to be used with wireshark so i can
check precisely what is happening there (gnutls-cli) and rule out any
gnutls issue?

regards,
Nikos

Message #212 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 14:18:14 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 13:54:37 -0500, Nikos Mavrogiannopoulos wrote:

> Could you first send me a capture to be used with wireshark so i can
> check precisely what is happening there (gnutls-cli) and rule out any
> gnutls issue?

Attached is a pcap file, and the test key and certificate used by the
server during the communication.  The client had no certificate.

wireshark tells me that the TCP checksums of most packets in the
packet capture are wrong; i don't know why that is, nor do i think
it's particularly relevant, given that this was all done across the
loopback interface.

This packet capture was done with gnutls-cli 2.6.2-1 and with
libgnutls26 from the same version.

Hope this is helpful,

        --dkg

[480041.pcap (application/cap, attachment)]

[key.pem (text/plain, attachment)]

[cert.pem (text/plain, attachment)]

[Message part 5 (application/pgp-signature, inline)]

Message #217 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 14:34:41 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 14:18:14 -0500, Daniel Kahn Gillmor wrote:

> Attached is a pcap file, and the test key and certificate used by the
> server during the communication.  The client had no certificate.

And here, i've attached a pcap of the connection using openssl, which
actually returns some HTTP output and terminates cleanly.  The openssl
invocation was:

  (sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | \
   openssl s_client -connect fubar.example.org:443

as compared to the gnutls-cli invocation of:

  (sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | \
   gnutls-cli fubar.example.org

hope this is useful,

     --dkg

[480041.openssl.pcap (application/cap, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #222 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>, 480041@bugs.debian.org

Subject: Re: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 21:59:21 +0000

On Fri, Nov 21, 2008 at 11:58:36AM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
> > Hello, this does not seem to be a gnutls error. The server merely asks
> > for renegotiation, gnutls-cli ignores it (legal behavior) and server
> > does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

IIUC what will happen in this case is that mod_ssl puts OpenSSL into the 
state where it expects a full handshake - if it receives any app_data 
packets OpenSSL treats thas a hard failure.  And slso IIUC - this 
results in the server sending a ChangeCipherSpec message on the wire - 
and the client has no option to ignore that in TLS, right?

joe

Message #227 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, neon@lists.manyfish.co.uk

Cc: 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 21 Nov 2008 22:02:14 +0000

On Fri, Nov 21, 2008 at 12:31:14PM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:
> 
> > neon already has a callback which does that, yeah.
> >
> > Daniel, can you try this neon patch?
> 
> neon27 FTBFS for me right now (i opened http://bugs.debian.org/506464
> to try to figure that out) so it'll probably take me a little while to
> try out the patch.  But thanks for offering it, Joe.  If i can get
> neon to build properly, i'll give it a shot.

Could require this patch to neon's Makefile.in, which I just checked in:

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 1616)
+++ Makefile.in	(working copy)
@@ -119,10 +119,10 @@
 
 again: clean
 
-Makefile: Makefile.in
+Makefile: $(srcdir)/Makefile.in
 	@./config.status Makefile
 
-neon-config: neon-config.in
+neon-config: $(srcdir)/neon-config.in
 	@./config.status neon-config
 
 install-docs: install-man install-html

Message #232 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Joe Orton <joe@manyfish.co.uk>

Cc: 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sat, 22 Nov 2008 00:51:05 -0500

[Message part 1 (text/plain, inline)]

On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:

> neon already has a callback which does that, yeah.
>
> Daniel, can you try this neon patch?

OK, after figuring out how to build neon27 (don't try it in a path
that contains the string "libneon" in it), i tried applying the patch.

With tour patch, svn co just runs forever against an svn server
configured with SSLVerifyClient optional, and never fetches anything.

What additional bits of debugging would you like?

           --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #237 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, neon@lists.manyfish.co.uk

Cc: 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sat, 22 Nov 2008 08:05:03 +0000

On Sat, Nov 22, 2008 at 12:51:05AM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:
> 
> > neon already has a callback which does that, yeah.
> >
> > Daniel, can you try this neon patch?
> 
> OK, after figuring out how to build neon27 (don't try it in a path
> that contains the string "libneon" in it), i tried applying the patch.

I guess that's a problem with the Debian package build process?

> With tour patch, svn co just runs forever against an svn server
> configured with SSLVerifyClient optional, and never fetches anything.

Err, reading that patch again, it's complete rubbish.  Could you try the 
one below which is hopefully less rubbish?  Thanks a lot for working on 
this!

Index: src/ne_socket.c
===================================================================
--- src/ne_socket.c	(revision 1607)
+++ src/ne_socket.c	(working copy)
@@ -750,13 +750,18 @@
 static ssize_t read_gnutls(ne_socket *sock, char *buffer, size_t len)
 {
     ssize_t ret;
+    unsigned reneg = 1; /* number of allowed rehandshakes */
 
     ret = readable_gnutls(sock, sock->rdtimeout);
     if (ret) return ret;
     
     do {
-        ret = gnutls_record_recv(sock->ssl, buffer, len);
-    } while (RETRY_GNUTLS(sock, ret));
+        do {
+            ret = gnutls_record_recv(sock->ssl, buffer, len);
+        } while (RETRY_GNUTLS(sock, ret));
+        
+    } while (ret == GNUTLS_E_REHANDSHAKE && reneg--
+             && (ret = gnutls_handshake(sock->ssl)) == GNUTLS_E_SUCCESS);
 
     if (ret <= 0)
 	ret = error_gnutls(sock, ret);

Message #242 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: neon@lists.manyfish.co.uk, 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sat, 22 Nov 2008 13:54:43 -0500

[Message part 1 (text/plain, inline)]

On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:

> Err, reading that patch again, it's complete rubbish.  

I thought it looked a little sparse, actually, but i've never really
poked around inside libneon before.  Thanks for the updated patch.

> Could you try the one below which is hopefully less rubbish?  Thanks
> a lot for working on this!

This does something different now:

[0 dkg@squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: Could not read status line: SSL error: Decryption has failed. (https://foo.example.org)
[1 dkg@squeak cdtemp.oNUHIC]$ 

But it's still not just going ahead with the checkout the way it does
when i use the openssl version of libneon.  Can i give you more
detailed debugging info somehow?

    --dkg

[Message part 2 (application/pgp-signature, inline)]

Message #247 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: neon@lists.manyfish.co.uk, 480041@bugs.debian.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sat, 22 Nov 2008 22:13:00 +0000

On Sat, Nov 22, 2008 at 01:54:43PM -0500, Daniel Kahn Gillmor wrote:
> On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:
> [0 dkg@squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
> svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: 
> Could not read status line: SSL error: Decryption has failed. 
> (https://foo.example.org)
> [1 dkg@squeak cdtemp.oNUHIC]$ 
> 
> But it's still not just going ahead with the checkout the way it does
> when i use the openssl version of libneon.  Can i give you more
> detailed debugging info somehow?

Interesting, thanks for trying that out.  I'm not sure what else neon 
could do to make this work correctly so I think further diagnosis based 
on packet traces will be needed.  I can try to work on that sometime in 
the coming week, with luck.

It might be useful to modify gnutls-cli to call gnutls_rehandshake() in 
the same fashion as my patch to neon, to get some debugging traces from 
GnuTLS, if you wanted to try that.

Regards, Joe

Message #252 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Nikos Mavrogiannopoulos <nmav@gnutls.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, neon@lists.manyfish.co.uk, 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sun, 23 Nov 2008 10:02:10 +0200

Joe Orton wrote:
> On Sat, Nov 22, 2008 at 01:54:43PM -0500, Daniel Kahn Gillmor wrote:
>> On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:
>> [0 dkg@squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
>> svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: 
>> Could not read status line: SSL error: Decryption has failed. 
>> (https://foo.example.org)
>> [1 dkg@squeak cdtemp.oNUHIC]$ 
>>
>> But it's still not just going ahead with the checkout the way it does
>> when i use the openssl version of libneon.  Can i give you more
>> detailed debugging info somehow?
> 
> Interesting, thanks for trying that out.  I'm not sure what else neon 
> could do to make this work correctly so I think further diagnosis based 
> on packet traces will be needed.  I can try to work on that sometime in 
> the coming week, with luck.
> It might be useful to modify gnutls-cli to call gnutls_rehandshake() in 
> the same fashion as my patch to neon, to get some debugging traces from 
> GnuTLS, if you wanted to try that.

The git version of gnutls-cli (both in main and 2.6 branches) support
this behavior.

regards,
Nikos

Message #257 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Joe Orton <joe@manyfish.co.uk>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, neon@lists.manyfish.co.uk, 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Fri, 28 Nov 2008 14:47:22 +0000

[Message part 1 (text/plain, inline)]

I've tried this using a git build of GnuTLS, gnutls-cli and a test 
httpd/mod_ssl server configured for per-location client cert auth (i.e. 
it requests a second handshake after the GET request is recevied), and 
it does fail, so I think this is indeed a GnuTLS bug in the handling of 
rehandshakes.

Attached:

1) gnutls-cli log output from testing using httpd/mod_ssl
2) patch to tests/x509self.c which attempts to replicate this test case
3) stdout and stderr output from running (2)

[log (text/plain, attachment)]

[diff (text/plain, attachment)]

[x.out (text/plain, attachment)]

[x.err (text/plain, attachment)]

Message #262 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Nikos Mavrogiannopoulos <nmav@gnutls.org>

To: Nikos Mavrogiannopoulos <nmav@gnutls.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, neon@lists.manyfish.co.uk, 480041@bugs.debian.org, GnuTLS development list <gnutls-devel@gnu.org>

Subject: Re: Bug#480041: confirmation that debian #480041 is a gnutls problem, and steps to reproduce

Date: Sat, 29 Nov 2008 10:02:35 +0200

Joe Orton wrote:
> I've tried this using a git build of GnuTLS, gnutls-cli and a test 
> httpd/mod_ssl server configured for per-location client cert auth (i.e. 
> it requests a second handshake after the GET request is recevied), and 
> it does fail, so I think this is indeed a GnuTLS bug in the handling of 
> rehandshakes.

Hello Joe,
 I the test case was not correct. The call (from server) to
gnutls_rehandshake will only notify the client about a rehandshake.
After that a call to gnutls_handshake is required. Once I do this the
test case works correctly (i've also committed it).

To debug (1 - gnutls-cli log output from testing using httpd/mod_ssl)
you might need some output from mod_ssl as well. There the server
notifies the client about a rehandshake, the client starts the handshake
by sending client hello and the server replies with an alert.

regards,
Nikos

Message #267 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Craig Ringer <craig@postnewspapers.com.au>

To: 480041@bugs.debian.org

Subject: Ubuntu tracker URL

Date: Wed, 14 Jan 2009 13:29:23 +0900

Hi

There's a tracker entry in Ubuntu's launchpad for this issue as well. See:

https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648

I've posted instructions on rebuilding the package against the
openssl-based version of libneon for anyone stumbling across this bug
who's just trying to get svn working.

--
Craig Ringer

Message #280 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: friedel@nomaden.org, 480041@bugs.debian.org, 530510@bugs.debian.org

Subject: 480041 and 530510

Date: Mon, 30 Nov 2009 15:44:27 +0100

Can you explain how these bug reports suggests there is a bug in the
GnuTLS packages?

To me, 480041 looks like a fairly common administrator problem.  530510
looks like it contains all sorts of problems, many of them were reported
solved.  I cannot find any succinct problem description describing a
GnuTLS issue, but due to the length of the bug I didn't read it all.

If you want us to fix this, we need a better description of the actual
problem.

I suspect some of the problem may have been triggered by the recent
OpenSSL security advisory that disables TLS renegotiation, which is
often used with client certificates.

/Simon

Message #285 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Friedrich Delgado Friedrichs <friedel@nomaden.org>

To: Simon Josefsson <simon@josefsson.org>

Cc: 480041@bugs.debian.org, 530510@bugs.debian.org

Subject: Re: 480041 and 530510

Date: Mon, 30 Nov 2009 22:07:44 +0100

unmerge 530510 480041
reassign 480041 subversion
found 480041 1.6.6dfsg-1
found 480041 1.4.6dfsg1-4
found 480041 1.5.0dfsg1-2
found 480041 1.6.6dfsg-1
thank you

Hi!

Sorry, I didn't read bug 480041 carefully enough, it's actually
different from 530510.

I hope I've managed to clean up the mess I've made.


-- 
        Friedrich Delgado Friedrichs <friedel@nomaden.org>
                             TauPan on Ircnet and Freenode ;)

Message #300 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Bryan Cain <plombex342@gmail.com>

To: 480041@bugs.debian.org

Subject: Fix for bug #480041

Date: Sun, 10 Oct 2010 21:07:15 -0500

[Message part 1 (text/plain, inline)]

I've uploaded a patch for this bug to
https://bugs.launchpad.net/ubuntu/+source/neon27/+bug/294648
<https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648>.  Joe
Orton has already committed the fix upstream in libneon.

Bryan Cain

[Message part 2 (text/html, inline)]

Message #309 received at 480041@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Bryan Cain <plombex342@gmail.com>, 480041@bugs.debian.org

Subject: Re: Bug#480041: Fix for bug #480041

Date: Mon, 11 Oct 2010 12:24:38 -0500

[Message part 1 (text/plain, inline)]

tags 480041 patch
thanks

[Bryan Cain]
> I've uploaded a patch for this bug to
> https://bugs.launchpad.net/ubuntu/+source/neon27/+bug/294648
> <https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648>.  Joe
> Orton has already committed the fix upstream in libneon.

Attaching this patch here, in dpatch format.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

[02_client_cert.dpatch (text/plain, attachment)]

Message #316 received at 480041-close@bugs.debian.org (full text, mbox, reply):

From: Laszlo Boszormenyi (GCS) <gcs@debian.hu>

To: 480041-close@bugs.debian.org

Subject: Bug#480041: fixed in neon27 0.29.3-3

Date: Sun, 24 Oct 2010 17:17:35 +0000

Source: neon27
Source-Version: 0.29.3-3

We believe that the bug you reported is fixed in the latest version of
neon27, which is due to be installed in the Debian FTP archive:

libneon25-dev_0.29.3-3_amd64.deb
  to main/n/neon27/libneon25-dev_0.29.3-3_amd64.deb
libneon27-dbg_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27-dbg_0.29.3-3_amd64.deb
libneon27-dev_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27-dev_0.29.3-3_amd64.deb
libneon27-gnutls-dbg_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27-gnutls-dbg_0.29.3-3_amd64.deb
libneon27-gnutls-dev_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27-gnutls-dev_0.29.3-3_amd64.deb
libneon27-gnutls_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27-gnutls_0.29.3-3_amd64.deb
libneon27_0.29.3-3_amd64.deb
  to main/n/neon27/libneon27_0.29.3-3_amd64.deb
neon27_0.29.3-3.diff.gz
  to main/n/neon27/neon27_0.29.3-3.diff.gz
neon27_0.29.3-3.dsc
  to main/n/neon27/neon27_0.29.3-3.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 480041@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Laszlo Boszormenyi (GCS) <gcs@debian.hu> (supplier of updated neon27 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 24 Oct 2010 18:20:49 +0200
Source: neon27
Binary: libneon27 libneon27-dev libneon27-dbg libneon27-gnutls libneon27-gnutls-dev libneon27-gnutls-dbg libneon25-dev
Architecture: source amd64
Version: 0.29.3-3
Distribution: unstable
Urgency: low
Maintainer: Laszlo Boszormenyi (GCS) <gcs@debian.hu>
Changed-By: Laszlo Boszormenyi (GCS) <gcs@debian.hu>
Description: 
 libneon25-dev - Header and static library files for libneon25
 libneon27  - An HTTP and WebDAV client library
 libneon27-dbg - Detached symbols for libneon27
 libneon27-dev - Header and static library files for libneon27
 libneon27-gnutls - An HTTP and WebDAV client library (GnuTLS enabled)
 libneon27-gnutls-dbg - Detached symbols for libneon27 (GnuTLS enabled)
 libneon27-gnutls-dev - Header and static library files for libneon27 (GnuTLS enabled)
Closes: 480041
Changes: 
 neon27 (0.29.3-3) unstable; urgency=low
 .
   * Fix client certificate negotiation with a patch that got included in
     v0.29.5 (closes: #480041).
   * Updated Standards-Version to 3.9.1 .
Checksums-Sha1: 
 40278f80c50f16e1a49cfae58447ad91e7f29291 1274 neon27_0.29.3-3.dsc
 fb01189849a837b5a094d2091904b69497ee90a0 9707 neon27_0.29.3-3.diff.gz
 207adce7366a945d2e4c75ee1c67b7f4960eade0 168316 libneon27_0.29.3-3_amd64.deb
 4bb6b252b70b7169f3a30bad6eee0eb74646f762 457666 libneon27-dev_0.29.3-3_amd64.deb
 95dd064b9de1c08d387aad90f698c15c18eca75a 205354 libneon27-dbg_0.29.3-3_amd64.deb
 0c334f6d71f48cfbd3815d6bbdb9758cff5e518a 139110 libneon27-gnutls_0.29.3-3_amd64.deb
 8370eaa609bef38753b95c37fe291106fffb5dcc 425216 libneon27-gnutls-dev_0.29.3-3_amd64.deb
 c437a231eab9ba01827dd0d305eeaa95428f5d6d 183624 libneon27-gnutls-dbg_0.29.3-3_amd64.deb
 8288058c55713c89acc6774b968d2a016dc44b3c 63236 libneon25-dev_0.29.3-3_amd64.deb
Checksums-Sha256: 
 24f0b6221721227fc0bdb2961f6985e1c05f3b31ab7fe95f4ad9118586fcb75f 1274 neon27_0.29.3-3.dsc
 17c8f30c17fd68f8daf0d8279306a00d08ffba280981b5ab71178c089983120f 9707 neon27_0.29.3-3.diff.gz
 6a6231c14ef9a8171a787122706377d077ddf11ffd3ec9403f2b2f500eb3695d 168316 libneon27_0.29.3-3_amd64.deb
 998b86c6093774225fecfe317a0a6f90b3434a241cb727e180225dd804bb63e9 457666 libneon27-dev_0.29.3-3_amd64.deb
 9eef584d8d2de30ca0cf5fd732adf044e65d0aa387205e97178110bd916c4900 205354 libneon27-dbg_0.29.3-3_amd64.deb
 29f7cd9e2a9da43173bba7047dece91fa137cf51fb0ba49e76a5004dc0c22b6e 139110 libneon27-gnutls_0.29.3-3_amd64.deb
 92082942b06630f5309a9a1af37976cf28d9d5cc93d54b899385e52a84035151 425216 libneon27-gnutls-dev_0.29.3-3_amd64.deb
 5edda1817e42a72426c3d9e9b05bac824c8c2aae2ae29f1d657cfb8108953c94 183624 libneon27-gnutls-dbg_0.29.3-3_amd64.deb
 aab9b1c4c35ce2a08de1340d16e2b36b5c6cefb38cec3d9c21caea3fb06c394f 63236 libneon25-dev_0.29.3-3_amd64.deb
Files: 
 cb8a68935ee848881986aa5d8dd01bf4 1274 net optional neon27_0.29.3-3.dsc
 7455eaf1bb11779d3aa9204d53303df1 9707 net optional neon27_0.29.3-3.diff.gz
 91e980d88ad1e840b6c0450e36c38d21 168316 libs optional libneon27_0.29.3-3_amd64.deb
 1cddbd647392b06f8c1ce9d7b0f3880a 457666 libdevel optional libneon27-dev_0.29.3-3_amd64.deb
 111404b894318ba6bdc56a16b34fed71 205354 debug extra libneon27-dbg_0.29.3-3_amd64.deb
 4c04a0b58b0af1db1f9b7ac648c1af86 139110 libs optional libneon27-gnutls_0.29.3-3_amd64.deb
 e461b4b925f3447fec67b732f8fb7fc9 425216 libdevel optional libneon27-gnutls-dev_0.29.3-3_amd64.deb
 b27f1907385d8f03ea5bf008fd6d4be9 183624 debug extra libneon27-gnutls-dbg_0.29.3-3_amd64.deb
 0abe90141ca9bd9abc37b65901705a77 63236 libdevel optional libneon25-dev_0.29.3-3_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzEZYkACgkQMDatjqUaT91nnQCbBBp6aYTVdM56s/xrOZ+6J9wi
RIwAn3I6OHbrExjVcsAKt5ZK/0zK22sG
=czP8
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.