Commits (2)
......@@ -14,7 +14,7 @@ Welcome to the September 2022 report from the [Reproducible Builds]({{ "/" | rel
[![]({{ "/images/reports/2022-09/nsa.png#right" | relative_url }})](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/)
David Wheeler reported to us that the US National Security Agency ([NSA](https://en.wikipedia.org/wiki/National_Security_Agency)), Cybersecurity and Infrastructure Security Agency ([CISA](https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency)) and the Office of the Director of National Intelligence ([ODNI](https://en.wikipedia.org/wiki/Director_of_National_Intelligence)) have released a document called [*Securing the Software Supply Chain: Recommended Practices Guide for Developers*](https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF) (PDF).
David A. Wheeler reported to us that the US National Security Agency ([NSA](https://en.wikipedia.org/wiki/National_Security_Agency)), Cybersecurity and Infrastructure Security Agency ([CISA](https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency)) and the Office of the Director of National Intelligence ([ODNI](https://en.wikipedia.org/wiki/Director_of_National_Intelligence)) have released a document called [*Securing the Software Supply Chain: Recommended Practices Guide for Developers*](https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF) (PDF).
As David [remarked in his post to our mailing list](https://lists.reproducible-builds.org/pipermail/rb-general/2022-September/002684.html), it "*expressly* recommends having reproducible builds as part of 'advanced' recommended mitigations". The publication of this document has been accompanied [by a press release](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/).
......@@ -30,9 +30,9 @@ More details can be found in the `README.md` file [within the code repository](h
[![]({{ "/images/reports/2022-09/bestpractice.png#right" | relative_url }})](https://bestpractices.coreinfrastructure.org/en)
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".
David A. 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. Numerous pragmitic problems around excluding timestamps we raised in the discussion of the issue.
[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 pragmatic problems around excluding timestamps were raised in the discussion of the issue.
---
......