[Git][reproducible-builds/reproducible-website][master] 2022-09: mention that excluding timestamps were not exactly well recieved.

[Vagrant Cascadian (@vagrant)]

Vagrant Cascadian pushed to branch master at Reproducible Builds / reproducible-website


Commits:
33474f9f by Vagrant Cascadian at 2022-10-05T13:16:58-07:00
2022-09: mention that excluding timestamps were not exactly well recieved.

- - - - -


1 changed file:

- _reports/2022-09.md


Changes:

=====================================
_reports/2022-09.md
=====================================
@@ -32,7 +32,7 @@ More details can be found in the `README.md` file [within the code repository](h
 
 David Wheeler also pointed out that there are some potential upcoming changes to the [OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/en) badge for open source software in relation to reproducibility. Whilst the badge programme has [three certification levels](https://bestpractices.coreinfrastructure.org/en/criteria) ("passing", "silver" and "gold"), the "gold" level includes the criterion that "The project MUST have a reproducible build".
 
-However, [David reported](https://lists.reproducible-builds.org/pipermail/rb-general/2022-September/002696.html) that some projects have argued that this reproducibility criterion should be slightly relaxed as outlined in an [issue on the `best-practices-badge`](https://github.com/coreinfrastructure/best-practices-badge/issues/1865) GitHub project. Essentially, though, the claim is that the reproducibility requirement doesn't make sense for projects that do not release built software, and that timestamp differences by *themselves* don't necessarily indicate malicious changes.
+However, [David reported](https://lists.reproducible-builds.org/pipermail/rb-general/2022-September/002696.html) that some projects have argued that this reproducibility criterion should be slightly relaxed as outlined in an [issue on the `best-practices-badge`](https://github.com/coreinfrastructure/best-practices-badge/issues/1865) GitHub project. Essentially, though, the claim is that the reproducibility requirement doesn't make sense for projects that do not release built software, and that timestamp differences by *themselves* don't necessarily indicate malicious changes. Numerous pragmitic problems around excluding timestamps we raised in the discussion of the issue.
 
 ---
 



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/33474f9f7c550b41ca88c9206dfe9d5df71be707

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/33474f9f7c550b41ca88c9206dfe9d5df71be707
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20221005/7b0bcefb/attachment.htm>