On 16/09/12 23:56, Xyne wrote:
Tom Gundersen wrote:
Am 16.09.2012 08:34, schrieb Jan Steffens:
> I want avoid anything that requires me to upload the DB from my computer.
[...]
> That would be over 7MB I would have to download and upload Why can't the following procedure be used?
1) update the database on the server 2) download it 3) check it and sign it 4) upload the signature 5) check that the signature matches on the server
The database would only need to be locked during step 1. If user B updates it while user A is in the process of signing it, step 5 will ensure that the uploaded signature from user A is rejected and that user B's signature is kept, even if user B manages to upload a signature before user A.
Advantages: * no complicated locking * local signing (i.e. no keys on server) * minimal upload
What does "check it and sign it" mean? Diff it to the old and signed database? Anyway, I think it would need locked throughout. If B updates the database while A is uploading, that is not different to bad guy C adjusting the database and leaving it for someone to sign on the next addition. The only way to maintain what would be a chain of trust - where we can link each database update to the previous database - is to have the current db signature checked before adding the new packages and resigning. Worst case scenario is that you move stuff from [testing] to [core] and [extra] so you need to download three databases - probably less that 2MB in total and then upload three signatures. I am ignoring signing the .files databases...