On Mar 3, 2011, at 4:24 PM, Johan Corveleyn wrote:
> On Thu, Mar 3, 2011 at 6:25 PM, Rudy Grigar <rudy_at_tag1consulting.com> wrote:
>> I worked through an issue this morning with a Subversion user that was unable to store a password locally:
>>
>> Authentication realm: <https://code:443> Zinch SVN Drupal
>> Password for 'dev':
>>
>> -----------------------------------------------------------------------
>> ATTENTION! Your password for authentication realm:
>>
>> <https://code:443> SVN
>>
>> can only be stored to disk unencrypted! You are advised to configure
>> your system so that Subversion can store passwords encrypted, if
>> possible. See the documentation for details.
>>
>> You can avoid future appearances of this warning by setting the value
>> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
>> '/var/lib/hudson/.subversion/servers'.
>> -----------------------------------------------------------------------
>> Store password unencrypted (yes/no)? yes
>> At revision 2260.
>> [hudson_at_srv-zinch-ec2db3 devdrup.zinch.com]$ svn up
>> Authentication realm: <https://code:443> Zinch SVN Drupal
>> Password for 'dev':
>>
>> -----------------------------------------------------------------------
>> ATTENTION! Your password for authentication realm:
>>
>> <https://code:443> SVN
>>
>> can only be stored to disk unencrypted! You are advised to configure
>> your system so that Subversion can store passwords encrypted, if
>> possible. See the documentation for details.
>>
>> You can avoid future appearances of this warning by setting the value
>> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
>> '/var/lib/hudson/.subversion/servers'.
>> -----------------------------------------------------------------------
>> Store password unencrypted (yes/no)? yes
>> At revision 2260.
>>
>>
>> The password wasn't actually being stored, the root of the problem being that auth/svn.simple/* was set read-only/444 (the cause of this is still unknown).
>>
>> I talked to Stefan (stsp) this morning in #svn and he wants to add better error handling here when the file isn't writable instead of silently failing to store the password. The relevant IRC log is here: http://colabti.org/irclogger/irclogger_log/svn?date=2011-03-03#l243
>>
>
> I've seen this happen recently by using svnkit ([1]). I don't remember
> the exact conditions (I was experimenting with use of svnkit via
> svnant in an ant build script), but it happened only when using a
> recent version of svnkit (1.3.5, i.e. the latest version at this time;
> with svnkit 1.2.0 the problem didn't happen).
>
> Is svnkit possibly involved somehow?
>
> I think svnkit does this when running on unix with the "unencrypted"
> situation. It's trying to cache the password, but it won't do it
> because it's going to be stored unencrypted. After that, the file
> seems to be read-only.
>
> --
> Johan
>
> [1] http://www.svnkit.com/
svnkit isn't being used currently. Hudson is being used to auto update the dev environment, but it's just using a standard 'svn up' from the shell.
It's also possible that someone else reconfigured or changed this around without me knowing -- the box that this is configured on is a bit of a moving target. I'm more interested in seeing an improved error message when the permissions prevent the password from being stored.
Thanks!
Rudy
Received on 2011-03-04 03:13:07 CET