Slashdot Mirror
Linux Foundation's Census Project Ranks Open Source Software At Risk
jones_supa writes: The Core Infrastructure Initiative, a Linux Foundation effort assembled in the wake of the Heartbleed fiasco to provide development support for key Internet protocols, has opened the doors on its Census Project — an effort to figure out what software projects need support now, instead of waiting for them to break. Census assembles metrics about open source projects found in Debian's package list and on openhub.net, and then scores them based on the amount of risk each presents. Risk scores are an aggregate of multiple factors: how many people are known to have contributed to the project in the last 12 months, how many CVEs have been filed for it, how widely used it is, and how much exposure it has to the network. According to the current iteration of the survey, the programs most in need of attention are not previously cited infrastructure projects, but common core Linux system utilities that have network access and little development activity around them.
What they did is getting a basic overview of which projects need most attention. This is the first stage in improving the situation the most effective way. Now people/companies which have an interest in linux security as a whole (e.g. redhat) have a list of projects they can contribute to, even sorted by which to contribute first. I think the list is incredibly useful. Before heartbleed nobody did this kind of research, or it didn't get any attention.
Mostly it will be that OpenSSL has a larger encryption library, that is available for general use, and thus more useful.
As FOSS projects become more widely used (privately and by companies), it's an excellent idea to actually collect some statistics that give an idea of how well and how actively a project is maintained.
An attacker might e.g. get commit rights to several low-activity projects, insert malicious code, and wait for people to download updates and become easily exploitable.
No FOSS end-user ever checks code: they rely om the maintainers to produce clean and honest code. Large and tech-savvy businesses tend to be a little more cautious, but in the end only a minority have the staff and the budget to actually vet the code. So unless they're going to expose themselves by redistributing the code, or they know they're going to use it in mission-critical ways, they won't look into it very deeply.
This leaves users vulnerable. Because when a project is "asleep", it's a good candidate to slip in some backdoors.
Given the number of FOSS projects, it can be quite hard for any organisation to get an idea of (let alone metrics on) how well maintained those projects are. Doing this and making the numbers public is a very useful service.
Of course, as no doubt various FOSS enthusiasts will rush to point out, it's not a perfect indicator.
Well ... it isn't and it doesn't have to be, but it's a very useful indicator all the same. And if you can easily look up a project's rating, that will sharply increase the likelihood that it will be used.
I guess it's understandable. Those guys wrote those things to scratch an itch and they worked well enough long enough. If a company where trying to maintain all the code that goes into a typical Linux install for me, it'd probably cost billions of dollars. It seems to me it would be fairly easy to subvert entire subsystems in a distribution by, for example, waiting for everyone to be happy with how it works and going off, then picking up maintenance or starting a replacement project because "No one works on that old one anymore!" Next thing you know, the system you used to love is bleeding features left and right and before you know it ends up being a dumbed-down version of Windows. Maybe that's just the open source lifecycle on a scale of decades...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
There's far too much software out there that depends on having clocks close to in sync.
That is all.
No surprise about tcpd (aka Wietse Venema's TCP wrapper utilities) which has not been updated since its last release in 1997.
It should just be removed from all Linux distributions just as Arch did in 2011: https://www.archlinux.org/news...
Use something, anything else rather than this practically stone age software.
Except that most of them are obsolete, discarded in favor of more effective or more powerful tools, or never had another user. This includes most of CPAN for perl, most rubygems, most python modules, most maven packages, and perhaps 90% of github or sourceforge hosted projects. It's not possible to simply select an array of such tools and throw time or money at them. Some focus on ones that have a chance of working or a chance of usefulness is necessary.
The result now is a "bazaar" of varying quality tools which live up to Theodore Sturgeon's famous conversation:
From a new science fiction reader: "90% of science fiction is crap!"
From Theodore Sturgeon: "90% of *everything* is crap!"
The Census whitepaper details that and a lot of other stuff.
> Sometimes its just better to salvage the working stuff and jettison the rest, which is the approach LibreSSL takes.
This kind of work pays for a great deal of my salary. My favorites are the long term architects who built up complex systems themselves that *no one else in the world uses*, but refuse to move to the safer and better supported modern tools. Examples written by software architect I know include:
RCCS - (an RCS based shared repository source control tool, replaced by CVS even before it was written)
Tuttle - (system config tool, replaced by cfengine and puppet even before it was written)
ypmake - (perl based replacement for GNU make, written by someone who loved perl and couldn't be bothered to learn shell)
And oh, there's my favorite reasons for why such folks won't review their code with me.
The code is the documentation. (This was popular over at the FSF in its early days.)
The Wiki blew up last time I used it, so I refuse to use it.
Schedule a meeting! (and then refuse to show up five meetings in a row)
Cleaning up freeware and open source code is often thankless.
Did you read how the derived it? Patches mean less risk (for some bizarre reason) and systemd patches hourly!
What they did is getting a basic overview of which projects need most attention.
No, they have a lit of project that rate in their arbitrary definition of "risk." Have a nice and stable project that is not on the feature of the week train? High risk, because there are not enough updates. How about a hidden development svn, with a public mirror that makes all contributions look like they come from one person? Oh, that is very high risk... By their metrics, "Hello World" is the riskiest program on the planet.
Why companies are throwing support behind it rather than LibreSSL is beyond me.
Because it is what they use. Porting has a non-zero cost as well.
How is it bizarre than an active project which creates patches for found flaws is not seen at risk? The whole at-risk is about old software that no one looks at and only assumes is ok since it's old and trusted software.
How is it bizarre than an active project which creates patches for found flaws is not seen at risk? The whole at-risk is about old software that no one looks at and only assumes is ok since it's old and trusted software.
Last I read, 1 in 10 fixes creates a new bug. Most activity on new projects is new features, not the grunt work of fixing flaws. You can always get lots of people to write new code. It's hard to get people to do thorough testing.
I don't completely agree that project needs to be widely used to pose a high risk. There are certain applications which are not installed on many machines, but which security is extremely critical for the internet in whole. Two very good examples would be Quagga & BIRD. You can find one of them from very large number of core network deployments. They may not always be the ones that pass actual traffic, but they might be the ones that receive routing tables and pass them to other routers after modifying them as they allow you to modify them to fit your needs better.
It depends on how you define "wide usage". If wide usage is defined as total number of servers then even something like DNS might not make the cut.
On the other hand if it's defined as needed infrastructure where it either dominates its market or there is no other reasonable alternative then certain
programs only used for backbones or ISPs would definitely make the cut.
I am officially starting the Church Of SystemD, which will bring enlightenment to the masses.
Services praising The Holy SystemD will be performed at gunpoint, so stop making trouble with all those facts and shit and just get in line.
Just cruising through this digital world at 33 1/3 rpm...
Because a project patching bugs daily (that only a hand full of users are actually applying) is rated as more secure then a well tested and stable project that is not finding bugs and releasing patches...
Are they really at risk or just mature? after 20-30 years I don't see how tools like whois and bzip2 could really need that much development.
lose != loose
It "details" systemd? What the fuck are you talking about? I see one reference to systemd in that whitepaper, and it's in a section about rsyslog, so it really isn't even about systemd at all:
"Its" in that context is rsyslog, not systemd!
As far as I'm concerned, it didn't cover systemd at all. I don't know what the fuck you're talking about.
Why don't we try the open source route and have people adopt these at-risk core system utilities? Won't there be any interest if those are up for adoption? If we get 3-4 volunteers per tool we can for sure do something about this and get more people to contribute to those tools.
I would definitely be up for something like that.