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

Re: tag2upload service architecture and risk assessment - draft v2



On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
> Scott Kitterman <debian@kitterman.com> writes:
> > As an example, I recall concerns about there not being an uploader
> > signature on the source anymore, so we would lose the ability to verify
> > from the archive who was responsible for the upload.
> Does anyone do this?  Does it work today?

Yes, I did in the past complete security archive checks against
signatures, both on the advisories when they still contained checksums,
and the dsc signatures.

> I'm dubious that you would be able to successfully verify all of the
> archive from *.dsc signatures now.  Maybe you would be able to verify the
> pieces that are the most important to you, though?

Still, even if the success rate it not a 100%, do we want to actively
abolish this possibility and reduce it to ~0%?

> I think this requirement is a bit incomplete, in that I don't understand
> the use case that would lead you to want to do this.  It's more of a
> description of an implementation strategy than a use case, which makes it
> hard to find other ways of accomplishing the same use case.

We don't want to be forced to trust ftp-master.  We have reproducible
builds to verify the content of binary packages.  We have the user
signatures to verify source packages.  Of course none of this are
foolproof or will work all the time.

Right now the team delegated to keep the archive running and safe is not
willing to drop the ability to verify the contents independently.

Regards,
Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
		-- Sirah the Yang, "The Omega Glory", stardate unknown


Reply to: