Jeffrey Walton writes: > On Mon, Aug 17, 2020 at 10:33 AM Amin Bandali <band...@gnu.org> wrote: >> >> Jeffrey Walton writes: >> >> > The Savannah website uses ViewVC 1.1.26. It looks like ViewVC is a >> > couple of years out of date. >> > >> > The latest versions are 1.2.1 and 1.1.28. >> > https://github.com/viewvc/viewvc/tags >> >> The Savannah server running viewvc installs the viewvc package from the >> repositories of the distro it uses, which is almost always a few >> versions behind the latest upstream. We don't typically build and >> install software from source (as opposed to available distro package), >> unless there is a very good reason to do so. > > It seems like running old software is fairly toxic. We know server > comprimises most often occur due to stale software. Specifically, > software that is out of date by 30 days or more. > > ViewVC has fixed at least two vulnerabilities since 1.1.26. >
I only see one (issue #211 on their tracker) affecting 1.1.26, which was assigned a low severity [0]. Further, the vulnerability is in a feature that is disabled by default, including on the Savannah server running viewvc. [0]: https://github.com/viewvc/viewvc/security/advisories/GHSA-xpxf-fvqv-7mfg Thus, as I see it, the Savannah server running viewvc is not currently affected by any publicly-known vulnerabilities in the viewvc version it is running. > > GNU server compromise has happened in the past: > https://news.slashdot.org/story/10/11/30/2134203/gnu-savannah-site-compromised. > Whatever patch model is being used, it is not working. Learn from the > past mistakes. > > Jeff Here is a better link: https://www.fsf.org/blogs/sysadmin/savannah-and-www.gnu.org-downtime The attack was possible due to a SQL injection bug in Savane, the forge software developed and used by Savannah. I imagine the Savannah servers were running the latest version of Savane at the time. Yet they were still compromised. Thus, your example does not really support your argument. Also, do keep in mind that new versions/releases are inevitably how bugs get introduced in software. What guarantee is there that the newest version does not have new bugs? In most pieces of software developed today, none (see below). Also, I think you fail to realize/notice the countless possible attacks that were/are thwarted all through the years, thanks to (or despite) using the current software installation model of relying on security fixes in distro packages. Debian and other large distros are generally pretty good at patching vulnerabilities in the software they package. In closing, bugs happen. Programmers are humans, which by nature make mistakes every now and again. Sometimes grave ones, but nonetheless mistakes. The best way of eliminating bugs would be to have clear requirement specifications for the software at hand, and use formal verification techniques to verify the implementation against the specifications. Unfortunately, as of now, this is rather costly and nearly no free software projects do so. I hope that will change at some point.
signature.asc
Description: PGP signature