[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Different behaviour of storing plaintext passwords under Unix - svn log differes from svn co/up

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 24 Nov 2014 10:57:00 +0100

Ahhhh…

 

In that case you stumbled upon an old bug in the libsvn_ra_neon code, where we didn’t properly store the password in certain scenarios after a successful request. (There is probably an issue number somewhere)

 

These bugs were fixed for 1.7, and the whole libsvn_ra_neon library removed for 1.8.

 

                Bert

 

From: Schulz, Gunther [mailto:gunther.schulz_at_zeiss.com]
Sent: maandag 24 november 2014 10:03
To: Bert Huijben; users_at_subversion.apache.org
Subject: AW: Different behaviour of storing plaintext passwords under Unix - svn log differes from svn co/up

 

No – our server asks always for a password, but the client does not ask to store it. I had to enter the password for the svn log everytime.

Only if I use a svn co/up the server also asks, but in that case the client asks to store it.

 

Gunther

 

Von: Bert Huijben [mailto:bert_at_qqmail.nl]
Gesendet: Freitag, 21. November 2014 22:56
An: Schulz, Gunther; users_at_subversion.apache.org <mailto:users_at_subversion.apache.org>
Betreff: Re: Different behaviour of storing plaintext passwords under Unix - svn log differes from svn co/up

 

Does your server support anonymous read only connections?

 

If it allows those, it is completely expected that it doesn't use a password for authorizing things like log… and therefore never updates/stores passwords in that case.

 

Bert

 

From: Schulz, Gunther <mailto:gunther.schulz_at_zeiss.com>
Sent: ‎Friday‎, ‎November‎ ‎21‎, ‎2014 ‎4‎:‎05‎ ‎PM
To: users_at_subversion.apache.org <mailto:users_at_subversion.apache.org>

 

Hello,

 

I detected an unexpected behaviour of the subversion client (Debian 7.7, svn version 1.6.12 (r955767)):

 

The configuration settings of store-plaintext-passwords (yes/ask/no) are only validated if I execute svn commands like checkout or update, but not for a simple ‘svn log’ command:

- the password file in auth/svn.simple were not generated

- strangely I was asked if I want to store the hostkey certificate which worked seemlessly

- when using a ‘svn update’ or ‘svn checkout’ the expected behaviour was seen (prompt for saving or save automatically)

 

Usually this is not detected as one of the first calls are update or checkout commands, but I used here some scripting using ‘svn log’ and was wondering why my password was never updated, no matter where I changed the save-plaintext-passwords settings (/etc/subversion/servers or ~/.subversion/servers, global section or specific local server sections).

 

I assume this is a bug or at least a strange feature. Normally I would expect that the same authentication procedure is used for all the remote svn commands which require authentication against the server.

 

Please let me know if you need some traces or configuration settings…

 

BTW: Subversion server was running on a Windows server machine, access via WebDAV / https

 

Best regards,

 

Gunther

 

--
-----------------------------------------------------------------------------------------------------
Carl Zeiss SMT GmbH
Carl Zeiss Gruppe
Lithography Optics Division / Technology Mechatronics
Department LIT-TES
G u n t h e r      S c h u l z
Phone:                 +49 73 64 20-9672
mailto:        <mailto:gunther.schulz@zeiss.com> gunther.schulz@zeiss.com |  <http://www.zeiss.com/smt> http://www.zeiss.com/smt
Carl Zeiss SMT GmbH
Rudolf-Eber-Straße 2, 73447 Oberkochen
Geschäftsführung: Dr. Hermann Gerlinger (Vorsitzender), Dr. Andreas Dorsel, Axel Jaeger
Sitz der Gesellschaft: 73447 Oberkochen, Deutschland
Amtsgericht Ulm, HRB 725667, USt-IdNr: DE 811119999
-----------------------------------------------------------------------------------------------------
 
Received on 2014-11-24 10:59:14 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.