Generate digest and signature seperately

[Dan McGee]

On Sun, Jun 12, 2011 at 7:54 PM, Jerome Baum <jerome at jeromebaum.com> wrote:
>> The databases (lists) are not very large, as far as I understand, but
>> it wasn't my call ("repositories" in the 4th line is a typo; I meant
>> "databases"). I'm not an Arch Linux developer; I'm just contributing
>> to their effort to implement package signing.
>
>> Individual packages will be signed, but for complete security, the
>> databases must themselves also be signed; otherwise, an attacker could
>> use DNS spoofing to deliver a database listing outdated packages with
>> known vulnerabilities, and it would happily be accepted by end-users'
>> systems. The vulnerable packages would not be updated, but the users
>> would most likely not notice, since other packages would be updated.
>
> All makes sense. Just don't get why it's so expensive to download a
> small package list?

I'll speak up as a developer here. I was the same one that asked about
a system-shared keyring last week if that helps bring it into context.

The actual issue isn't with package databases at all; those are, as
several people indicated, small enough to be copied, signed, and
uploaded as necessary. We're talking 50-500 KB or so here.

Our real issue revolves around signing very large packages. Take for
example, sage-mathematics [1]. This package clocks in at 306.3 MB
compressed. If this was built remotely on some build server and the
packager wanted to sign it, the current GPG signing workflow would
require to copy it locally where his secure keyring is located, sign
it, and then upload the signature file. The package itself could be
uploaded from either location.

With all that said, does anyone see a reasonable and secure workflow
for this? I did suggest [2] signing package hashes as one possible
option, after looking into agent forwarding and discovering that
doesn't seem to be a workable option at this point.

-Dan

[1] http://www.archlinux.org/packages/community/i686/sage-mathematics/
[2] http://mailman.archlinux.org/pipermail/pacman-dev/2011-June/013333.html