On Tue, Apr 1, 2025 at 12:23 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > 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 ?
Yes, or the package stops being buildable from the URL specified in Sources. > 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). Fedora source cache should be just that: a cache. > 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. We can do a lot of things provided we can access SCM metadata from within the build process. Doesn't mean we should, because the benefit gained from this complexity is vanishingly low. Sources: https:/forge/project/archive/v0.0.14.txz + SHA512 (v0.0.14.txz contents) = f00g00... gives you all the guarantees you requested. Don't fall into the SecureBoot trap of "git tag signatures sometimes exist, so we must bend over backwards to leverage them no matter what at a great cost". > 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. And we have one. All it's missing is doing the unpacking that'd get rid of this determinism. > 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. I'm ambivalent to whether it should be a tag or a commit hash, just pick one and write it down in the policy. -- _______________________________________________ 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
