On Tue, Apr 01, 2025 at 10:49:59AM +0200, Alexander Sosedkin wrote:
> On Mon, Mar 31, 2025 at 9:31 PM Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> wrote:
> >
> > On Mon, Mar 31, 2025 at 01:24:06PM +0200, Alexander Sosedkin wrote:
> > > On Mon, Mar 31, 2025 at 12:56 PM Zbigniew Jędrzejewski-Szmek
> > > Just one question: how would you make those git forges output stable
> > > archives?
> > > GitHub itself explicitly says they won't and you shouldn't do that [2].
> >
> > Heh, I followed the link you provided, and they explicitly say:
> >
> > > If you rely on stable archives only for reproducibility (ensuring
> > > you always get identical files inside your archive), then we
> > > recommend you download source archives using the source archives
> > > REST API with a commit ID for the :ref parameter. There is no need
> > > to record the hash, since the commit ID ensures you’ll always get
> > > the same file contents inside the archive.
> >
> > and also
> >
> > > if we intend to change either archive format, we’ll provide six
> > > months’ notice in documentation, and on the blog and changelog.
> >
> > In other words, they understand that people expect the outputs to be
> > stable, they are stable, and if they ever want to change something,
> > we'll have plenty of advance notification.
>
> That's one very optimistic reading of it.
> I read it as "we broke it once, and you know what, we'll totally do it again".
> We don't wanna update the entirety of fedora lockfiles once they do.
Do we actually need to update the 'sources' file in that scenario though ?
The hash in the 'sources' file is current serving two purposes.
It is letting us
1. verify that the tarball matches the one upstream,
as a proxy for validating the content
2. verify that, when built in koji, the tarball acquired
from the Fedora source cache matches what the maintainer
imported originally
A change in git archive output is only important for (1),
not for (2).
Traditionally (1) is critical because with manually generated
tarballs (aside from the hash, or sometimes signature) you
have no other way to validating the content matches what
upstream provided.
With tarballs that are auto-generated from a git tag/commit,
(1) is no longer critical. Provided we can validate the git
tag signature and/or had recorded the original commit hash,
we could validate the tarball contents matches upstream.
So potentially we avoid the need to update the 'sources'
file has if 'git archive' ever changes its output in a way
that is not back compatible. We just need a tool for chcking
archive content against latest upstream archive.
It would be prudent to also keep a record of the original
git commit hash that the archive was created from, so that
we can verify the upstream git repo HEAD for the tagged
release didn't move.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
