Comment 1 by Adrien Sulpice, Aug 3, 2010

I did some test and the problem does NOT come from Pear. The problem 
is this function :

/**
 * Get the repository password for the user
 */
function getSvnPass($user){
   return substr(sha1($user->password.Pluf::f('secret_key')), 0, 
8);
}

... It is not possible to find the originial password from the 
sha-1... So the value was never the good one. That is why the 
authentication was impossible.

I created a patch (atached file). In the processSyncPasswd function 
I use the variable $_POST['password'] instead 
$this->getSvnPass($user). And I completely commented the function 
generateProjectPasswd because it is not possible to find the 
password from the sha. Now it works.

I hope it helps.

• patch_ticket513.txt - 504 bytes - view

Comment 2 by Adrien Sulpice, Aug 3, 2010

Bon, je la refais en français comme ça ce sera compréhensible. J'ai 
également changé le patch. Cette fois il est propre contrairement au 
précédent qui était un bricolage.

Donc pour résumer, après multiples tests, je n'arrivais pas à faire 
un checkout d'un projet svn créé avec indefero. J'ai regardé et j'ai 
vu que les mot de passes encryptés dans le fichier 
/home/svn/dav_svn.passwd n'étaient pas corrects. J'en ai donc dans 
un permier temps déduit que le problème venait de Pear. J'ai donc 
moi-même recodé une classe permettant de gérer un fichier htpasswd. 
Après avoir fait ça, le problème a subsisté. J'ai donc commencé à 
débugger et je me suis rendu compte que le problème était en amont 
du cryptage. C'était en fait la chaine passée à la fonction qui 
renvoyait un mot de passe invalide.

J'ai essayé de comprendre pourquoi et j'ai trouvé la fonction 
getSvnPass($user). J'ai vu qu'elle essayait de faire un bricolage 
sur le mot de passe en renvoyant les 8 premiers caractère du sha-1 
de la secret_key (je ne sais pas ce que c'est, ça vient de Pluf que 
je ne connais pas du tout). Cette fonction génère en fait un mot de 
passe mais qui en plus de ça n'est pas toujours le même. Donc le mot 
de passe pour accéder au dépot svn n'est pas le mot de passe de 
l'utilisateur mais un autre mot de passe. Je n'ai pas compris 
l'utilité.

Après, je me suis dit que c'était une solution pour pouvoir 
regénérer les mots de passe du fichier passwd à partir de la base de 
donnée dans laquelle sont stockés les mot de passes cryptés 
(fonction generateProjectPasswd). Cette fonction est appelée lors de 
la modification des membres d'un projet afin de s'assurer (selon 
moi) que tous les membres du projet soient répertoriés dans le 
fichier htpasswd. Cependant, ce n'est pas forcément utile. Si tout 
se passe bien il n'y a pas besoin de le regénérer à chaque fois. 
Donc dans ce cas on insére le mot de passe seulement lors de 
l'inscription ou changement de mot de passe. Il est donc possible 
d'utiliser la variable $_POST['password'] directement.

EN BREF : ce que j'ai fait dans le patch joint est donc supprimer 
les fonctions getSvnPass et generateProjectPasswd qui sont inutiles. 
Et remplacé dans la fonction processSyncPasswd les appels à 
getSvnPass par la variable $_POST['password'] ce qui marche 
parfaitement. J'ai vu que le code de Mercurial était un copier/collé 
du svn à ce niveau, j'ai donc fait la même modification dans le 
fichier SyncMercurial.php.

J'espère que ça aura aidé et que le patch sera utilisé. Pour toutes 
questions supplémentaires, n'hésitez pas à me contacter. Si possible 
en français, ça facilitera votre travail de compréhension :p.

Cordialement.
Adrien Sulpice.

• patch_ticket513.txt - 4.21 kB - view

Comment 3 by Loïc d'Anterroches, Sep 1, 2010

As discussed, this point must be solved using a more thorough 
approach with hooks to avoid getting the passwords out of sync.

Comment 4 by Michael Sciscenti, Jun 18, 2012

Has there been any new progress on this issue? Is it still being 
considered?

Comment 5 by Arnaud Gomes, Oct 18, 2012

I have tried the patch in comment #2, it fails with LDAP 
authentication (the user's info is never written to the password 
file).