[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: [VOTE] Reverting r1845377 (Was: [PROPOSAL] Allow plaintext passwords again.)
From:       Daniel Sahlberg <daniel.l.sahlberg () gmail ! com>
Date:       2023-04-22 16:41:19
Message-ID: CAMHy98Mm7+V3PnD2CynwjEMvag78PWj5RPKuap6Ay-t_vpz5Kw () mail ! gmail ! com
[Download RAW message or body]

Den l=C3=B6r 22 apr. 2023 kl 10:30 skrev Branko =C4=8Cibej <brane@apache.or=
g>:

> On 22.04.2023 10:27, Branko =C4=8Cibej wrote:
>
> On 21.04.2023 16:43, Johan Corveleyn wrote:
>
>
> My plan is to revert r1845377 during next weekend. For the first bulletpo=
int nothing has to be done, but if consensus changes during the week, I can=
 do the work to to implement option 1. For the second bullet point I'd like=
 to reach consensus (on the short- and long term plan) by the same time, th=
en if we decide on 2/3 we will put it on the wish list for a future release=
.
>
> Great!
>
> There was one additional suggestion: obfuscate plaintext passwords, or
> encrypt them with a key embedded in the code (or even with a key
> supplied at compile-time).
>
>
> There's actually a branch for that, but the feature never made it to trun=
k.
>
>
> I'll just add that the intent of that branch is to properly encrypt
> passwords at least on Linux, not to obfuscate them or embed a key in the
> code. The latter is worse than storing in plain text, because the effect =
is
> the same but it adds a veneer of false sense of security.
>

I assume you are referring to the master-password branch? That will not
help with the use case some users are having - ie unattended svn actions -
since the user will have to enter the master password instead of the
password. (The use case "not remembering a lot of different passwords while
not storing passwords in clear" is of course solved by a master password).

--- thread reply ---
As you have probably seen, I've committed the revert as r1909351.

I have not made up my mind regarding the other points, but as pointed out
by several others, let's start with reverting and then take it from there.
I will read through all e-mails once more and see if i can sumarize the
discussion somewhat. So far I couldn't see any clear direction.

Kind regards,
Daniel

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Den lör 22 apr. 2023 kl \
10:30 skrev Branko Čibej &lt;<a \
href="mailto:brane@apache.org">brane@apache.org</a>&gt;:<br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  
    
  
  <div>
    <div>On 22.04.2023 10:27, Branko Čibej
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div>On 21.04.2023 16:43, Johan Corveleyn
        wrote:<br>
      </div>
      <blockquote type="cite"><br>
        <blockquote type="cite">
          <pre>My plan is to revert r1845377 during next weekend. For the first \
bulletpoint nothing has to be done, but if consensus changes during the week, I can \
do the work to to implement option 1. For the second bullet point I&#39;d like to \
reach consensus (on the short- and long term plan) by the same time, then if we \
decide on 2/3 we will put it on the wish list for a future release. </pre>
        </blockquote>
        <pre>Great!

There was one additional suggestion: obfuscate plaintext passwords, or
encrypt them with a key embedded in the code (or even with a key
supplied at compile-time).</pre>
      </blockquote>
      <br>
      There&#39;s actually a branch for that, but the feature never made it
      to trunk.<br>
    </blockquote>
    <br>
    I&#39;ll just add that the intent of that branch is to properly encrypt
    passwords at least on Linux, not to obfuscate them or embed a key in
    the code. The latter is worse than storing in plain text, because
    the effect is the same but it adds a veneer of false sense of
    security.<br></div></blockquote><div><br></div><div>I assume you are referring to \
the master-password branch? That will not help with the use case some users are \
having - ie unattended svn actions - since the user will have to enter the master \
password instead of the password. (The use case &quot;not remembering a lot of \
different passwords while not storing passwords in clear&quot; is of course solved by \
a master password).</div><div><br></div><div>--- thread reply ---</div><div>As  you \
have probably seen, I&#39;ve committed the revert as \
r1909351.</div><div><br></div><div>I have not made up my mind regarding the other \
points, but as pointed out by several others, let&#39;s start with reverting and then \
take it from there. I will read through all e-mails once more and see if i can \
sumarize the discussion somewhat. So far I couldn&#39;t see any clear \
direction.</div><div><br></div><div>Kind \
regards,</div><div>Daniel</div><div><br></div></div></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]