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

Re: Tagging in Salsa -> upload: status?



Hello Thomas,

On Thu 13 Aug 2020 at 10:36PM +02, Thomas Goirand wrote:

> On 8/13/20 10:07 PM, Sean Whitton wrote:
>>
>> As to the current status: FTP Team members objected to having
>> uploader-signed git tags on dgit.debian.org be the canonical record of
>> an uploader's intended source package (rather than uploader-signed .dsc
>> files stored on other servers)
>
> Did you think about ways to workaround this, for example, by having some
> signed content in the signed git tag comment? For example, how about a
> signature for the .dsc file stored in it, and having the package
> reproducible (and making sure it is in the build process)? Or is the
> intend to avoid completely building packages on DDs laptop? In such
> case, a signature of the debian/changelog could do?

Once you go down that road you basically end up with `dgit push-source`
which already exists and works well.

What would be worth having in addition to `dgit push-source` would be
source-only uploads triggered by the pure git operation of pushing a
signed tag to salsa, such that the entire package build chain occurs on
Debian-controlled hosts with a signed git tree as input, rather than the
current situation where various things happen on random DD laptops, even
for source-only uploads.

As I mentioned, the issue was that FTP Team members were unhappy with
how someone who wanted to verify uploader intent would need to fetch
tags from a git server as opposed to downloading .dsc files.

(It's worth noting that unlike salsa tags, the tags on dgit.debian.org
are immutable.  The maintainer pushes a tag to salsa but tag2upload
copies it to dgit.debian.org, where it becomes a permanent record.)

>> and they objected to the ways in which
>> the system relies on git SHA1 hashes.
>>
>> I still believe that the design is sound and deploying the system can
>> and should go ahead, but we could not overcome the disagreement.
>
> Is there a workaround that git SHA1 weakness? Would it still be valid
> with my suggestion above?

Well, Ian and I do not think the issues with git and SHA1 are valid for
the ways in which git-debpush and tag2upload use git.  Several DDs who
are security experts (as indeed Ian is) analysed our design and agreed
with us.

The workarounds we came up with would compromise the simplicity and
usability of the system we came up with, so given that we do not think
that SHA1 worries are valid, we didn't consider any of them viable.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: