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

Borini, Stefano @te|@no@bor|n| @end|ng |rom @@tr@zenec@@com
Thu Mar 17 11:37:47 CET 2022


    It's hard to convey tone in an email, but to me your post read more like
    a demand than a report of an issue.  I apologize for my misreading if
    that wasn't your intention.

No problem. I just wanted to point out that it is a problem. A lot of people use R and CRAN for regulated environment development. Inside our company, we do everything we can and more to ensure reproducibility and auditability of our results, but of course people may decide to migrate to other languages and environment if guarantees are hard to obtain on these respects. I've been following the EMA recommendations for validation, and the issue is getting more and more prevalent. As an individual working for my company, all I can do is to safeguard the code I produce and put into production to monitor for such events. It is my responsibility and I do everything I can to protect the integrity of the environment my users run calculations on.

   From Dirk's message, it sounds as
    though he knows a lot about this, so you could work with him to propose
    a change to the R build process.

We could. However, be aware that my expertise in terms of R is very lacking. I've been a long time python developer. All I do is migrate my python experience and apply it to R, but the deep technicalities of R and CRAN are unknown to me.

    Now it sounds as if you are accusing CRAN of shirking its
    responsibilities.  CRAN is not responsible for your workflow, you are.

No, but CRAN is responsible for hosting packages and their integrity. I am quite sure that if CRAN were to go away, there would be a complete uproar from the whole R community. Similarly, if CRAN were compromised and packages were modified to inject malicious code, people would be _very_ angry about it. Python has a few PEPs on PyPI integrity, e.g:

https://peps.python.org/pep-0458/

https://peps.python.org/pep-0480/

and a lot more on the Python Packaging Authority site.
The workflow is to download packages. How I download packages is a different story, but I am assuming that most R users don't give much thought about package SHA. Not sure if packrat or renv checks for SHA. I don't use them. As I said I found them inadequate and built my own solution.

    As I said before, I don't know how it happened that there were two
    builds of MASS on CRAN, built 50 seconds apart.  But a guess is that it
    was built and published, but something appeared to indicate that things
    failed, or someone accidentally repeated some keystrokes, and the
    process was repeated.  You were unlucky enough to download it during
    that 50 second window.

Highly unlikely. That day was bank holiday in the UK

Early May Bank Holiday  Mon, 3 May 2021

And I am certainly not working during a bank holiday, let alone re-run locking of packages. I also have to add that this is not the first time this event occurs. I've experienced this many, many times in the past 2 years. This is the first time I actually happen to have both the old package (in roo package cache) and the new one (downloaded) so I could compare the two.



________________________________


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>


More information about the R-package-devel mailing list