6 ms·

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

18 points by reindeerer 8y ago

deleted 8y ago
[deleted]
thisacctforreal 8y 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?criteria_level=2#security https://bestpractices.coreinfrastructure.org/en/projects/34?...
gtirloni 8y ago
Whats the point being made? This is more useful: https://github.com/coreinfrastructure/best-practices-badge https://github.com/coreinfrastructure/best-practices-badge
dwheeler 8y 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?gteq=100 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_stats 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/ https://bestpractices.coreinfrastructure.org/
- reindeerer 8y 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.
  - dwheeler 8y 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!
dwheeler 8y 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.
userbinator 8y 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-are-no-best-practices.html https://agilepainrelief.com/notesfromatooluser/2010/03/there... http://www.satisfice.com/blog/archives/27 http://www.satisfice.com/blog/archives/27 http://www.satisfice.com/presentations/nobest.pdf http://www.satisfice.com/presentations/nobest.pdf "Best practices are best not practiced."
- throwaway2048 8y 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 8y 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
- dwheeler 8y 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 https://bestpractices.coreinfrastructure.org/en Or the current complete list here: https://bestpractices.coreinfrastructure.org/en/projects?gteq=100 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.
dwheeler 8y 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/ https://lwn.net/Articles/690169/ Things have happened since then, but it's still a good overview.
otriv 8y 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 8y 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/blob/master/doc/criteria.md 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/blob/master/doc/other.md 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

18 points by reindeerer 8y ago

deleted 8y ago

[deleted]

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?criteria_level=2#security https://bestpractices.coreinfrastructure.org/en/projects/34?...

gtirloni 8y ago

Whats the point being made? This is more useful: https://github.com/coreinfrastructure/best-practices-badge https://github.com/coreinfrastructure/best-practices-badge

dwheeler 8y 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?gteq=100 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_stats 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/ https://bestpractices.coreinfrastructure.org/

reindeerer 8y 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.
- dwheeler 8y 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!

dwheeler 8y 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.

userbinator 8y 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-are-no-best-practices.html https://agilepainrelief.com/notesfromatooluser/2010/03/there... http://www.satisfice.com/blog/archives/27 http://www.satisfice.com/blog/archives/27 http://www.satisfice.com/presentations/nobest.pdf http://www.satisfice.com/presentations/nobest.pdf "Best practices are best not practiced."

throwaway2048 8y 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 8y 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
dwheeler 8y 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 https://bestpractices.coreinfrastructure.org/en Or the current complete list here: https://bestpractices.coreinfrastructure.org/en/projects?gteq=100 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.

dwheeler 8y 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/ https://lwn.net/Articles/690169/ Things have happened since then, but it's still a good overview.

otriv 8y 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 8y 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/blob/master/doc/criteria.md 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/blob/master/doc/other.md 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