On Sat, Jun 1, 2013 at 9:14 AM, Randall Leeds <[email protected]>wrote:

> On Fri, May 31, 2013 at 4:30 PM, Jason Smith <[email protected]> wrote:
> > Hi, Benoit.
> >
> > I did not put this in a branch since it was a single commit. I think I
> > missed that IRC meeting and did not realize the policy.
> >
> > My original implementation assumed a "raw" update if the password had a
> > "-pbkdf2-" prefix. Yes, that means people can no longer have a password
> of
> > literally "-pbkdf2-<etc.>" but I figured CouchDB should DTRT in that one
> > special case.
>
> Isn't that already a restriction in the sense that you can't put a
> plaint-text password in the .ini that starts with -pbkdf2-?
>

Both methods have their own restrictions.

When editing an .ini file, you *can* trivially set a password cyphertext
(just paste it in), but you cannot set a password to literally
"-pbkdf2-...". (You could calculate the hash yourself and then paste that.)

When using the API, you *can* trivially set a password to literal
"-pbkdf2-..." but you cannot set the password to some cyphertext, as-is.
(And reversing the hash back to the plaintext is impossible.)

In other words, even if you are admin on couch A and admin on couch B, you
cannot synchronize the admin passwords using the API.


> > The new way (?raw=true), the API is explicit rather than implicit. That
> is
> > "simple" in its own way.
>

> But less simple in that it's a new parameter and new feature (assuming
> what I said before is correct -- that it was not possible via the .ini
> to have this kind of password). I'm leaning toward Benoit's suggestion
> on this one.
>

​I agree with Benoit too. However, I brought this up on IRC and literally
every person there had their own opinion. (Dikjan had a cool idea of
sending an object instead of a string.) It was a textbook bike shed.

Somebody made a decent argument that Couch should not "DWIM" depending on
the content of your config value. That way would change the API (in a rare
situation, I admit). With the "raw" option, the API is merely extended.

Reply via email to