[arch-general] Is it secure to just sign repository databases?

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190616/2b11d2d5/attachment.sig>