Hi I think this is an interesting discussion, but I think we are not doing it in the right place. The discussion is more or less whether packages should be allowed in Debian in the first place. This should be discussed on some general mailinglist, like debian-devel or debian-project. LTS cannot put restrictions on what should enter Debian in general.
LTS is aout handling things that have already been there for years. With this said I think restricting packages because they are insecure is not the best way to do. If course we should not add software that are generally available to anyone as a service that is known to be extremely insecure. But most software can actually be quite badly written and this is not a problem from a security standpoint. If the user use insecure software in the right way it can work just fine. For example if you are using a text editor to write your own software that editor can have all sort of software problems without causing a security issue. In many cases it is better to have some software that fit your purpose even though they are not the best from a security point of view. I maintained Vnc (version 3) for many years. Vnc (3) was not in any way secure, at least it was not in the beginning. However with decent firewalls around your network this is not really an issue. Best regards // Ola On Fri, 12 Feb 2021 at 12:56, Paul Wise <p...@debian.org> wrote: > 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 > > -- --- Inguza Technology AB --- MSc in Information Technology ---- | o...@inguza.com o...@debian.org | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | ---------------------------------------------------------------
