SRUs and the importance of validating upstream release tarballs

[Christian Ehrhardt]

On Wed, Oct 2, 2024 at 12:02 PM Robie Basak <robie.basak at ubuntu.com> wrote:
>
> If we take a fresh upstream release directly into a stable release
> update, then it seems to me that it's important to validate that the
> orig tarball matches what upstream released, or is otherwise
> reproducible against what upstream released (eg. if it was repacked for
> the usual reasons).
>
> It's not currently a documented hard requirement for SRUs, but I think
> that it should be, or at least be our default position.
>
> I've noticed some matter related to this concern a couple of days
> running so I thought it was time to start a thread on this.
>
> When reviewing an SRU that does this, I usually take steps to verify
> this. If it doesn't match (usually due to a repack I cannot reproduce)
> then I query it. This is sometimes quite painful to do as I try to track
> down an upstream source and some way to validate it.
>
> We have tooling to make this easy in the majority of cases, with uscan,
> debian/watch and debian/upstream/signing-key.asc. I usually run `uscan
> --download-current-version`, check that HTTPS or GPG was used, and that
> the resulting tarball's hash matches the hash in the upload's changes
> file.
>
> It might help to understand my position in the other thread by
> considering that I have myself been doing this kind of verification for
> years when I review SRUs that include orig tarballs.
>
> A few discussion points from this:
>
> 0) If you don't agree that this is important, then I guess this an
> opportunity to make your point.
>
> 1) If you're preparing a relevant SRU, this is a request for you to
> please ensure that uscan is set up appropriately with as much security
> as upstream offer. Preferably this is done and maintained in the
> development release, so by the time an SRU is required, there are no
> changes needed to uscan configuration. Since this tooling is
> well-established and this is best practice anyway, I trust that this
> isn't a controversial request! Note that uscan can do some repacking via
> mk-origtargz and Files-Excluded* in debian/copyright.
>
> 2) If uscan cannot be made to work, then it would be useful to document
> how you arrived at the orig tarball you uploaded.
>
> 3) To what extent should this become a documented requirement for SRUs,
> main inclusion, etc?

Just like you on SRU, I've been loosely looking at that when I was
looking at the NEW queue.
I say loosely because it is me doing it "mostly" but not part of these
rules and guidance we follow.
But it could be and that is why I bring it up.

Where it already is a requirement is the MIR process, a working
d/watch is checked there before getting to main.
This part of the rules is rather old, and back then not everyone was
that aware about the importance of sig/csum checks.

I'm +1 on your suggestion, but would - if agreed - extend it to also
get added to:
- NEW queue processing as recommended (we can debate if it shall be
strictly required)
- MIR processing to strictly require support for checksum/signature if
the upstream that backs it provides such

That would in the long run help to solve some of your "Preferably this
is done and maintained in the development release, so by the time an
SRU is required, there are no changes needed to uscan configuration"
desire.

> Robie
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd