Re: Support for insecure applications
Hi, On Fri, 12 Feb 2021, Carles Pina i Estany wrote: > When I was discussing this with a friend I had thought if Debian could > make available and visible for the users some metrics, contextualised in > similar (per functionality) packages: That would certainly be useful to expose, yes! But many things that you are listing really relate to "best practices" for well run open source projects and there's at least one initiative to formalize those: https://bestpractices.coreinfrastructure.org And you can get a badge/label. It would certainly make sense for us to forward that kind of information to our users so that you can find out which of the software that you're looking at have made the effort to be structured according to best practices. But we're getting away from the initial topic which was really focused on the security aspect. > May I ask: how do people choose (security wise or in general) between > packages for a certain task? Could this be automated? Part of the I do it a bit like you, I have no formal process. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Support for insecure applications
On Fri, 2021-02-12 at 14:40 +0100, Ola Lundqvist wrote: > 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. Agreed, I encourage the team to start that discussion. > But most software can actually be quite badly written and this is not > a problem from a security standpoint. In an increasingly networked world it is hard to have poorly written software that doesn't interact with untrusted data at some point. > 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 a world where people are cloning git repositories from strangers and loading the code locally, poorly written text editors can theoretically become security liabilities. > 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. Agreed. > 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. We need more sandboxing and other ways to use poorly written software that avoid their potential for security liabilities. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Support for insecure applications
Hi, On Feb/12/2021, Sylvain Beucler wrote: > Hi, > > On 12/02/2021 01:17, Carles Pina i Estany wrote: > > When I was discussing this with a friend I had thought if Debian could > > make available and visible for the users some metrics, contextualised in > > similar (per functionality) packages: > > > > -popularity > > -number of recent updates in upstream > > -number of contributors > > -usage of control version system > > -test coverage > > -continous integration > > -upstream activity (issues, PRs, etc. with more the better GitHub or > > similar places stars, forks, etc?) > > -translations? (the more, more popualar the software is?) > > -warnings from the compilers? > > -static code analyser? > > -documentation? > > -CVEs? > > Almost none of these relate to software _security_. You are right, I was thinking on software quality hoping that security would come along in the majority of cases. > Let's keep in mind that active/popular software are often the ones > with the earlier Time-To-Market, at the expense of security (check the > history of PHP or Docker for instance). Yep, in number of items in my list I realise that it seems more like a popularity contest (it wasn't what I was thinking and Popularity Contest might be enough for this). I've read Paul Wise's email in this thread and I'll follow the links and project. I was thinking thinking on something along that lines but to give information to the final users. I'm interested in the checks that are already included there and see if they match the checks that I do when choosing software. We all decide to use A over B (e.g. to use pwgen password generator instead of one of the other at least 5 similar ones in Debian; or to use geeqie file image viewer instead of another one...) and having more information when choosing software might help taking better informed decisions. Perhaps it's not even about software quality but more general. Since probably my thoughts about metrics to help deciding packages might be off-topic here I'll move my thoughts to a better venue. Cheers, thanks for answering! -- Carles Pina i Estany https://carles.pina.cat
Re: Support for insecure applications
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 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.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
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
Re: Support for insecure applications
Hi, On 12/02/2021 01:17, Carles Pina i Estany wrote: When I was discussing this with a friend I had thought if Debian could make available and visible for the users some metrics, contextualised in similar (per functionality) packages: -popularity -number of recent updates in upstream -number of contributors -usage of control version system -test coverage -continous integration -upstream activity (issues, PRs, etc. with more the better GitHub or similar places stars, forks, etc?) -translations? (the more, more popualar the software is?) -warnings from the compilers? -static code analyser? -documentation? -CVEs? Almost none of these relate to software _security_. Let's keep in mind that active/popular software are often the ones with the earlier Time-To-Market, at the expense of security (check the history of PHP or Docker for instance). Also beware that "automated" ranking usually ends up pretty biased as well, e.g. social media's "algorithms" (or SourceForge's front-page projects some years ago). Cheers! Sylvain
Re: Support for insecure applications
Hi, When packages reach LTS, users have been using them for years, and it makes sense we try our best to fix vulnerabilities, and when that proves near-impossible, we mark them unsupported on a case-by-case basis. This accounts for poorly written software, but more often orphaned projects, codebases that change too fast, upstream EOL in high-complexity+hard-to-test projects, etc. 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. I'd add that we have room for improvements on our own reactivity. TL;DR, I think we're good as-is. Cheers! Sylvain On 11/02/2021 23:00, Brian May wrote: Hello, I notice that the quality of our packages can vary significantly. Some get frequent security updates, while with others the author appears to be confused just what an SQL injection attack is and how to prevent it. Not going to name names here, because they have done a wonderful job in developing the software, publishing it as open source, and getting it into Debian. And they most likely are not-paid and doing this on their own time. I think that possibly there are a number of packages and different (possibly seriously time constrained) authors here. Plus Debian doesn't seem to have any requirement that packages should be vaguely secure before a new package in accepted (maybe this needs to change?). However, I was wondering if we should even try to support such software that obviously has not been written to have any level of security? As even if we patch one CVE - chances are there are many more security waiting to be found. We are providing a disservice to our users by pretending that all software is secure, when obviously it is not. Yes, this could also result in a flame war with the author too. Which I would rather avoid. Maybe though people who are keen enough, and have time, to enter a flame war, are also keep enough to help fix the problems. But I am not sure that treating all software as equal, when it obviously isn't, is a good thing for our users. Yes, users can look up our security trackers, not sure how much this helps though. A lot of these open security issues aren't necessarily serious issues that warrant concern. Any ideas, comments?
Re: Support for insecure applications
Hi, On Feb/12/2021, Brian May wrote: [...] If this is off-topic in the list feel free to answer to me only, redirect to another mailing list and apologies for the noise. > But I am not sure that treating all software as equal, when it obviously > isn't, is a good thing for our users. > Yes, users can look up our security trackers, not sure how much this > helps though. A lot of these open security issues aren't necessarily > serious issues that warrant concern. > > Any ideas, comments? Some months ago I was thinking something along the same lines. I was comparing the source code of certain packages (10 packages more or less) searching for certain bugs but I saw how packages that might look similar from the outside varied a lot in quality, maintenance, etc. The problem is that from a user point of view it would be hard to know which one is better maintained. I think that when a package is distributed in Debian some users might expect certain quality because the package is in Debian. When I was discussing this with a friend I had thought if Debian could make available and visible for the users some metrics, contextualised in similar (per functionality) packages: -popularity -number of recent updates in upstream -number of contributors -usage of control version system -test coverage -continous integration -upstream activity (issues, PRs, etc. with more the better GitHub or similar places stars, forks, etc?) -translations? (the more, more popualar the software is?) -warnings from the compilers? -static code analyser? -documentation? -CVEs? So, when a user chooses a package the user would have more information to decide I was trying to think of metrics that could be automated (to a certain extend) to avoid flamewars between reviewers and upstream but metrics that might indicate software quality (hard to measure!). Another option would be like science publications: reviewers reviewing the code and rating it for different aspects but I agree that might be a never ending story, unless there is a clear cut. The Journal of Open Source Software (https://joss.theoj.org/) has a review criteria: https://joss.readthedocs.io/en/latest/review_criteria.html , https://joss.readthedocs.io/en/latest/review_checklist.html but some are still subjective, IMHO. May I ask: how do people choose (security wise or in general) between packages for a certain task? Could this be automated? Part of the process for my decision is seen above, plus looking at dependencies and sometimes at source code. Cheers, -- Carles Pina i Estany https://carles.pina.cat
Support for insecure applications
Hello, I notice that the quality of our packages can vary significantly. Some get frequent security updates, while with others the author appears to be confused just what an SQL injection attack is and how to prevent it. Not going to name names here, because they have done a wonderful job in developing the software, publishing it as open source, and getting it into Debian. And they most likely are not-paid and doing this on their own time. I think that possibly there are a number of packages and different (possibly seriously time constrained) authors here. Plus Debian doesn't seem to have any requirement that packages should be vaguely secure before a new package in accepted (maybe this needs to change?). However, I was wondering if we should even try to support such software that obviously has not been written to have any level of security? As even if we patch one CVE - chances are there are many more security waiting to be found. We are providing a disservice to our users by pretending that all software is secure, when obviously it is not. Yes, this could also result in a flame war with the author too. Which I would rather avoid. Maybe though people who are keen enough, and have time, to enter a flame war, are also keep enough to help fix the problems. But I am not sure that treating all software as equal, when it obviously isn't, is a good thing for our users. Yes, users can look up our security trackers, not sure how much this helps though. A lot of these open security issues aren't necessarily serious issues that warrant concern. Any ideas, comments? Regards -- Brian May https://linuxpenguins.xyz/brian/
