Re: Support for insecure applications
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
Reply to: