Re: Support for insecure applications

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 <pabs@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