Bug 981431 - Authentication fails after Fedora 19 upgrade
Authentication fails after Fedora 19 upgrade
Status: CLOSED DUPLICATE of bug 983563
Product: Fedora
Classification: Fedora
Component: subversion (Show other bugs)
19
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-04 12:28 EDT by Mattias Ellert
Modified: 2013-07-31 16:09 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 16:09:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch against neon-0.29.6 to fix use of uninitialised size_t (426 bytes, patch)
2013-07-11 09:16 EDT, Simon
no flags Details | Diff

  None (edit)
Description Mattias Ellert 2013-07-04 12:28:43 EDT
Description of problem:

After upgrading to Fedora 19, authentication starts failing on svn https connections. No changes were made to the configuration that was working on Fedora 18 before the upgrade. Certificates are still valid - connecting to the same server using the same certificates from a CentOS 6 machine still works.

Version-Release number of selected component (if applicable):
subversion-1.7.10-1.fc19.x86_64
neon-0.29.6-6.fc19.x86_64
gnutls-3.1.11-1.fc19.x86_64

How reproducible:
Always:

Steps to Reproduce:
1. Upgrade to Fedora 19
2. svn update
3. watch it fail

Actual results:
$ svn update
Updating '.':
Passphrase for '/home/ellert/.globus/usercert.p12': 
svn: E175002: Unable to connect to a repository at URL 'https://svn.nordugrid.org/repos/nordugrid/arc1/trunk'
svn: E175002: OPTIONS of 'https://svn.nordugrid.org/repos/nordugrid/arc1/trunk': SSL handshake failed, client certificate was requested: SSL alert received: Handshake failed (https://svn.nordugrid.org)

Expected results:
$ svn update
Passphrase for '/home/ellert/.globus/usercert.p12': 
At revision 27886.
Comment 1 Simon 2013-07-11 04:29:59 EDT
I've also seen this. I've been trying to get to the bottom of it using neon-debug-mask. This gives:

req: Connecting to 192.168.11.112:443
Negotiating SSL connection.
ssl: Client cert provider callback; 1 CA names.
ssl: Mapped 1 CA names to 1 DN objects.
Passphrase for '/home/sah29/simon.harvey.p12': 
ssl: Match common name 'Simon Harvey' against ''
No client certificate supplied.
TLS fatal alert: Handshake failed

On a working Fedora 16, I get:

req: Connecting to 192.168.11.112:443
Negotiating SSL connection.
ssl: Client cert provider callback; 1 CA names.
ssl: Mapped 1 CA names to 1 DN objects.
ssl: Match common name 'Simon Harvey' against ''
ssl: Match common name 'Simon Harvey' against ''
Supplying client certificate.

Looking at the neon sources, the client certificate is not being provided by the callback function in Subversion which neon is calling (from ne_gnutls.c). I can't yet figure out why. The "gnutls-cli" utility can connect to this server fine if I provide it with the certificate and unencrypted public key from the p12 file.
Comment 2 Simon 2013-07-11 05:12:10 EDT
Having patched neon to enable GNUTLS logging, I see:
ssl: Client cert provider callback; 1 CA names.
ssl: Mapped 1 CA names to 1 DN objects.
002 ASSERT: pkcs12.c:1091
Passphrase for '/home/sah29/simon.harvey.p12': 
009 salt.size: 8
009 iterationCount: 2048
002 ASSERT: pkcs12_bag.c:709
009 salt.size: 8
009 iterationCount: 2048
002 ASSERT: common.c:1848
002 ASSERT: dn.c:307
002 ASSERT: dn.c:409
002 ASSERT: x509.c:521
ssl: Match common name 'Simon Harvey' against ''
No client certificate supplied.
Comment 3 Simon 2013-07-11 09:16:44 EDT
Created attachment 772216 [details]
Patch against neon-0.29.6 to fix use of uninitialised size_t

I've tracked this down to the x509_crt_copy function which is used to duplicate the client certificate. This make two calls to gnutls_x509_crt_export, the first supposedly to evaluate how large to make a memory buffer. Unfortunately, gnutls_x509_crt_export only returns GNUTLS_E_SHORT_MEMORY_BUFFER after first dereferencing the uninitialised size_t argument "output_data_size".

This patch correctly initializes size to 0 before calling gnutls_x509_crt_export which appears to fix the problem.
Comment 4 Simon 2013-07-11 09:30:19 EDT
Reported as a neon-specific bug 983563
Comment 5 Simon 2013-07-16 05:03:20 EDT
This was also reported back in November by someone else:
http://lists.manyfish.co.uk/pipermail/neon/2012-November/001518.html
Comment 6 Joe Orton 2013-07-31 16:09:15 EDT

*** This bug has been marked as a duplicate of bug 983563 ***

Note You need to log in before you can comment on or make changes to this bug.