On 04/11, Remi Gacogne wrote:
- requiring TU and devs to sign the database when publishing a package is not easy and ;
It shouldn't be particularly hard, someone just has to do the work on devtools to support it.
- we don't want to have a package-signing key online if we can prevent it,
No need to do any signing at all on the server.
so ideally the key used to sign the database should not be able to sign packages ; - in addition to that, it would be nice if package-signing keys would not be able to sign the database.
Doesn't really matter much in practice. [snip]
As I am not a TU nor a developer, I am not familiar with the exact process used to publish packages. I have discussed this a bit with Levente, but this is clearly the fuzziest part for me, so please let me know if this is non-sense.
Basically, 1) packages are built locally (preferably in a clean chroot, but there currently aren't technically any rules about it.) 2) commitpkg signs the built package (if necessary), does a svn commit of the current PKGBUILd and misc versions, runs archrelease which copies the current package's trunk to the repos branch, then commitpkg rsyncs the built package and the signature to nymeria. 3) Dev or TU SSH's to nymeria and does a /community/db-update or /packages/db-update which locks the DBs, moves the built packages to the correct location, adds them to the DBs, and then unlocks them again. IMO the simplest way to add DB signing would be to modify the 3rd step to have a local wrapper that first SSHs to the server and runs a script to lock the DBs, moves the built packages in place, adds them to the DB and then exits. Then the local wrapper script would download the DB, and sign the DB locally before uploading the DB and the new signature, then runs a second remote script that puts the DB and signature in the right place and then unlocks the DB. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/