[keeping this on the users@ list]
On Feb 23, 2005, at 11:07 AM, Josef Wolf wrote:
> On Tue, Feb 22, 2005 at 09:03:03PM -0600, Ben Collins-Sussman wrote:
>> On Feb 17, 2005, at 3:42 PM, Josef Wolf wrote:
>>> But when I connect to the same sever with svn, and svn asks me to
>>> verify the certificate, it prints me a completely _different_
>>> fingerprint.
>>
>> Hm, I can't reproduce this using the latest svn code. (And the ssl
>> code hasn't been touched in ages.)
>>
>> For example, when I tell mozilla to look at
>>
>> https://svn.red-bean.com/repos/sussman
>>
>> It shows me 2 different fingerprints: one for SHA1, one for MD5.
>
> Ah, this seems to be the problem here: subversion prints the sha1
> digest
> while tinyca, konqueror and even openssl print only md5 digest.
>
> The openssl command line tools default to md5. The only exception is
> DSA
> keys, where _always_ sha1 is used. Since I generated a RSA key,
> openssl,
> tinyca and konqueror present md5 signatures to me.
>
> I am not a crypto expert, but I wonder whether it would make sense to
> adopt openssl's behavior to subversion? Maybe it would make even more
> sense to simply print both digests so the user can choose the one that
> he was given when the certificate was generated. IMHO, the current
> behavior can cause lot of confusion to people that are not
> crypto-experts.
Subversion is using the API provided by neon, which is just a wrapper
around openssl functionality. Take a look in libsvn_ra_dav/session.c:
/* Extract the info from the certificate */
cert_info.hostname = ne_ssl_cert_identity(cert);
if (ne_ssl_cert_digest(cert, fingerprint) != 0)
{
strcpy(fingerprint, "<unknown>");
}
cert_info.fingerprint = fingerprint;
ne_ssl_cert_validity(cert, valid_from, valid_until);
cert_info.valid_from = valid_from;
cert_info.valid_until = valid_until;
cert_info.issuer_dname = issuer_dname;
cert_info.ascii_cert = ascii_cert;
Maybe we should be doing more? Or maybe there's some other neon cert
APIs we should be using? Patches are welcome.
> In addition, it forces one to take extra steps to verify the
> certificate.
> Unfortunately, the certificate is stored in a format that is not
> understood by openssl.
It's generated by the call to
char *ascii_cert = ne_ssl_cert_export(cert);
This ain't my field of expertise. Perhaps you should take up this
conversation on the neon list.
> So I ended up with
>
> $ grep ~/.subversion/auth/svn.ssl.server/07* | \
> perl -ne 'print "-----BEGIN CERTIFICATE-----\n";
> $x=64;
> while ($x<length $_) {
> substr($_,$x, 0, "\n");
> $x+=65;
> }
> print "$_-----END CERTIFICATE-----\n";' | \
> openssl x509 -inform PEM -fingerprint | \
> grep Fingerprint
>
> to verify the certificate. IMHO, verifying a certificate should not
> be _that_ hard ;-)
>
> BTW: It would be fine to have an independent option to store ssl
> certificates. To have a ssl certificate stored, I need to
> enable store-auth-creds (at least temporarily) and end up
> with my password in cleartext in the ~/.subversion/auth/svn.simple
> directory :-( :-( :-(
>
That's why we have the new "store-passwords = no" option in the
run-time config file. That way passwords will not be stored, but certs
will.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 23 18:29:40 2005