On Fri, Feb 12, 2021 at 11:21 AM Sylvain Beucler wrote: > Pushing your point, we'd need to consider all software insecure by > default, perform regular code audits on the full Debian archive, which > would be very costly, and blocking packages from reaching testing, which > would introduce another bottleneck there.
The right place to be blocking poorly written software is before they enter the archive. I would like to suggest that folks interested in improving the security of incoming packages work on that. The first way to do so would be to influence uploading DDs and DMs to do at good auditing before adding new packages and minimal auditing on new package versions. Myself and Jakub Wilk worked on check-all-the-things, which makes it easier for devs to run static analysis and other tools over directory trees. Another option would be to have central infrastructure running the relevant tools, in the past there were DACA and Debile. Right now we have DACA2 from cppcheck upstream, but that just checks our upstream tarballs, ignoring our patches. We also have tarzeau's static analysis report, which ad-hoc runs a bunch of different tools over the archive. None of the static analysis tool outputs have ever been presented on the PTS, DPT, DDPO or anywhere else maintainers regularly look though. https://github.com/collab-qa/check-all-the-things/ https://wiki.debian.org/qa.debian.org The second way would be to start auditing new and existing packages where the maintainer is requesting a sponsor. Most sponsorship requests arrive on debian-mentors in the form of RFS mails, but a lot of sponsorship is handled via teams. This could help build a culture of doing auditing, by ensuring that new folks at least know what tools are out there. I've been doing a bit of this by running check-all-the-things and poking people towards looking at the results in response to RFS mails. -- bye, pabs https://wiki.debian.org/PaulWise