[arch-dev-public] [RFC] Moving repos to nymeria

[Xyne]

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



>Would we really need to sign the full 7MB database? Could we not come
>up with something more minimal to sign that would still be sufficient?
>Alternatively, we need to get Jan a better connection :)

This is something that came up before when discussing signing of the [haskell]
repo. The problem there is that Magnus builds the packages remotely and just
doesn't have the bandwidth to download the entire repo and sign it. We found no
solution, because the only way to verify the integrity of the file is to check
the entire file. Anything generated on the server (e.g. a list of checksums)
could be compromised if an attacker managed to gain access.

Security costs bandwidth. There does not seem to be any way around it.



>We don't need to lock the database for the duration of the
>download/sign/upload. We could simply:
>
> * check the timestamp of the old database
> * download the database
> * check the old signature
> * update the database and sign the new version
> * upload the database
> * lock the database on the server
> * check if the timestamp has changed
>   * if yes, release the lock and start from scratch
>   * if no, overwrite it with your new version and release the lock
>
>This means that you might need to retry once or twice if more than one
>person is updating the database, so it does not scale that well.
>However, we are not that many people and we don't update the database
>that often, so the chance of actually getting a conflict is low (and
>the additional cost is not that high either).

The procedure that I outlined above should avoid these conflict altogether. The
signature that matches the most recent version of the database wins,
regardless of the order of upload. It should work as long as the database is
locked when updated on the server.


Regards,
Xyne