Date   
Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-01.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2018-12-302019-01-30
Total Projects20412091
Projects 25%+770789
Projects 50%+630645
Projects 75%+497511
Projects passing240249

Here are the projects that first achieved a passing badge in 2019-01:

  1. landscapeapp at 2019-01-03 18:58:37 UTC
  2. BioCor at 2019-01-12 15:24:23 UTC
  3. svg-autocrop at 2019-01-13 00:36:53 UTC
  4. ticketguardian-python at 2019-01-15 23:36:27 UTC
  5. skipper at 2019-01-16 13:36:35 UTC
  6. PENTESTON at 2019-01-17 13:00:05 UTC
  7. TensorFlow at 2019-01-18 23:32:59 UTC
  8. SmartCar Shield at 2019-01-19 16:05:54 UTC
  9. busdater at 2019-01-20 06:44:03 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

FYI: Rails upgrade for BadgeApp

David A. Wheeler
 

FYI: In our effort to keep the Best Practices Badge website running smoothly, we just upgraded from the Rails 5.1 to Rails 5.2 (specifically version 5.2.2).

 

If you notice a problem, please let us know!!

 

Rail 6 will come out April 30 of 2019; at that time, Rails 5.1 will stop receiving guaranteed security updates.  So we really needed to upgrade at some point, and it’d be safer to do that now.  This required a few subtle changes, which were resolved.

 

Everything seems to be fine (so far) on the upgraded system.  We have a decent automated test suite; the test suite did detect some problems with a “naïve” upgrade, but we corrected those problems before we even merged it into our initial-test tier (“master”).  If desperate we can revert the running version & switch to a backup database, but hopefully it will never come to THAT J.

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-02.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-01-302019-02-27
Total Projects20912170
Projects 25%+789811
Projects 50%+645664
Projects 75%+511527
Projects passing249263

Here are the projects that first achieved a passing badge in 2019-02:

  1. newspaper-server at 2019-02-03 15:34:04 UTC
  2. restgoose at 2019-02-05 15:57:57 UTC
  3. Awesome Framework at 2019-02-05 16:03:52 UTC
  4. trickster at 2019-02-12 02:05:14 UTC
  5. Jastacry at 2019-02-12 14:07:53 UTC
  6. jtools at 2019-02-16 02:58:49 UTC
  7. BlurWal at 2019-02-19 21:30:01 UTC
  8. TransmogrifAI at 2019-02-19 22:35:23 UTC
  9. Gitano at 2019-02-20 07:57:44 UTC
  10. NetSurf Browser at 2019-02-20 08:47:57 UTC
  11. js-data-structure at 2019-02-22 03:33:34 UTC
  12. drace at 2019-02-26 10:12:49 UTC
  13. LinuxTV at 2019-02-27 15:18:02 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

CII Badge project - some recent URLs that discuss it

David A. Wheeler
 

If you’re curious about the current status of the badge project, I have a useful summary in the presentation “Core Infrastructure Initiative (CII) Best Practices Badge in 2019” (2019-03-14) - https://events.linuxfoundation.org/wp-content/uploads/2018/07/cii-bp-badge-2019-03.pdf . This was a presentation at the Linux Foundation's Open Source Leadership Summit 2019 in Half Moon Bay, CA.

 

The badging project was also mentioned in some other recent places:

* A Sample Security Assurance Case Pattern (2018) - https://www.ida.org/idamedia/Corporate/Files/Publications/IDA_Documents/ITSD/2019/P-9278.pdf – this discusses how to create secure software by applying an assurance case, and uses the Badge Application's assurance case as an example.

* FLOSS Weekly 522: Railroader - https://twit.tv/shows/floss-weekly/episodes/522) primarily discussed the [Railroader](https://railroader.org) project, but it also touched on the continued progress of the CII Best Practices badge.

 

If you know of other places where the badging project is discussed, let us know, and/or update the Wiki page here:

https://github.com/coreinfrastructure/best-practices-badge/wiki/Publicity

 

