Linux Foundation's Census Project Ranks Open Source Software At Risk 47
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.
Re: (Score:1)
Re: (Score:1)
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.
Re:Why is systemd missing from this list? (Score:4, Interesting)
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
Re:Stop performing studies (Score:4, Interesting)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:1)
Mostly it will be that OpenSSL has a larger encryption library, that is available for general use, and thus more useful.
Re: (Score:2, Interesting)
> 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
Re: (Score:3)
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.
Excellent idea (Score:4, Interesting)
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.
Re: (Score:3)
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.
Their rating system actually encourages this. If you have tight controls on commits, like perhaps 1 or two people who review code and actually make the commits, you are "at risk." So go ahead and give that NSA guy commit access...
Yeah (Score:2)
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 go
Re: (Score:3)
I was just noticing the other day that a number of emacs lisp packages I use on a regular basis hadn't had any development work in 5-10 years.
If it works, why change it? The SmallWall project was immune to all of the SSL bugs in the last year because we use an old version that does not have these new and buggy features... Of course, this rating system would ding us for that... :)
Re: (Score:2)
One of the problems the software world faces is when is something 'done'.
Suppose and application was carefully designed and written 5 years ago and was free of problems like buffer overflows, logic errors, bad assumptions about input domain, bad assumptions about scale. If these things were true 5 years ago why would they be less true today? The questions than becomes does this application still meet the need today?
Software isn't like a house or machine. It does not require maintenance unless a problem
NTP needs the most love... (Score:2)
There's far too much software out there that depends on having clocks close to in sync.
Re: (Score:2)
The freeware ntpd at http://www.ntp.org/downloads.h... [ntp.org] was extremely stable code. It's greatest problems have been with subtle configuration issues, not with the old daemon itself. Unfortunately, the service is now merged into systemd itself, which means that support for it from that large part of the Linux world will no longer apply to any other operating system.
The main codeline at http://www.eecis.udel.edu/~ntp... [udel.edu] shows that it is in active development, mostly to support new operating systems and hardwar
Re: (Score:2)
Re: (Score:1)
Guys. Just use OpenNTPD.
It's actively developed, and it doesn't have any of the bloat that is in the official ntpd. And it syncs clocks!
Brought to you by the OpenBSD project. Known for writing secure software.
Re: (Score:2)
Or chrony [tuxfamily.org], which I just switched all my machines to.
tcpd top of the list - what a shock! (Score:1)
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... [archlinux.org]
Use something, anything else rather than this practically stone age software.
Re: (Score:2)
Seems to be the current "best practice" and I hate it.
#1 (Score:1, Troll)
Re: (Score:2)
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.
That's It.... (Score:1)
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.
at risk or mature? (Score:2)
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.
Adopt a Linux System Utility (Score:1)
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.