Den lör 20 aug. 2022 kl 14:27 skrev Olaf van der Spek <olafvds...@gmail.com
>:

> Op za 20 aug. 2022 om 12:39 schreef Daniel Sahlberg
> <daniel.l.sahlb...@gmail.com>:
> >
> > Den lör 20 aug. 2022 kl 12:20 skrev Olaf van der Spek <
> olafvds...@gmail.com>:
> > Check the available authentication credential caches:
> > [[[
> > $ svn --version
> > [...]
> > The following authentication credential caches are available:
> >
> > * Plaintext cache in /home/daniel/.subversion
> > * Gnome Keyring
> > * GPG-Agent
> > * KWallet (KDE)
> > ]]]
> >
> > If you are missing the Plaintext cache then your distribution compiled
> Subversion without the support for storing passwords in the plaintext
> cache. (The compile-time option changed in Subversion 1.12 to disable the
> plaintext cache unless explicitly enabled).
>
> Right, thanks!
> Does it really have to be this hard to store passwords? ;)
>

Well... yes. I assume it was a rethorical question but I'll answer anyway
for the benefit of the list.

There are radically conflicting requirements and priorities between
different users. Some want to store the authentication for full
in-the-background automation while others won't even allow a software that
potentially COULD store authentication credentials unencrypted (and SSH
keys are not significantly different than plaintext passwords in this
regards, the server setup makes all the difference what you can do if you
get hold of the credentials). The difference being how you treat access to
~, if you see it as world readable or if you see it as a secure part of
your computer (and in the latter case if you believe all bets are off in
case someone has physical access).

I'm running a local svnserve, is there a better way to handle this?
>

If you have the repository locally (I assume you have RW in the repository
folder), then you could checkout using the file:// protocol, leaving the
server out of the equation completely.

I'll also give the script a try.
>

(I'll reply separately to your other e-mail with the script error)

Kind regards,
Daniel

Reply via email to