Policy for software package requests

[jemrobinson]

✅ Checklist

• You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
• You are targeting the develop branch.
• Your branch is up-to-date with the develop branch (you probably started your branch from develop but it may have changed since then).
• If-and-only-if your changes are not yet ready to merge, you have marked this pull request as a draft pull request and added '[WIP]' to the title.
• If-and-only-if you have changed any Powershell code, you have run the code formatter. You can do this with ./tests/AutoFormat_Powershell.ps1 -TargetPath <path to file or directory>.

⤴️ Summary

Add a policy for approving software package requests. Note that this is a policy for adding packages to the main repository, and not a policy for any specific deployment.

Much of the text comes from #622 which was removed during the private-public transition but I think is still relevant here.

🌂 Related issues

Closes #622

🔬 Tests

Tested that automated package generation works as expected.

NB. CI test failure is due to the fact that we're adding a new .md file and the Edit this page link refers back to the non-existent file in GitHub.

[edwardchalstrey1]

If I was a reviewer, how would I know how to make this decision? Is it possible to expand some guidance here - for example, in Daniel from Edon's case, would the reviewer just google "R Arrow" and check it's a real package and somehow figure out if it's something without known security vulnerabilities?

[jemrobinson]

The issue template asks them to answer the following questions:

• Package name
• Package version (if different from latest)
• Package repository (e.g. CRAN, PyPI)
• Number of authors/contributors to the package codebase
• Any existing versions that should not be used (linking to publicly-accessible CVE databases if relevant)
• Download statistics (recent and longer-term, for both current and previous versions)
• List of packages that this package depends on
• What will you be able to do with this package that you can't currently do?
• Is this the most widely supported package for the intended purpose? What alternatives are there?
• What risks to data integrity/security might arise from including this package or its dependencies?

[edwardchalstrey1]

Makes sense, so the burden of checking risks falls to the requester

[jemrobinson]

The burden of explaining why the risks are manageable. We still don't have a well-defined way to make a decision based on these answers though :)

[JimMadge]

I think I'm not convinced that we should be doing this.

I really like the explanation of how we are confident about the security of the SRE, but that allowing data from outside presents risks to data mixing or other misuse.

The criteria for what we would consider adding seem quite broad.
I think this has caused us problems in the past, particularly with Python packages are resolving all dependencies across many packages is difficult (or impossible).

If that is what we really want to do, we should probably look at using lmod (or another module system) to isolate those packages.