Re: Tagging in Salsa -> upload: status?
On 8/13/20 10:07 PM, Sean Whitton wrote:
> Hello Didier, Christian,
>
> On Thu 13 Aug 2020 at 09:08PM +02, Didier 'OdyX' Raboud wrote:
>
>> Le jeudi, 13 août 2020, 11.19:59 h CEST Christian Kastner a écrit :
>>> Unless I'm grievously misremembering something, there was a discussion a
>>> while ago about automatically generating a source package and uploading
>>> it whenever a Debian release is (signed-)tagged in Salsa.
>>>
>>> If I did remember correctly: may I kindly inquire what the status on
>>> that is?
>>
>> I think I was the one with that idea [0], and I threw around some code last
>> winter, but I never really finished this; as I've stuck to using `dgit push-
>> source` for now.
>>
>> The idea would be to have: a `dgit tag-source-for-upload`, which produces a
>> tag with all the metadata needed by a knowledgeable tag consumer to reproduce
>> a signed .dsc + a signed _source.changes. That knowledgeable tag consumer
>> would run at the end of a salsa pipeline.
>
> Ian and I implemented something along these lines last summer and it's
> available to try from the archive; here is how:
> <https://spwhitton.name/blog/entry/tag2upload/>
>
> 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?
> 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?
Cheers,
Thomas Goirand (zigo)
Reply to: