2015-03-19 9:07 GMT+01:00 Jan Nijtmans <jan.nijtm...@gmail.com>:
> 2015-03-18 18:41 GMT+01:00 Richard Hipp <d...@sqlite.org>:
>> Perhaps the right way to handle this case is to modify
>> https://www.fossil-scm.org/fossil/info/2e4de226a7?ln=1066-1110 so that
>> if
>>
>> (1) The operation is "push", and
>> (2) There is exactly one entry in the BLOB table, and
>> (3) That one BLOB entry is a manifest
>>
>> Then it will overwrite the PROJECTCODE and "DELETE FROM blob; DELETE
>> FROM plink; DELETE FROM event;" before proceeding. (The SERVERCODE is
>> an historical artifact that is no longer used for anything and can be
>> safely ignored.) This would permit any repository to push into a
>> freshly created repo and the freshly created repo would take on the
>> identity of the repository that is doing the push.
>
> I like this idea. Thanks!
Even though I like this approach there is a problem: In the "user" table,
the password is not saved as-is, but it takes the form of a hash which
is constructed taking the "project-code" into account. So, as soon as
the project-id of an existing project is changed, all current passwords
stop working: no-one can log-in any more!
See:
<http://fossil-scm.org/index.html/artifact/475f5dc5fd546d3e?ln=367-382>
If the project-code is not set, the password is stored unhashed, so that's
the way out as I currently see it.
Hacking continues ......
Regards,
Jan Nijtmans
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
