[ 
https://issues.apache.org/jira/browse/SVN-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150350#comment-17150350
 ] 

Daniel Shahaf commented on SVN-4861:
------------------------------------

You can use the --password-from-stdin option instead.

Also, if I'm reading the code correctly, simply adding the password to the 
md5sum(realm)-named file in ~/.subversion/auth/svn.simple/ should work: the 
compile-time knob prevents passwords from being _written_, but doesn't prevent 
passwords already there from being read.

Please continue discussion on the us...@subversion.apache.org public mailing 
list.  Thanks.



> Automation of SVN without "plaintest password store" is clunky
> --------------------------------------------------------------
>
>                 Key: SVN-4861
>                 URL: https://issues.apache.org/jira/browse/SVN-4861
>             Project: Subversion
>          Issue Type: Bug
>    Affects Versions: 1.12.0
>            Reporter: Alexander Falb
>            Priority: Major
>
> [Since 1.12.0 the plaintext-password-store is disable on Linux on compile 
> time|https://subversion.apache.org/docs/release-notes/1.12#client-server-improvements].
>  This makes it very hard to automate Subversion on Linux in a "headless" 
> environment like a docker container.
> In my particular situation on some conditions a dockerized script needs to 
> commit a few files to SVN. My current approach is to start a gpg-agent (or 
> reconnect to it if its already running), preload the password in gpg-agent 
> (because gpg-agent might have expired it) and finally do the SVN commit. I 
> however first need to calculate the md5 hash of the SVN auth realm, to 
> identify the gpg-agent key-handle.
> Overall a lot of steps that would not be necessary if SVN would save the 
> passwords in it's plaintext store. In the end I'm now keeping a plaintext 
> store to preload gpg-agent, I have a process running in my container that 
> could be omitted and the script is a lot clunkier than needed.
>  
> Please advice if my approach is the way to go or if I'm doing something 
> terribly wrong.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to