Date   
Re: Support Grsecurity/PaX

Kevin P. Fleming (BLOOMBERG/ 731 LEX)
 

(sorry for top-posting, our message system doesn't believe anything else is possible)

The funding for the fuzzing project is intentionally short-to-medium-term, with two goals: helping to learn the 'state of the world' (which will feed into the census, and future support/funding decisions), and producing better and easier-to-apply fuzzing tools so that project teams can run them on their own software to identify flaws as early as possible. It's definitely not a long-term 'fuzz test the world' project.

The funding for Frama-C is for further development of the tool (and related tools), not funding to do static analysis of large bodies of open source software.

As a result, neither of these are suitable comparisons to the request for funding of grsecurity/PaX. Such a request would be more comparable to funding OpenSSL, ntpd, etc. Those are also not open-ended funding commitments, but are based on achieving improvements (in some cases, milestones) to continue funding. It's certainly possible that the SC would consider a funding proposal for grsecurity/PaX, but such a proposal would need to include reasonably well defined goals/milestones, and there's no question that the committee discussion would include the topic of the in-tree/out-of-tree status of these tools.

From: pageexec@... At: Aug 19 2015 17:56:13
To: Jason@..., dankohn@...
Cc: cii-census@..., cii-discuss@..., spender@...
Subject: Re: [cii-census] Support Grsecurity/PaX
On 19 Aug 2015 at 13:37, Dan Kohn wrote:

Hi Dan,

> On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:
> > Of course there are worthwhile
> > kernel projects that are not a part of mainline.
>
> One last question for you: could you name other such projects (not
> necessarily security-related). Nearly every other out-of-mainline
> project I'm aware of has eventually either merged or died out.

Let's hope you only had bad luck and that's why you aren't aware of
any of these ;)

http://lttng.org/download/
http://www.sysdig.org/wiki/how-to-install-sysdig-from-the-source-code/
http://open-mx.gforge.inria.fr/download/
http://knem.gforge.inria.fr/download/
http://download.savannah.gnu.org/releases/davfs2/
http://www.openafs.org/release/index.html
http://www.asterisk.org/downloads/dahdi
https://www.virtualbox.org/wiki/Downloads
https://www.jetico.com/linux/installation.html
http://zfsonlinux.org/
http://aufs.sourceforge.net/
http://cryptodev-linux.org/download.html
http://loop-aes.sourceforge.net/loop-AES/
https://www.rsbac.org/download
http://cdemu.org/about/vhba/
https://github.com/vmware/open-vm-tools
http://scst.sourceforge.net/downloads.html
http://sourceforge.net/projects/xtables-addons/files/Xtables-addons/

As for the requirement of mainlining grsec, it's not possible since
we know right off the start that some of the features and other changes
are not acceptable at all (say, all the x86 segmentation based code).

Second, for the potentially viable pieces this would be a multi-year
full time job. Is the CII willing to fund projects at that level? If not
we all would end up with lots of unfinished and partially broken features.

Third, you're actually wrong as to what is needed for mainline acceptance,
it's most definitely not enough to dump the code on them and let the
community figure it all out and take care of it. If anything, the exact
opposite is true, for any non-trivial amount of code there has to be a
pledge for long-term maintenance from the submitters (so regardless where
grsec stays, in-tree or out-of-tree, the maintenance burden would still
be ours for some years at least, with corresponding need of funding).

Fourth, you mentioned the potential futility of not funding grsec indefinitely.
It begs the question why it is then worth doing the same for the fuzzing
project or Frama-C. I hope noone at CII believes that a year or two of
fuzzing and static analysis will exterminate all bugs so what happens after
their funding runs out? Or are you suggesting that they can be funded
indefinitely but for some reason grsec could not be?

In any case, it is your money and decision at the end and we thank you
for your attention at least. However it is also clear that we have a
different understanding of what constitutes securing the core infrastructure.

cheers,
PaX Team

_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census

Re: Support Grsecurity/PaX

Shawn C
 

Hi Dan,

It'd be a tough work to break up the features of PaX/Grsec and push
them into upstream, separately. The fact is vanilla kernel community
don't care about mitigation. People who runs GNU/Linux servers for
security critical scenes has been suffering from vanilla kernel guys's
philosophy of A-bug-is-a-bug for years. Some brilliant developers
doesn't even treat "bypass methods" as a threat:

http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html
http://www.openwall.com/lists/oss-security/2014/12/08/3

IMOHO, PaX/Grsec is the only option we have for mission critical
infrastructure if we do want to continue using GNU/Linux.

On Wed, Aug 19, 2015 at 9:44 PM, Dan Kohn <dan@...> wrote:
Thanks for the comment. Has anything significant changed since 2009?
https://lwn.net/Articles/313621/

If members of the PAX team would like to apply for a grant to break up
their work and work with upstream to get it included in mainline
Linux, CII would be happy to consider it.

https://www.coreinfrastructure.org/contact
--
Dan Kohn <mailto:dan@...>
tel:+1-415-233-1000


On Wed, Aug 19, 2015 at 9:12 AM, Jason A. Donenfeld <Jason@...> wrote:
Dear Core Infrastructure Initiative:

I do consulting for several different security companies. The uniform advice
across the industry is: if you want to deploy Linux securely, be sure to be
using a Grsecurity/PaX kernel. This advice is given time after time in
reports authored by several security companies for whom I consult. And
companies who take their security seriously wind up using Grsecurity/PaX.
This isn't just security-scare-speak rattling the saber; this is pretty much
essential and true. As somebody who works day in day out developing exploits
and finding vulnerability, I can tell you that Grsecurity/PaX makes my work
considerably more difficult. The defenses Grsecurity/PaX offers are real,
and are useful. They're doing important work, and as a whole they're moving
everybody forward.

Simply put, anybody serious about security uses a Grsecurity/PaX kernel.

Yet, as far as I can see, the developers (CC'd) receive basically no
funding, and since the source they release is GPL, the thousands of
companies who deploy Grsecurity/PaX are not compelled to give any financial
support. As such, the financial situation of the developers is in nearly
constant peril, and this core Linux project lives under a consistent
existential threat.

Were it not for Grsecurity/PaX, I would probably not be using the Linux
kernel in my mission critical infrastructure, in favor of some flavor of BSD
that's copied Grsecurity/PaX's techniques. Or simply in favor of a smaller,
less performant, more minimal BSD kernel, that would be a big hassle, but
would have a smaller attack surface. However, since there is Grsecurity/PaX,
I feel a bit more comfortable deploying Linux. And I think many in the
security industry feel the same.

So, Core Infrastructure Initiative - please - consider supporting them. I'm
not affiliated with them in anyway, but in stumbling across CII, and
reviewing what CII is up to, it struck me that there's currently a glaring
omission in supported projects. Grsecurity/PaX ought to be at the top of the
list.


Thank you,

Jason Donenfeld

_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census
_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census
--
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn

Re: Support Grsecurity/PaX

PaX Team
 

On 19 Aug 2015 at 13:37, Dan Kohn wrote:

Hi Dan,

On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:
Of course there are worthwhile
kernel projects that are not a part of mainline.
One last question for you: could you name other such projects (not
necessarily security-related). Nearly every other out-of-mainline
project I'm aware of has eventually either merged or died out.
Let's hope you only had bad luck and that's why you aren't aware of
any of these ;)

http://lttng.org/download/
http://www.sysdig.org/wiki/how-to-install-sysdig-from-the-source-code/
http://open-mx.gforge.inria.fr/download/
http://knem.gforge.inria.fr/download/
http://download.savannah.gnu.org/releases/davfs2/
http://www.openafs.org/release/index.html
http://www.asterisk.org/downloads/dahdi
https://www.virtualbox.org/wiki/Downloads
https://www.jetico.com/linux/installation.html
http://zfsonlinux.org/
http://aufs.sourceforge.net/
http://cryptodev-linux.org/download.html
http://loop-aes.sourceforge.net/loop-AES/
https://www.rsbac.org/download
http://cdemu.org/about/vhba/
https://github.com/vmware/open-vm-tools
http://scst.sourceforge.net/downloads.html
http://sourceforge.net/projects/xtables-addons/files/Xtables-addons/

As for the requirement of mainlining grsec, it's not possible since
we know right off the start that some of the features and other changes
are not acceptable at all (say, all the x86 segmentation based code).

Second, for the potentially viable pieces this would be a multi-year
full time job. Is the CII willing to fund projects at that level? If not
we all would end up with lots of unfinished and partially broken features.

Third, you're actually wrong as to what is needed for mainline acceptance,
it's most definitely not enough to dump the code on them and let the
community figure it all out and take care of it. If anything, the exact
opposite is true, for any non-trivial amount of code there has to be a
pledge for long-term maintenance from the submitters (so regardless where
grsec stays, in-tree or out-of-tree, the maintenance burden would still
be ours for some years at least, with corresponding need of funding).

Fourth, you mentioned the potential futility of not funding grsec indefinitely.
It begs the question why it is then worth doing the same for the fuzzing
project or Frama-C. I hope noone at CII believes that a year or two of
fuzzing and static analysis will exterminate all bugs so what happens after
their funding runs out? Or are you suggesting that they can be funded
indefinitely but for some reason grsec could not be?

In any case, it is your money and decision at the end and we thank you
for your attention at least. However it is also clear that we have a
different understanding of what constitutes securing the core infrastructure.

cheers,
PaX Team

Re: Support Grsecurity/PaX

Dan Kohn
 

On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:
Of course there are worthwhile
kernel projects that are not a part of mainline.
One last question for you: could you name other such projects (not
necessarily security-related). Nearly every other out-of-mainline
project I'm aware of has eventually either merged or died out.
--
Dan Kohn <mailto:dankohn@...>
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000

Re: Support Grsecurity/PaX

Jason A. Donenfeld
 

On Wed, Aug 19, 2015 at 5:11 PM, Dan Kohn <dankohn@...> wrote:
Jason, I do see your points, and the Grsecurity team is welcome to
apply for funding whether they want to upstream their work as patches
or keep it out-of-mainline. I am pointing out that sustainability is a
major factor that the CII steering group evaluates, and that
mainlining the work appears to be a much more sustainable path.
Hopefully the Grsecurity/PaX developers are actually reading this
thread and do consider applying!

One last point, and then I'll fade away a little bit. There is a set
of projects that are core infrastructure and are worth funding. There
is a set of projects that should be mainlined. I think it's entirely
reasonable that while these sets might overlap at times, they won't
overlap all the time, and that's okay. Of course there are worthwhile
kernel projects that are not a part of mainline. And in this case, one
of those projects happens to be core infrastructure, and certainly
worthy of a CII grant.

I play jazz guitar; here's an analogy. Sometimes artists make pop
music, and this sells many albums, and everyone is happy. Othertimes
artists make jazz music, but nobody cares about jazz, so artists often
can't sustain themselves. There are a few artists who do very well
though -- say, Pat Metheny or Herbie Hancock. If your musical
direction fits with theirs, you might get lucky and they'll bring you
on tour (into the mainline!), and then you'll be set for life. But if
not, you'll have to struggle. Fortunately there are a huge amount of
foundations, institutions, conservatories, patrons, and so forth who
help fund talented upcoming jazz artists. Often times these artists
live grant-to-grant (shows don't pay well; cds are pirated). With the
help of these patrons, some jazz artists have a chance, and eventually
become the next big deal. Sometimes they don't become big, but having
their artistic voice in the scene remains an inspiration for many
other artists, and so these patrons have supported a good cause here
too. Now this analogy breaks down, as there are many other odd ways
for jazz musicians to make a living. But hopefully the goofy
comparison will demonstrate that there are indeed very legitimate
grounds for funding non-mainlined kernel code.

Okay, thanks for listening; I'll let others take over the discussion from here.

Re: Support Grsecurity/PaX

Dan Kohn
 

On Wed, Aug 19, 2015 at 10:59 AM, Jason A. Donenfeld <Jason@...> wrote:

That's a nearly reasonable objection, but I think it's a bit narrow of
a vision on how many open projects work. More generally, it's "how can
a small but essential open source project be supported?" One answer is
by merging with an already funded project, like the Linux kernel
itself, that already has plenty of commercial investment, with paid
developers.
Jason, I do see your points, and the Grsecurity team is welcome to
apply for funding whether they want to upstream their work as patches
or keep it out-of-mainline. I am pointing out that sustainability is a
major factor that the CII steering group evaluates, and that
mainlining the work appears to be a much more sustainable path.

Separately, I would encourage you (and them) to take a look at a
sister project to the CII census, which is our best practices program.
https://github.com/linuxfoundation/cii-best-practices-badge

One criteria we might add in the future is around mainlining code.
--
Dan Kohn <mailto:dankohn@...>
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000

Re: Support Grsecurity/PaX

Jason A. Donenfeld
 

On Wed, Aug 19, 2015 at 4:43 PM, Dan Kohn <dankohn@...> wrote:
Jason, if CII funded Grsecurity/PaX for a year or two, it would keep
the project going, but then what?
That's a nearly reasonable objection, but I think it's a bit narrow of
a vision on how many open projects work. More generally, it's "how can
a small but essential open source project be supported?" One answer is
by merging with an already funded project, like the Linux kernel
itself, that already has plenty of commercial investment, with paid
developers. Another, more accessible, answer is -- by receiving
funding when it can, using that funding to improve the project, and
have those improvements result in more interest, and therefore more
funding and grants down the line. It appears that many projects work
this way. For example, OpenBSD seems to be supported by generous
donations and grants (one of which has come from the CII, IIRC). The
longer these projects go, the more likely funding from various places
is to pour in. It seems that having CII fund Grsecurity/PaX for a year
or two would indeed result in increased momentum, more interest, and
therefore a steady stream of funding and support from elsewhere going
forward. This, anyway, is the route that most smaller open source
projects take, that do not directly have developers who are paid by
commercial entities. And on top of this, there's the obvious point: a
year or two of funded Grsecurity/PaX work would result in research and
practical security solutions that would be a massive benefit to all. I
suspect there are additional counter arguments as well that I am
missing (others can chime in?), because were it the case that it's not
worthwhile to fund something for a year or two as you described, many
projects that do now receive funding would become woefully ineligible.

Re: Support Grsecurity/PaX

Dan Kohn
 

On Wed, Aug 19, 2015 at 4:15 PM, Dan Kohn <dankohn@...> wrote:
CII follows the philosophy of Linux development that long-term,
out-of-mainline patches are problematic because of the maintenance
issues and lack of peer-review.
On Wed, Aug 19, 2015 at 10:21 AM, Jason A. Donenfeld <Jason@...> wrote:

Please do try to consider Grsecurity/PaX as not "just another out of tree
patchset" but rather a mission critical project that serves a real world
benefit in addition to pushing the bounds with the research that goes into
it. No matter the debate on the various kernel development practices and
philosophies, nobody in the security world disagrees with the fact that
keeping Grsecurity/PaX around as a healthy project is very critical.
Regardless of the mainline discussion, Grsecurity/PaX, as it exists today,
*is* *core* *infrastructure*.
Jason, if CII funded Grsecurity/PaX for a year or two, it would keep
the project going, but then what? It is unlikely that CII could fund
the project indefinitely, so it would remain an unhealthy project. By
contrast, if we funded mainlining the most important parts of
Grsecurity, then the thousands of companies and individuals that
develop Linux would take responsibility for maintaining it (and
improving it) indefinitely. The parts that didn't get accepted could
still be maintained out-of-mainline by whatever companies or
individuals chose to do so.
--
Dan Kohn <mailto:dankohn@...>
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000

Re: Support Grsecurity/PaX

Jason A. Donenfeld
 



On Wed, Aug 19, 2015 at 4:15 PM, Dan Kohn <dankohn@...> wrote:
CII follows the philosophy of Linux development that long-term,
out-of-mainline patches are problematic because of the maintenance
issues and lack of peer-review. 

Please do try to consider Grsecurity/PaX as not "just another out of tree patchset" but rather a mission critical project that serves a real world benefit in addition to pushing the bounds with the research that goes into it. No matter the debate on the various kernel development practices and philosophies, nobody in the security world disagrees with the fact that keeping Grsecurity/PaX around as a healthy project is very critical. Regardless of the mainline discussion, Grsecurity/PaX, as it exists today, *is* *core* *infrastructure*.

Re: Support Grsecurity/PaX

Dan Kohn
 

On Wed, Aug 19, 2015 at 10:03 AM, Jason A. Donenfeld <Jason@...> wrote:

It's important to note, though, that it shouldn't be considered relevant
whether or not their work is mainlined. This is an important core project
that's extremely widely used by everybody who cares about security. Ensuring
the work goes on is of *critical* importance. Not only that, but work done
in Grsecurity/PaX _does_ make its way back to mainline bit by bit in the
form of individual patches that are a rework of features pioneered by
Grsecurity/PaX. In other words, mainlined or not, keeping Grsecurity/PaX
around with healthy funding is of the utmost importance for the Linux
ecosystem at large. We need them. (And I believe they very likely need you,
CII.)
CII follows the philosophy of Linux development that long-term,
out-of-mainline patches are problematic because of the maintenance
issues and lack of peer-review. Of course, the Grsecurity/PaX team is
welcome to continue as they have been, and the GPL allows them to
charge for consulting services.

But the most likely scenario for a CII grant would be to facilitate
inclusion into mainline.
--
Dan Kohn <mailto:dankohn@...>
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000

Re: Support Grsecurity/PaX

Jason A. Donenfeld
 

I believe there have been significant changes since 2009. I'll let the Grsecurity/PaX developers chime in on this, I guess.

It's important to note, though, that it shouldn't be considered relevant whether or not their work is mainlined. This is an important core project that's extremely widely used by everybody who cares about security. Ensuring the work goes on is of *critical* importance. Not only that, but work done in Grsecurity/PaX _does_ make its way back to mainline bit by bit in the form of individual patches that are a rework of features pioneered by Grsecurity/PaX. In other words, mainlined or not, keeping Grsecurity/PaX around with healthy funding is of the utmost importance for the Linux ecosystem at large. We need them. (And I believe they very likely need you, CII.)

Re: Support Grsecurity/PaX

Dan Kohn <dan@...>
 

Thanks for the comment. Has anything significant changed since 2009?
https://lwn.net/Articles/313621/

If members of the PAX team would like to apply for a grant to break up
their work and work with upstream to get it included in mainline
Linux, CII would be happy to consider it.

https://www.coreinfrastructure.org/contact
--
Dan Kohn <mailto:dan@...>
tel:+1-415-233-1000

On Wed, Aug 19, 2015 at 9:12 AM, Jason A. Donenfeld <Jason@...> wrote:
Dear Core Infrastructure Initiative:

I do consulting for several different security companies. The uniform advice
across the industry is: if you want to deploy Linux securely, be sure to be
using a Grsecurity/PaX kernel. This advice is given time after time in
reports authored by several security companies for whom I consult. And
companies who take their security seriously wind up using Grsecurity/PaX.
This isn't just security-scare-speak rattling the saber; this is pretty much
essential and true. As somebody who works day in day out developing exploits
and finding vulnerability, I can tell you that Grsecurity/PaX makes my work
considerably more difficult. The defenses Grsecurity/PaX offers are real,
and are useful. They're doing important work, and as a whole they're moving
everybody forward.

Simply put, anybody serious about security uses a Grsecurity/PaX kernel.

Yet, as far as I can see, the developers (CC'd) receive basically no
funding, and since the source they release is GPL, the thousands of
companies who deploy Grsecurity/PaX are not compelled to give any financial
support. As such, the financial situation of the developers is in nearly
constant peril, and this core Linux project lives under a consistent
existential threat.

Were it not for Grsecurity/PaX, I would probably not be using the Linux
kernel in my mission critical infrastructure, in favor of some flavor of BSD
that's copied Grsecurity/PaX's techniques. Or simply in favor of a smaller,
less performant, more minimal BSD kernel, that would be a big hassle, but
would have a smaller attack surface. However, since there is Grsecurity/PaX,
I feel a bit more comfortable deploying Linux. And I think many in the
security industry feel the same.

So, Core Infrastructure Initiative - please - consider supporting them. I'm
not affiliated with them in anyway, but in stumbling across CII, and
reviewing what CII is up to, it struck me that there's currently a glaring
omission in supported projects. Grsecurity/PaX ought to be at the top of the
list.


Thank you,

Jason Donenfeld

_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census

Support Grsecurity/PaX

Jason A. Donenfeld
 

Dear Core Infrastructure Initiative:

I do consulting for several different security companies. The uniform advice across the industry is: if you want to deploy Linux securely, be sure to be using a Grsecurity/PaX kernel. This advice is given time after time in reports authored by several security companies for whom I consult. And companies who take their security seriously wind up using Grsecurity/PaX. This isn't just security-scare-speak rattling the saber; this is pretty much essential and true. As somebody who works day in day out developing exploits and finding vulnerability, I can tell you that Grsecurity/PaX makes my work considerably more difficult. The defenses Grsecurity/PaX offers are real, and are useful. They're doing important work, and as a whole they're moving everybody forward.

Simply put, anybody serious about security uses a Grsecurity/PaX kernel.

Yet, as far as I can see, the developers (CC'd) receive basically no funding, and since the source they release is GPL, the thousands of companies who deploy Grsecurity/PaX are not compelled to give any financial support. As such, the financial situation of the developers is in nearly constant peril, and this core Linux project lives under a consistent existential threat.

Were it not for Grsecurity/PaX, I would probably not be using the Linux kernel in my mission critical infrastructure, in favor of some flavor of BSD that's copied Grsecurity/PaX's techniques. Or simply in favor of a smaller, less performant, more minimal BSD kernel, that would be a big hassle, but would have a smaller attack surface. However, since there is Grsecurity/PaX, I feel a bit more comfortable deploying Linux. And I think many in the security industry feel the same.

So, Core Infrastructure Initiative - please - consider supporting them. I'm not affiliated with them in anyway, but in stumbling across CII, and reviewing what CII is up to, it struck me that there's currently a glaring omission in supported projects. Grsecurity/PaX ought to be at the top of the list.


Thank you,

Jason Donenfeld

Let's update the master branch due to accepting issue #21 (popularity)

David A. Wheeler
 

We accepted issue#21 in the "develop" branch, which changes the scoring. See here for why and more detail:
https://github.com/linuxfoundation/cii-census/issues/21

We'd like to push this branch to master around Monday; any objections? Once that's updated, we should update the Linux Foundation page about it, but I think we should change the master branch first :-).

--- David A. Wheeler

networking analysis of Linux applications

Miika Komu <mkomu@...>
 

FYI,

I read about the Linux foundations's core infrastructure census project. Related to this, we analyzed networking related issues in Linux applications a few years back in university:

https://www.kernel.org/doc/ols/2012/ols2012-komu.pdf

The next step would have been to automatize scanning of the software in the repositories of distributions. We're not working actively anymore on this, but the analysis source code is still available if somebody is interested.

P.S. I am not actively following this list, so please contact us directly.

Re: Minor update (version 1.1.0) in "develop" branch ready to go?

Kevin P. Fleming (BLOOMBERG/ 731 LEX)
 

I've been lurking and watching the pull requests, and this set of updates certainly gets my vote, for what that's worth.

From: dwheeler@... At: Jul 27 2015 16:18:56
To: cii-census@...
Subject: Re:[cii-census] Minor update (version 1.1.0) in "develop" branch ready to go?

Sam and I have a minor update of the cii-census queued up in the "develop" branch.  Below is a draft ChangeLog.

 

I'd like to release the develop branch this Wednesday as the new "master" branch.  I don't think the changes are controversial, but I'd like to hear if others agree :-).  It has a number of smaller improvements, a bugfix, and adds a number of projects.

 

--- David A. Wheeler

 

 

 

= DRAFT CHANGELOG =

 

2015-11-15   Version 1.1.0

 

* Issue #29: Included breakdown of risk index score into the result

* Added original cached data from Openhub and Debian,

  put in original_cache folder

* Included latest cached data and results put in latest_cache folder

* Added projects suggested by pull requests (fail2ban, glib-networking,

  openvpn, clamav, dnsmasq, encfs, ffmpeg,owncloud, qemu, rsync, samba,

  virt-manager, git, subversion, mercurial, bzr, parted, vlc)

* Fixed string and integer comparison bugs for CVE and 12-month

  contributor counts

* Issue #22: get language and role for each project from

  apt_cache_dumpavail.txt, not through web scraping

* Issue #28: only the 'worst' score is obtained from exposure values,

  making the code input processing more robust

* General Code clean up

* Added script to load results.csv into a SQLite database

  (thanks to Florian Weimer)

 

_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census

Minor update (version 1.1.0) in "develop" branch ready to go?

David A. Wheeler
 

Sam and I have a minor update of the cii-census queued up in the "develop" branch.  Below is a draft ChangeLog.

 

I'd like to release the develop branch this Wednesday as the new "master" branch.  I don't think the changes are controversial, but I'd like to hear if others agree :-).  It has a number of smaller improvements, a bugfix, and adds a number of projects.

 

--- David A. Wheeler

 

 

 

= DRAFT CHANGELOG =

 

2015-11-15   Version 1.1.0

 

* Issue #29: Included breakdown of risk index score into the result

* Added original cached data from Openhub and Debian,

  put in original_cache folder

* Included latest cached data and results put in latest_cache folder

* Added projects suggested by pull requests (fail2ban, glib-networking,

  openvpn, clamav, dnsmasq, encfs, ffmpeg,owncloud, qemu, rsync, samba,

  virt-manager, git, subversion, mercurial, bzr, parted, vlc)

* Fixed string and integer comparison bugs for CVE and 12-month

  contributor counts

* Issue #22: get language and role for each project from

  apt_cache_dumpavail.txt, not through web scraping

* Issue #28: only the 'worst' score is obtained from exposure values,

  making the code input processing more robust

* General Code clean up

* Added script to load results.csv into a SQLite database

  (thanks to Florian Weimer)

 

You may be interested in this list of basic libraries I needed for my program

Steven Stewart-Gallus
 

Hello,

I found the paper about possibly vulnerable and critical software very
informative. The paper mostly focused on core, web and development software.
However, I think the full list of dependencies at
https://gitlab.com/linted/linted/blob/master/docs/platforms.h that my own
minimal personal game I'm working on may be interesting. The two key insights I
would take away from my list of dependencies is that in order to put on the
screen a simple 3D model one needs a huge rat nest of dependencies (some of
which don't seem well supported) and that small shims such as libcap for little
known functional that is exposed by the kernel and not by GLibc may not be well
maintained. I think there was talk about creating a libsyscall or something for
centralizing these shims a while ago but I don't think that got off the ground.
You may also find the raw build dependencies at
https://gitlab.com/linted/linted/blob/master/scripts/builddeps interesting.
Also, many of the dependencies read or write file formats (such as s2tc, zlib,
LLVM, libexpat and elfutils) as noted as potentially vulnerable stuff in the
paper. XCB also does protocol handling. LLVM is also interesting because it is
both used in compilers and jitters.

Thank you,
Steven Stewart-Gallus

Re: Trinity fuzzer

Kevin P. Fleming (BLOOMBERG/ 731 LEX)
 

Thanks for bringing this to our attention. It's been forwarded to the CII Steering Committee for discussion.

From: pabs3@... At: Jul 13 2015 13:43:19
To: cii-census@...
Subject: Re:[cii-census] Trinity fuzzer

Hi,

The Trinity fuzzer is essential to ensuring the security and
reliability of the Linux kernel. The author of it has just quit working
on it. It would be great if LF could repair the damage done by the
discontinuation of this project.

http://codemonkey.org.uk/2015/07/12/future-trinity/

--
bye,
pabs

http://bonedaddy.net/pabs3/

----------------------------

_______________________________________________
cii-census mailing list
cii-census@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-census

Trinity fuzzer

Paul Wise <pabs3@...>
 

Hi,

The Trinity fuzzer is essential to ensuring the security and
reliability of the Linux kernel. The author of it has just quit working
on it. It would be great if LF could repair the damage done by the
discontinuation of this project.

http://codemonkey.org.uk/2015/07/12/future-trinity/

--
bye,
pabs

http://bonedaddy.net/pabs3/