For those who didn’t notice, there was a serious attack on the xz library:
I don’t want to go so much into the technology of the back door, but I would like to draw attention to the fact that it could come to this:
A subsequent investigation found that the backdoor was a culmination of approximately three years of effort by a user going by the name Jia Tan and the nickname JiaT75, who appears to have made a concentrated effort to gain access to a position of trust within the xz project, by putting pressure on the head maintainer to step down and hand over the control of the project through the use of sockpuppets.
In short, a person built malicious code into an open source project, by gaining trust and putting pressure on the head maintainer.
This will (hopefully) lead to consequences in the FOSS community, that we (the Fortran community) should follow. While we don’t have control over every Fortran open source project, we could and should think about security measures in the Fortran Registry.
I don’t know if it is possible, but it would be great if we also could provide some basic security measures with fpm, e.g. by checking whether a fpm project contains anything “impure”, that could be a security risk.
We have kept set of measures to prevent this in the fpm registry, like all the packages are run through a set of checks (we intend to expand this set of tests later currently only used to check for consistency of tarball) and all the users have the ability to report a package, add feedback, rate the package , all the package reports are directly reported to the sudo admins (org admins) and sudo admins have the ability to delete/disable any namespace/package/version/user.
One of the highest rated mechanisms in OpenBSD is the pledge() system, where the programmer declares what system resources the executable will use, which are enforced by the kernel. Until this becomes easier in Linux (things like SELinux and seccomp exist but are not used very much) it will give something for people to test and verify is accurate.
Once the registry is a bit more fleshed out and ready, I would really like to get integration with Dependabot, both for security advisories and also regular updates of fpm dependencies. I think we are long way from doing that, but it would be a useful feature for people who pin their dependency versions.
The fpm registry has the potential to mitigate current risks, as mentioned. Packages being frozen once registered is a powerful improvement, providing for a source that can be counted on for a long time but also has a pedigree and a method for problems to be reported is a significant improvement; but also creates a consolidated target (but so do things like github) but the repository should probably include a statement of liability. A quick glance did not show one. Is there/will there be something in the registry similiar to gitlab/github/ … or other software registries that states the conditions of use? I might have just missed it; but I was wondering if other registries require you agree to such terms when you run the equivalent of “fpm publish” or create a registry namespace, for instance. Everything from netlib to github to rust repositories has the same issue, so I am not suggesting this is a show-stopper by any means, but there probably should be something up-front about it.
David H. Wheeler’s Secure Programming on Linux is also worth study. despite being focused on C/C++.