[R-pkg-devel] Ensuring permanence and SHA consistency of released CRAN packages for validated software

[Borini, Stefano]

Sure, but why rebuild the package that has already been built?
Alternatively, would it be possible to have an index containing the sha of the packages, both of the current and of the archive? It doesn’t necessarily solve (someone hacking CRAN to inject a package would certainly make sure to update the SHA as well) but at least I would have information on integrity.

And while I am here, would it be possible to have a PACKAGES index equivalent also for the Archive? I wrote my own package resolver, here

https://github.com/AstraZeneca/roo/

to create my environment. It’s similar to python poetry, but I currently can’t do backtracking when a constraint is not respected, pubgrub style, or I would have to download a lot of stuff.
If I had an index covering both the current and the archive packages, I would be able to evaluate the dependency tree without downloading the package and inspecting DESCRIPTION for constraints, which would allow me to pubgrub it more efficiently.

If you want to talk about this in more detail, I have some experience with the issue on python (I worked for a major scientific python distributor, and I had to learn my fair dose of pain). I would not mind setting up a broader conversation, mostly referring to PEP and PyPA approaches.

--
Stefano Borini
Principal Analytical Tools Developer
AstraZeneca R&D BioPharmaceuticals | Data Science & AI | Early Biometrics & Statistical Innovation



From: R-package-devel <r-package-devel-bounces using r-project.org> on behalf of Dirk Eddelbuettel <edd using debian.org>
Date: Thursday, 17 March 2022 at 02:04
To: Henrik Bengtsson <henrik.bengtsson using gmail.com>
Cc: "r-package-devel using r-project.org" <r-package-devel using r-project.org>
Subject: Re: [R-pkg-devel] Ensuring permanence and SHA consistency of released CRAN packages for validated software


On 16 March 2022 at 14:01, Henrik Bengtsson wrote:
| Related to this, there's also been discussion (here or on R-devel), of
| having `R CMD build` produce identical tarballs when the input doesn't
| change, but the injection of `Packaged: <timestamp>; <user>` to the
| `DESCRIPTION` file prevents this. If I recall correctly, there was at
| least some discussion on being able to control, or anonymize, the
| <user> part.

It's much bigger than R: https://reproducible-builds.org/<https://reproducible-builds.org>

Started within Debian, but grew fairly quickly beyond one distribution to
many. We patched the build to use the (fixed) time from debian/changelog
(rather than current build time) and a few more things and were at some point
compliant, but there is still more and the package I stand behind as far as
Debian is concerned currently fails this goal of reproducible (i.e. binary
identical builds) [1] (and I have limited time to chase this, but the
initiative is very very good).

If someone wants to help please get in touch off-list. It should just require
some patience and diligence and I may teach your Debian builds in the
process. The r-cran-* packages generally pass which is good.

Dirk

[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/r-base.html<https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/r-base.html>


--
https://dirk.eddelbuettel.com<https://dirk.eddelbuettel.com> | @eddelbuettel | edd using debian.org

______________________________________________
R-package-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel<https://stat.ethz.ch/mailman/listinfo/r-package-devel>

________________________________

AstraZeneca UK Limited is a company incorporated in England and Wales with registered number:03674842 and its registered office at 1 Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only and may contain confidential and privileged information. If they have come to you in error, you must not copy or show them to anyone; instead, please reply to this e-mail, highlighting the error to the sender and then immediately delete the message. For information about how AstraZeneca UK Limited and its affiliates may process information, personal data and monitor communications, please see our privacy notice at www.astrazeneca.com<https://www.astrazeneca.com>

	[[alternative HTML version deleted]]