On 6/16/19 10:44 AM, brent s. wrote:
On 6/16/19 5:03 AM, Manuel Reimer wrote:
Hello,
I run a repository locally that I would like to share to the public.
The build is mostly automated. That's why I don't want to sign each individual package. The private key is not stored on the build machine and I want to sign the resulting stuff externally.
The easiest way would be actually to just manually sign the database file. As this file includes all checksums of the individual packages, I think this is as secure as signing every package, right?
Thanks in advance
Manuel
theoretically, your thought process is sound. unfortunately, pacman doesn't verify like this (to my knowledge; someone feel free to correct me).
but there's nothing necessitating you sign the package on the build machine, technically. you could fetch the repo DB, grab the checksums inside (i believe they contain a metadata tree and .PKGINFO; been a while since i explored the format), fetch the package itself into memory, and if the checksum matches, you can create a detached signature from that item in memory, then upload that signature. (i think? you might meed to regen the repo.db; not sure if it tracks sigs.) there is, of course, the trouble of not being able to cryptographically verify the integrity of the checksums inside the repo DB (since the packages are being fetches from a remote source and *technically* possibly could have been tampered along with the repo DB). this is why signing is done at build time - it at least removes that vector (notwithstanding local tampering, but that's time-sensitive and a dedicated build box separate from a repo server is a lot more resistant).
i can create a python PoC of this if that'd be easier to understand of the "remote signing".
BUT. TL;DR "pacman doesn't work like that" and it's generally safer practice to build and sign (and build a repo db) on a different box, then push to the repo server.
I have no idea what you just said. ... Manuel -- makepkg has a --sign option, but all it actually does is this: # pretend it actually uses ${pkgname}-${fullpkgver}-${pkgarch}${PKGEXT} for pkgfile in *.pkg.tar.xz; do gpg --detach-sign --no-armor "${pkgfile}" done You can run gpg --detach-sign --no-armor yourself right before you repo-add, it makes no difference whether you use makepkg's convenience function for this. As a matter of fact, if you use clean chroot builds then you possibly don't want to copy your private key to the chroot, and anyway there have IIRC been bugs with signing in a chroot, so the devtools scripts do not do signing in the chroot and the official upload scripts for core/extra/community will do gpg --detach--sign --no-armor by hand, so you are in good company! That being said, if you have signed the repository db then as you mentioned the sha256 checksums for the package file are securely signed, so you are guaranteed that use of pacman -S pkgname will securely verify that it is installing the package the repo-add user expected to provide when running repo-add. What is your threat model? These things will not be protected against: - people installing the package file directly, as such: pacman -U https://example.com/foopkg-1-1-x86_64.pkg.tar.xz - An attacker with local filesystem access on the signing/hosting server can retroactively replace *all* packages built at any date, and trick you into signing a new repo DB referencing them. - In shared packaging situations, like when a team of dozens of people all upload packages, you want to be able to verify who signed each package, as opposed to only verifying that the last person to update the repository asserted that all other packages are good and backed by his/her good name -- this does not concern you. -- Eli Schwartz Bug Wrangler and Trusted User