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...
