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

[Borini, Stefano]

CRAN rebuilds binary packages because of (potential) changes in
build-time dependencies. ABI changes, in the loose sense of the term.
E.g. package A can call the shared library of another package B. If
the ABI of B changes, then you need to rebuild A.

AFAICT packages are rebuilt frequently and often. E.g. if you look at
the package time stamps of the package files at
https://cran.r-project.org/bin/windows/contrib/4.2/<https://cran.r-project.org/bin/windows/contrib/4.2> you see that many
(most?) of the binaries were (re)built yesterday.

Well, the binaries it’s a different story and needs its own solution. I am referring to the source packages, not the binary ones. So I suspect that when the binaries are rebuilt, the DESCRIPTION file in the source package is updated as well by the build system.
That’s what creates the issue.

Some time ago I suggested adding the Build field to the metadata, for
similar reasons. The Build field helps you decide if your package is
out of date or not, but a hash is obviously better, as you can also
use it to check the integrity of the package file.

One concern CRAN had with the Build field was that if
`update.packages()` used this field to decide if a package should be
updated, that would cause too many downloads.

I agree that it would be great to add the sha256 (or other) hash to
DESCRIPTION.

You can’t do that because then you would end up in a chicken egg situation where the sha of the tgz package depends on the content of the DESCRIPTION which would depend on the sha of the package.

Do you want me to study in more details on how it’s worked out in python? We could come up with a similar strategy, but I hardly doubt it will be implementable quickly and effortlessly.
Probably the easiest strategy is to have a gpg signature for each package, but it can get heavy for maintainers at CRAN, and it still does not really solve the problem if it’s automated. Whatever changes the source DESCRIPTION file, will have to repackage the source tar.gz, and then sign it anew.
________________________________

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]]