Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
> > Hi, Henrique de Moraes Holschuh wrote:
> >
> > > On Tue, 02 Dec 2003, Wouter Verhelst wrote:
> > >> So unless you have a suggestion that would solve this particular issue,
> > >> I'm afraid this idea won't work in practice.
> > >
> > > We could verify if the gpg agent (gpa? I forget the name...) cannot do
> > > this
> > > over a secure channel. It should be able to, and if not, it can probably
> > > be
> > > taught to.
> >
> > It's not that easy (basically you need to tunnel the actual
> > encryprion/signing function, not just the passphrase-getting).
> > See ssh-agent as an example.
> >
> > The good thing is that people are already thinking about this.
> >
> > http://lists.gnupg.org/pipermail/gnupg-users/2003-April/017920.html
>
> Well, implemented as Werner suggests in that message would require me to
> send the actual .deb over the line. I won't do that, since I don't have
> the bandwidth (or, in many cases, the time to wait for the download to
> finish; arrakis runs behind an ADSL line, while quickstep behind my
> cable modem. upstream speeds aren't that fast (and I regularly handle
> their mails at work)).
>
> As I understand it, an OpenPGP signature is an encrypted hash or
> something similar of the actual data. It would be feasible if the
> signature algorithm would allow for hashing the data on the remote
> machine, and signing that hash locally.
>
> Then again, we could do such things right now. Wouldn't it be more
> interesting to gpg-sign md5sums of control.tar.gz and data.tar.gz?
> Especially in the case of larger .debs, that would probably reduce the
> actual signature size as well...
The size being 132 bytes with only 72 bytes actual payload is small
enough.
But we could change what gets signed: Instead of signing the
control.tar.gz + data.tar.gz cated together the list of md5sums of all
files already present in the deb is signed.
The md5sums list would only be a few hundert bytes so transmitting it
over the network is not a problem. But it would mean one can't sign
buildd uploads offline anymore, or at least not in one go. The deb has
to be signed first and then a new chages file created.
Only transmitting and signing a digest of the deb is allways an option
if it becomes clear that splitting the gpg signing procedure (as
debsisgs uses now) between the remote and local system becomes to
complex. Lets see if a gpg agent can be developed that allows remote
signing without transmitting the deb.
MfG
Goswin
