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

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



>>>>> "Sean" == Sean Whitton <spwhitton@spwhitton.name> writes:

    Sean> Hello Bastian,
    Sean> On Wed 31 Jul 2019 at 10:37PM +02, Bastian Blank wrote:

    >> On Wed, Jul 31, 2019 at 03:21:32PM -0400, Sam Hartman wrote:
    Bastian> One last time: The user has to certify his upload in a way
    Bastian> the archive can verify.
    >>> Let me see if I'm correctly understanding this requirement.
    >>> You're saying that given the dsc presented to dak by the
    >>> tag2upload service, dak needs to be able to verify the contents
    >>> of the DSC based on the user's signature and no external data.
    >> 
    >> Yes.
    >> 
    >> dak will push the signed .dsc into the pool.  This file and the
    >> complete source package can then be verified independently by
    >> everyone.  We don't need to trust ftp-master's verification of
    >> the signature.
    >> 
    >> Not only dak, but everyone who downloads the source package needs
    >> to be able to verify the user signature.
    >> 

    Sean> Okay, thanks.

    Sean> I think that the Git-Tag-Info field solves this.  With that
    Sean> field available, anyone can do the following to perform an
    Sean> equivalent verification:

    Sean> 1. fetch the .dsc from the archive

    Sean> 2. fetch, from dgit-repos, the tag given in the Git-Tag-Info
    Sean> field of the .dsc

This violates the "no external data" requirement above.

You could technically meet this requirement by including a git bundle in
the dsc, although that would be an unacceptable design for a variety of
other reasons that seem obvious enough not to require enumeration.

--Sam


Reply to: