[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tag2upload (git-debpush) service architecture - draft



Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture - draft"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > This requirement can be met (as I mentioned before) by
> > including the tag object data as a file in the upload (listed
> > in .changes).  The signature can be verified without any
> > further data.  A git bundle is not needed.
> 
> What do you mean by tag object data?

I mean the output of "git cat-file tag refs/tags/debian/<v>".

Included as, say,   <source>_<version>-<revision>.git-tag
and referenced in .changes.

> Can you outline how to get from the dsc to a verification of the tag
> signature without contacting the dgit server?

Sure.

Split the tag object daa at the relevant ----- boundary.  This gives
you 1. an unsigned tag data file (first half) 2. a detached armoured
PGP signature (second half).  Feed that pair to gpgv (with appropriate
keyrings etc.).  That's it.

If information in the tag should be checked (eg, the intended source
package name or version, or the destination for the upload), this
should be parsed out of the "unsigned tag data file" half after
splitting, to avoid any possible attacks based on differences in
disassembly/parsing algorithms.

(Sample for this code can be found in dgit-repos-server and is already
deployed on the dgit git server; but it's not very hard.)

BTW, I thought the requirement was to be able to start with the upload
including the .changes, rather than necessarily with then .dsc, to do
this verification.  We could put the tag data file in the .dsc but it
seems to me that it is not really helpful to consumers of the .dsc and
that really we are putting it in the upload for the benefit of the
archive.  So the .changes is probably better.  Putting it into the
.dsc would involve changing more things to tolerate it (ie, ignore
it) and seems like a layering violation - the .dsc is firmly
dpkg's territory.

But the approach I sketch above would work for the .dsc too of course.

HTH.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: