The Only Linux Foundation CII Gold Rated Project Is a .. PHP Markdown Parser

https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

by reindeerer • 8 years ago

18 16 8 years ago

bestpractices.coreinfrastructure.org

thisacctforreal• 8 years ago

Looks like the Linux kernel would have a gold rating if kernel.org set X-Content-Type-Options to "nosniff".

https://bestpractices.coreinfrastructure.org/en/projects/34?...

gtirloni• 8 years ago

Whats the point being made?

This is more useful: https://github.com/coreinfrastructure/best-practices-badge

dwheeler6• 8 years ago

I am the technical lead of the CII best practices badge, so ask me anything!

I'm not sure what the point of the poster was. You can see the projects with "passing" or better here, and there are over 200: https://bestpractices.coreinfrastructure.org/en/projects?gte...

There are very few projects with gold, sure, but gold is a more recent badge level and it's pretty hard to get. In addition, we've been emphasizing helping projects get the "passing" badge, and we have so far spent less time encouraging projects to work on higher level badges (silver or gold). Most projects working on higher level badges tend to work on them slowly, instead of trying to get it all at once anyway.

I think a more telling chart is the steady increase in the number of participating projects: https://bestpractices.coreinfrastructure.org/en/project_stat...

If you are involved in an open source project, I would encourage you to get a badge. Go here for more: https://bestpractices.coreinfrastructure.org/

reindeerer2• 8 years ago

I'm not sure what the point of the poster was.

Certainly not knocking on the badge or the practices.

I just found it amusing that PHP often gets a bad rap, but then shows up at the top of the listed projects for objectively good development practices.

dwheeler6• 8 years ago

Ah! Thanks for clarifying that.

We intentionally created the badge criteria so that you could meet them regardless of the language you used. And if someone's doing the right things, then they should get a badge!

dwheeler6• 8 years ago

By the way, the title is wrong. The badging application itself also gets a gold badge. In addition, there are other projects that are close.

userbinator2• 8 years ago

...showing just how useful "best practices" actually are.

I associate that phrase with dogmatic cargo-cult "don't think just follow" and the horrible results thereof. Lots of self-proclaimed "experts" love to say "do X and Y and Z and you will be successful because these are best practices", but it's all a bunch of snake oil.

https://agilepainrelief.com/notesfromatooluser/2010/03/there...

http://www.satisfice.com/blog/archives/27

http://www.satisfice.com/presentations/nobest.pdf

"Best practices are best not practiced."

throwaway2048• 8 years ago

I see absolutely nothing dogmatic or cargo cult about the recommendations they make. They are completely sensible, and a decent guideline for improving the technical support infrastructure of a project.

What's wrong with that? Do you have any comparable list of actionable things that projects can do to improve their services?

escherplex• 8 years ago

That resonates. If living in a universe of one then personal best practices are whatever suit your fancy. But in this world apps must interact with a community of apps and be maintained within that context plus without suitable protocols inconsistent results will appear across apps. Some of Kaner, Bach and Pettichord work seems contrarian for its own sake. As in your ego is just as good as purported expert egos

dwheeler6• 8 years ago

You probably use every day at least one of the projects with a badge. That includes the Linux kernel, Kubernetes, Node.js, curl, GitLab, LibreOffice, and many others. See a short list here: https://bestpractices.coreinfrastructure.org/en

Or the current complete list here: https://bestpractices.coreinfrastructure.org/en/projects?gte...

As far as being not practiced, that's absurd. We worked to capture the practices already being used by successful open source software projects. Are you seriously arguing that projects should not use Version Control? Are you arguing that projects should not have automated tests? Are you arguing that projects should not have licenses? In short, have you even looked at the criteria?

Also, snake oil salesmen made all sorts of claims because they were going to earn money by selling you a product. Earning a badge requires $0, so the badging process is not a sham to earn money.

userbinator2• 8 years ago

You probably use every day at least one of the projects with a badge.

Yes, but it doesn't factor one bit in evaluating whether I use a project.

In short, have you even looked at the criteria?

Yes, and it doesn't matter --- whether or not a project does X is not necessarily an indicator of its success. You're essentially saying "all successful projects do X, so if you do X you'll be successful" --- where success is, in this case, earning a badge.

I've seen far too much software that happens to tick all the "best practices" boxes, yet is a horrific failure at doing what it needs to do.

Also, snake oil salesmen made all sorts of claims because they were going to earn money by selling you a product. Earning a badge requires $0, so the badging process is not a sham to earn money.

It's not free in terms of the time expense.

dwheeler6• 8 years ago

You can read an article I wrote about the badging project on LWN.net: "Core Infrastructure Initiative best-practices badge" https://lwn.net/Articles/690169/

Things have happened since then, but it's still a good overview.

otriv• 8 years ago

To be honest I don't find this completely surprising. PHP is widely used and the code can be just as clean as any other language.

exikyut• 8 years ago

I just found and read through the criteria list. It's mind-bogglingly exhaustive, but in a very good way, and an excellent catalyst for maintainable, secure software.

I'd regard it as universally applicable to any and all code.

This list gets you in the door: https://github.com/coreinfrastructure/best-practices-badge/b...

And this is the list that gets you a gold star rating: https://github.com/coreinfrastructure/best-practices-badge/b...

Prepare to have your eyes glaze over.

---

I had a go at summarizing the criteria. This is not an accurate reduction of the essence of the two lists; it comes close (I have no reason to misrepresent the criteria), but I've paraphrased here and there where I think it was editorially safe to do so (including slightly rearranging/renaming the major headings a little and swapping the ordering of points).

The following is NOT a substitute for reading the criteria. I wrote this to give a good idea of why you'd want to take the time to click the above links.

> The following is the criteria to get a _minimally_ passing score. <<

Website(s)

- <Must> succinctly describe the project with a minimum of domain-specific language or siloed knowledge

- <Must> explain how to obtain, provide feedback and contribute

- <Must> use HTTPS+TLS

Project

- <Must> use an OSS license (OSI, FSF, or liked by Debian or Fedora); <may> be dual-commercially-licensed

- <Must> provide basic documentation in 99% of circumstances

- <Must> use a URL-addressable, searchable discussion system for unilateral participation (IRC or mailinglists with URL-accessible logging is acceptable)

- <Should> use English

Source version control

- URL-addressable version control <must> be used

- System <must> track who changed what, and when

- <Must> list all interim releases, for accountability

- Unique version numbers <must> be used for all user-facing releases; commit IDs are listed as acceptable version "numbers", as is use of SemVer, and use of other version representations

- Release notes <must> accompany all releases

Bug reporting

- Project <must> provide bug reporting process; use of an issue tracker is recommended

- Project <must> at least respond to (if not fix) issues after 2-12 months, and <should> acknowledge more than half of submitted enhancement requests in the same timeframe

Vulnerability reporting

- Project <must> provide a vulnerability reporting mechanism; HTTPS or email (possibly with PGP) are suggested

- All reports submitted within the last 6 months <must> be responded to within 14 days

Building

- IF project must be built in order to function, automatic rebuild mechanism must be provided

- Automated OSS test suite <must> be used

- Tests for new functionality <must> be added to automated test suite

Code warnings

- Project <must> use compiler warnings, language strict/safe modes, or linting tools

Security

- Project <must> be built by at least one developer who knows how to design secure software (the 8 principles from Saltzer and Schroeder are noted)

- At least one developer <must> have domain knowledge of common vulnerability-introducing errors relevant to the software, and how to mitigate against them

- Project <must> use established and reviewed security algorithms/protocols

- Project <must> use keylengths that meet minimum NIST requirements through 2030 (certain keylengths are noted)

- Project <must not> use known-broken crypto

- Security mechanisms <should> use perfect forward secrecy

- Stored passwords <must> be iterated/key-stretched hashes with per-$user salt

- Keys and nonces must come from a cryptographically secure RNG

- Project delivery mechanism <must> be MITM-resilient (HTTPS and SSH+SCP are listed as acceptable)

- Checksums <must not> be delivered over HTTP

- Medium- to high-severity vulnerabilities <must> be fixed if they are public knowledge for more than 60 days

- Project <must not> leak security credentials (sample credentials are exempted)

Code analysis

- Project <must> use a static code analyser, if one exists for the given project language(s) and is OSS; it is <suggested> that the tool be configured/used to look for vulnerabilities, if possible; it is also <suggested> that code analysis be rerun every commit or at least daily

- Project <must> fix medium/high severity (CVSS 2.0 or higher) exploitable issues found by static analysis in a timely manner

- The use of a dynamic code analyzer to major production releases is <suggested>, if an OSS tool exists for the project language(s)

- If the software is written in C/C++ or another memory-unsafe language, it is <suggested> that a dynamic analyser (fuzzer, web application scanner) be used to look for things like buffer overflows/overwrites

- It is <suggested> that the project make heavy use of run-time assertions that are checked by dynamic analysis tools

The Only Linux Foundation CII Gold Rated Project Is a .. PHP Markdown Parser

Related Stories