Thanks!!

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-03.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-02-272019-03-30
Total Projects21702216
Projects 25%+811831
Projects 50%+664683
Projects 75%+527540
Projects passing263273

Here are the projects that first achieved a passing badge in 2019-03:

  1. scripts-common at 2019-03-03 01:10:16 UTC
  2. Yocto Project at 2019-03-06 18:29:56 UTC
  3. SPDX Tools at 2019-03-10 01:22:25 UTC
  4. prosody at 2019-03-14 21:19:56 UTC
  5. readme-inspector at 2019-03-15 21:23:57 UTC
  6. TiKV at 2019-03-19 18:02:58 UTC
  7. go-github at 2019-03-21 18:49:11 UTC
  8. Hyperledger Indy at 2019-03-21 20:26:32 UTC
  9. hexo-theme-next at 2019-03-23 16:45:49 UTC
  10. ONAP DCAE at 2019-03-26 20:19:47 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-03-302019-04-29
Total Projects22162296
Projects 25%+831862
Projects 50%+683709
Projects 75%+540565
Projects passing273285

Here are the projects that first achieved a passing badge in 2019-04:

  1. tpm2-tss at 2019-04-01 19:29:20 UTC
  2. vinyldns at 2019-04-03 02:01:25 UTC
  3. TySug at 2019-04-08 06:42:58 UTC
  4. cryptor at 2019-04-13 20:35:35 UTC
  5. PRoot at 2019-04-18 01:35:35 UTC
  6. OpenSwitch (OPX) at 2019-04-19 15:53:14 UTC
  7. java-html-sanitizer at 2019-04-20 19:43:45 UTC
  8. ONAP External API at 2019-04-23 08:58:41 UTC
  9. react-kentico-blog at 2019-04-25 14:46:02 UTC
  10. ONAP ESR (External System Register) at 2019-04-26 15:10:34 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-05.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-04-292019-05-30
Total Projects22962381
Projects 25%+862902
Projects 50%+709743
Projects 75%+565594
Projects passing285309

Here are the projects that first achieved a passing badge in 2019-05:

  1. Predator: an open source performance testing platform for APIs at 2019-05-06 09:30:58 UTC
  2. dice at 2019-05-08 15:44:52 UTC
  3. OpenImageIO at 2019-05-08 22:19:14 UTC
  4. ONAP AAI UI (sparky-fe) at 2019-05-09 13:14:21 UTC
  5. ONAP SDNC (SDN Controller) at 2019-05-09 18:40:52 UTC
  6. railroader at 2019-05-11 15:50:27 UTC
  7. Orekit at 2019-05-13 11:05:04 UTC
  8. vvp at 2019-05-13 21:44:17 UTC
  9. CLAMP (Closed Loop Automation Management Platform) at 2019-05-14 13:44:42 UTC
  10. pki-lint at 2019-05-14 20:34:09 UTC
  11. ONAP Champ at 2019-05-15 13:35:49 UTC
  12. bug at 2019-05-16 19:17:03 UTC
  13. kuberhealthy at 2019-05-16 20:30:19 UTC
  14. A review helper script for openQA at 2019-05-20 11:23:24 UTC
  15. ONAP Gizmo at 2019-05-20 15:39:08 UTC
  16. IN COMMON at 2019-05-21 11:26:50 UTC
  17. ONAP Virtual Infrastructure Deployment (VID) at 2019-05-22 12:32:34 UTC
  18. snakecase at 2019-05-25 14:38:17 UTC
  19. Lychee-Laravel at 2019-05-28 12:58:22 UTC
  20. ONAP SDC (Service Design and Creation) at 2019-05-29 11:41:22 UTC
  21. usecase-ui at 2019-05-30 12:52:36 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

FYI: BadgeApp & omniauth vulnerability CVE-2015-9284 resolved by third-party fix

David A. Wheeler
 

All, FYI.

 

One component we use (omniauth) has a publicly-known vulnerability (CVE-2015-9284) that is still not fixed.  To deal with this, we’ve taken unusual steps to eliminate the vulnerability’s effect in the BadgeApp.  Below are the details, in case you want to know more.

 

--- David A. Wheeler

 

=====================================================

 

As you know, the best practices badge is implemented by the “BadgeApp”.  Various mechanisms warn us when there’s a publicly-known vulnerability in a component used by the BadgeApp (directly or indirectly), and we normally quickly update, test, and ship the update.

 

Unfortunately, we’ve had a complication.  One component we use is “omniauth”, which has vulnerability CVE-2015-9284.  Unfortunately, while they continue to discuss it, they have *NOT* fixed it, and this vulnerability has become publicly known.  What’s more, as you can tell by the CVE number this was reported back in *2015*.  I think it’s embarrassing that it’s still not fixed.

 

My patience is exhausted.  This is not a trivial exploit to pull off, but it’s a dangerous one: it allows an attacker to take over another’s account.  And since the omniauth developers have failed to fix it for 4 years, I don’t have high hopes that they will fix it soon.  There is a third-party fix named omniauth-rails_csrf_protection.  I’m always leary of third-party fixes, but I think it’s our best option.  I reviewed its code & it appears okay.  I’ve incorporated the third-party fix by locking our download to the commit cryptographic hash that I reviewed; the hash lock counters tricks like “the RubyGems version is different from the one on GitHub” and “we silently upgraded/switched to a malicious version.”  So among our options I think this is the best one, and I think I’ve mitigated the biggest risks of this option.  We may look more seriously at removing omniauth in the longer term (since security components should be responsive to security issues), but for the moment I want to immediately resolve the *known* problem.

 

For more detail see:

 

https://nvd.nist.gov/vuln/detail/CVE-2015-9284

https://github.com/cookpad/omniauth-rails_csrf_protection

https://github.com/coreinfrastructure/best-practices-badge/pull/1298

 

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-06.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-05-302019-06-29
Total Projects23812441
Projects 25%+902927
Projects 50%+743765
Projects 75%+594612
Projects passing309316

Here are the projects that first achieved a passing badge in 2019-06:

  1. gomplate at 2019-06-01 13:24:49 UTC
  2. imageproxy at 2019-06-10 00:58:01 UTC
  3. MapMate at 2019-06-12 14:14:31 UTC
  4. HttpMate at 2019-06-12 17:46:07 UTC
  5. NACHO at 2019-06-18 11:46:42 UTC
  6. Gwion at 2019-06-20 16:43:00 UTC
  7. Yarhl at 2019-06-22 12:50:00 UTC
  8. kubeone at 2019-06-27 13:05:06 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2019-07.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2019-06-292019-07-30
Total Projects24412516
Projects 25%+927961
Projects 50%+765795
Projects 75%+612639
Projects passing316328

Here are the projects that first achieved a passing badge in 2019-07:

  1. openvdb at 2019-07-06 00:54:01 UTC
  2. cyborg at 2019-07-08 21:51:54 UTC
  3. Passbolt at 2019-07-09 16:29:39 UTC
  4. uber-poet at 2019-07-15 23:10:16 UTC
  5. mockolo at 2019-07-16 21:22:37 UTC
  6. Lite Byte Capsule at 2019-07-21 14:34:51 UTC
  7. classicdb_bot at 2019-07-23 22:30:03 UTC
  8. OpenColorIO at 2019-07-24 07:41:52 UTC
  9. volcano at 2019-07-26 12:49:16 UTC
  10. dockerserver at 2019-07-27 15:22:56 UTC
  11. kubeedge at 2019-07-29 03:39:03 UTC
  12. libtorrent at 2019-07-30 06:32:38 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

CII Best Practices badge application not affected by EU GDPR "like" button issues

David A. Wheeler
 

The Court of Justice of the European Union (ECJ) has ruled that online websites that embed a Facebook "Like" button are responsible for the data they send to Facebook and are liable for the same penalties under EU data protection laws. There are many reports about this, e.g.:
https://www.theregister.co.uk/2019/07/29/eu_gdpr_facebook_like_button/
https://techcrunch.com/2019/07/29/europes-top-court-sharpens-guidance-for-sites-using-leaky-social-plug-ins/
https://www.cnet.com/news/websites-using-facebook-like-button-liable-for-data-europes-top-court-decides/
https://www.bloomberg.com/news/articles/2019-07-29/facebook-s-like-button-makes-websites-liable-top-eu-court-rules
https://www.theverge.com/2019/7/29/8934924/facebook-like-buttons-court-justice-eu-ruling-privacy-data-protection-tracking
https://www.zdnet.com/article/eu-court-of-justice-ruling-may-spell-the-death-of-social-like-and-share-buttons/

While it's true that the CII Best Practices badge application has "share" buttons (e.g., see the bottom of https://bestpractices.coreinfrastructure.org/en ), to my knowledge the CII badge website is *not* affected by this ruling. I explain why (in detail) below. Basically, instead of using the dangerous "Like" buttons, we use "Responsible Social Share Links" ... that means that users can see our web pages (even the ones with share buttons) without having that fact automatically reported to some social media site. Social media sites only receive information when the user specifically chooses to do this. We also don't send our information on "who accessed what" to anyone or accept payment to act on that information.

If there's an error or any other kind of security/privacy issue, please let us know so we can fix it. We've made serious attempts to counter exactly these kinds of problems, but we're human and it's possible we've missed something. We want our site to be secure & to respect the privacy of others.

Thanks!

--- David A. Wheeler


=== DETAILS ===

The "like" button that Facebook recommends that people use transfers personal data automatically when a non-Facebook page loads. That approach means that a user's visiting of that non-Facebook page is immediately revealed to Facebook without the user's knowledge or consent.

However, the "share" button we implemented in the CII Best Practices badge site has *never* worked that way. One of our requirements ( https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/requirements.md ) is to "Protect users and their privacy. In particular, we MUST comply with the EU General Data Protection Regulation (GDPR). Don't expose user email addresses, and don't expose user activities to unrelated sites (including social media sites) without that user's consent." As a result, we *never* accepted privacy-destroying constructs such as pages that transclude third party artifacts. We explain how we do this in https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md#Confidentiality . In particular, here's how we handle this:

"We do have links to social media sites (e.g., from the home page), but we do this in a privacy-respecting manner. It would be easy to use techniques like embedding images from external (third party) social media sites, but we intentionally do not do that, because that would expose to an external unrelated site what our users are doing without their knowledge. We instead use the approach described in "Responsible Social Share Links" by Jonathan Suh (March 26, 2015) https://jonsuh.com/blog/social-share-links/#use-share-urls , specifically using share URLs. In this approach, if a user does not press the link, the social media site never receives any information. Instead, a social media site only receives information when the user takes a direct action to request it (e.g., a click), and that site only receives information from the specific user who requested it."

This is part of a more general approach to supporting privacy. That same security section also notes that, "We directly serve all our assets ourselves, including JavaScipt, images, and fonts. Since we serve them ourselves, and never serve information via external third parties, external sites never receive any request from a user that might impact that user's privacy. This is enforced by our CSP policy.... We do not use any web analytics service that uses tracking codes or external assets. We log and store logs using only services we control or have a direct partnership with." Our CONTRIBUTING.md page (which provides instructions on contributions) says, "Avoid mechanisms that could be used for tracking where possible (we do need to verify people are logged in for some operations), and ensure that third parties can't use interactions for tracking."

We also ensure that the site's main functionality (displaying and editing project & user data) works even when JavaScript is disabled. From a security and privacy point-of-view, automatically running arbitrary code provided by all sites is more dangerous (due to malicious code, fingerprinting, and so on). Our site works better with JavaScript, but we ensure (and test) that the main parts work without JavaScript so that users can choose to enhance their security and privacy (by disabling JavaScript) if they desire to do so. This isn't possible to do for all web applications, but it's certainly possible for many web applications including ours.

If you see a remaining security / privacy issue, please let us know. For details on vulnerability reporting, please see:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/CONTRIBUTING.md