Date   

Re: Suggestions on countering spammers?

Trevor Vaughan
 

Pretty sure if you report them the GitHub they'll get banned.


On Fri, Dec 20, 2019 at 3:14 PM David A. Wheeler <dwheeler@...> wrote:
Mark Rader:
> Require them to validate their email address.

Good idea, but for local accounts we already do that, and I believe GitHub also requires email validation for their accounts.

So we're going to have to go beyond that.

--- David A. Wheeler





--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --


Re: Suggestions on countering spammers?

David A. Wheeler
 

Mark Rader:
Require them to validate their email address.
Good idea, but for local accounts we already do that, and I believe GitHub also requires email validation for their accounts.

So we're going to have to go beyond that.

--- David A. Wheeler


Re: Suggestions on countering spammers?

Mark Rader
 

Require them to validate their email address.

On Dec 20, 2019, at 11:13 AM, David A. Wheeler <@dwheeler> wrote:

Sadly, spammers have started to add nonsense "projects" to the CII Best Practices site
at a higher rate than before. It appears to be all SEO-related fraud.
I suppose that was inevitable, and I guess it's good that we're "worth" their time.

If anyone has ideas on how to automatically help counter spammers, please
let us know via reply to this mailing list, private email, or this issue:
https://github.com/coreinfrastructure/best-practices-badge/issues/1377

Thanks!

--- David A. Wheeler




Suggestions on countering spammers?

David A. Wheeler
 

Sadly, spammers have started to add nonsense "projects" to the CII Best Practices site
at a higher rate than before. It appears to be all SEO-related fraud.
I suppose that was inevitable, and I guess it's good that we're "worth" their time.

If anyone has ideas on how to automatically help counter spammers, please
let us know via reply to this mailing list, private email, or this issue:
https://github.com/coreinfrastructure/best-practices-badge/issues/1377

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-11.

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-10-302019-11-29
Total Projects27652855
Projects 25%+10641089
Projects 50%+882902
Projects 75%+717732
Projects 90%+538551
Projects passing372382

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

  1. wordpress-sqrl-login at 2019-11-01 09:37:16 UTC
  2. SQLite-simplecrawler-queue at 2019-11-08 10:53:41 UTC
  3. cloud-mta-build-tool at 2019-11-13 08:51:16 UTC
  4. DymamicAuthProviders at 2019-11-20 10:26:43 UTC
  5. krowdy-ui at 2019-11-26 21:10:22 UTC
  6. .dotfiles at 2019-11-28 10:21:51 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-10.

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-09-292019-10-30
Total Projects26652765
Projects 25%+10241064
Projects 50%+849882
Projects 75%+692717
Projects 90%+516538
Projects passing356372

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

  1. standup-raven at 2019-10-05 05:27:49 UTC
  2. Group-Office at 2019-10-07 11:54:32 UTC
  3. tqdm at 2019-10-11 15:52:20 UTC
  4. boxrec at 2019-10-14 15:40:37 UTC
  5. PSP at 2019-10-15 12:31:17 UTC
  6. crawl at 2019-10-15 14:14:41 UTC
  7. setup-php at 2019-10-16 13:48:06 UTC
  8. Secure Production Identity Framework for Everyone Runtime Enviroment at 2019-10-17 18:10:47 UTC
  9. augur at 2019-10-23 23:22:27 UTC
  10. cyclone at 2019-10-26 01:37:47 UTC
  11. formatter at 2019-10-27 09:35:20 UTC
  12. FireO at 2019-10-28 13:41:17 UTC
  13. spice at 2019-10-28 23:05:16 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!


Re: Proposal: Use CVSS version 3, not version 2, in CII Best Practices measures

David A. Wheeler
 

Here's a pull request that tries to resolve the CVSS issues:
https://github.com/coreinfrastructure/best-practices-badge/pull/1367

It's more text than I'd like, but my goal was to be 100% clear.
For example, instead of "medium or high" it was changed to
"medium or higher" (because we REALLY want critical vulnerabilities fixed!).
Below is the (simplified) diff of criterion vulnerabilities_fixed_60_days.

My goal was to be future-proof and precise.
CVSS is not a perfect system, but we just want a way to let projects
lower the priority of low-importance vulnerabilities, and for task that I
think it does okay.

Comments welcome.

--- David A. Wheeler

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

There MUST be no unpatched vulnerabilities of medium
- or high severity that have been publicly known for more
+ or higher severity that have been publicly known for more
than 60 days.

(In details)
- A vulnerability
- is medium to high severity if its
- <a href="https://nvd.nist.gov/cvss.cfm">CVSS
- 2.0</a> base score is 4 or higher.
+ A vulnerability is considered medium or higher severity if its <a
+ href="https://www.first.org/cvss/"
+ >Common Vulnerability Scoring System (CVSS)</a>
+ base qualitative score is medium or higher.
+ In CVSS versions 2.0 through 3.1, this is
+ equivalent to a CVSS score of 4.0 or higher.
+ Projects may use the CVSS score
+ as published in a widely-used vulnerability database (such as the
+ <a href="https://nvd.nist.gov">National Vulnerability Database</a>)
+ using the most-recent version of CVSS reported in that database.
+ Projects may instead calculate the severity
+ themselves using the latest version of
+ <a href="https://www.first.org/cvss/">CVSS</a> at the time of
+ the vulnerability disclosure,
+ if the calculation inputs are publicly revealed once
+ the vulnerability is publicly known.


Re: Proposal: Use CVSS version 3, not version 2, in CII Best Practices measures

David A. Wheeler
 

Kevin Wall:
I have no objections, but how will moving from CVSSv2 to CVSSv3 affect things if NVD only has CVSSv2 scores available for the particular CVE? Would there be an expectation that we would need to deal with MITRE or maybe NIST to get them to assign a new CVSSv3 score? Because I don't even want to go there.
Good point. I think that shouldn't be required, & it wasn't intended. I think we can solve that.

But first, I think I'm required to note that anyone can calculate a CVSS score.
NVD has a little calculator: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
FIRST does too: https://www.first.org/cvss/calculator/3.0 and https://www.first.org/cvss/calculator/3.1
That said, there's a judgement call on a few questions like "privileges required" that are used to do the calculation. In most cases that won't matter, but I imagine people would rather get some "official" ruling on them. There's also the issue that people want to just use someone's calculation instead of doing it themselves; nobody wants to fight over that stuff.

Your question about versioning & clarity also raises a few related issues (which I think can also be resolved):
1. I posted about "version 3", but I really meant the "latest version in the 3 series" which is actually 3.1. We really don't want to be changing the text every time a new CVSS edition comes out. Using "most recent published" should resolve it.
2. When I say “CVSS scores” I really just mean the *base* score. NVD does the same thing, they only use base scares (see https://nvd.nist.gov/vuln-metrics/cvss ). The “temporal score” varies by time, and the “environmental score” varies by environment, so neither are useful for our purposes. Most people just look at NVD score (and thus "do what was intended" anyway), but that should be clearer than it currently is.

The simple solution is to let people use the vulnerability's base CVSS value as (1) published in a widely-used vulnerability database with the most-recent version of CVSS for that vulnerability, or (2) calculated themselves using the current version of CVSS (with the calculation publicly revealed if the vulnerability is publicly known). That means projects might not always use the current version of CVSS, but that's okay. Over time the old values will become irrelevant (through aging out), without requiring a lot of unnecessary work.

CVSS isn't a be-all/end--all. I think of it more as a simple heuristic. Ideally projects would fix all vulnerabilities, but there are some "vulnerabilities" which are very low risk & in some cases it's debatable that they even *are* vulnerabilities. We're simply using CVSS as a mechanism to let projects focus on the "vulnerabilities that are more likely to matter".

--- David A. Wheeler


Re: Proposal: Use CVSS version 3, not version 2, in CII Best Practices measures

Kevin W. Wall
 

I have no objections, but how will moving from CVSSv2 to CVSSv3 affect things if NVD only has CVSSv2 scores available for the particular CVE? Would there be an expectation that we would need to deal with MITRE or maybe NIST to get them to assign a new CVSSv3 score? Because I don't even want to go there.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/  |  Twitter:  @KevinWWall
NSA: All your crypto bit are belong to us.

On Mon, Nov 4, 2019, 09:04 David A. Wheeler <dwheeler@...> wrote:
A very few of our criteria mention CVSS (a method for estimating the risk from a vulnerability). For example, [dynamic_analysis_fixed] says this:
CRITERION: "All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed."
DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

I'd like to update from CVSS version 2 to version 3. CVSS version 3 has been around for a while, but we didn't use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data. However, NIST has since added support for version 3 & has supported it for a while. More info:
https://nvd.nist.gov/vuln-metrics/cvss

This should have no effect in practice. CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2). That said, if a project has that many vulnerabilities where the CVSS version change matters, that's a problem in itself.

If you think that's a bad idea, please let us know.  This is already an issue on GitHub:
https://github.com/coreinfrastructure/best-practices-badge/issues/1076

Thanks!

--- David A. Wheeler




Proposal: Use CVSS version 3, not version 2, in CII Best Practices measures

David A. Wheeler
 

A very few of our criteria mention CVSS (a method for estimating the risk from a vulnerability). For example, [dynamic_analysis_fixed] says this:
CRITERION: "All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed."
DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

I'd like to update from CVSS version 2 to version 3. CVSS version 3 has been around for a while, but we didn't use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data. However, NIST has since added support for version 3 & has supported it for a while. More info:
https://nvd.nist.gov/vuln-metrics/cvss

This should have no effect in practice. CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2). That said, if a project has that many vulnerabilities where the CVSS version change matters, that's a problem in itself.

If you think that's a bad idea, please let us know. This is already an issue on GitHub:
https://github.com/coreinfrastructure/best-practices-badge/issues/1076

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-09.

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-08-302019-09-29
Total Projects25862665
Projects 25%+9931024
Projects 50%+824849
Projects 75%+669692
Projects passing341356

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

  1. KrakenD at 2019-09-03 22:59:18 UTC
  2. RethinkDB at 2019-09-04 19:32:47 UTC
  3. Medical Imaging Diagnosis Assistant at 2019-09-10 15:41:38 UTC
  4. metallb at 2019-09-10 17:01:03 UTC
  5. WDLCT at 2019-09-11 20:41:47 UTC
  6. NEXT Directory at 2019-09-12 22:05:12 UTC
  7. etcd at 2019-09-19 19:26:57 UTC
  8. besu at 2019-09-20 15:52:25 UTC
  9. OpenEXR at 2019-09-22 03:07:39 UTC
  10. goku-api-gateway at 2019-09-24 14:24:37 UTC
  11. bfe at 2019-09-25 13:57:25 UTC
  12. gosec at 2019-09-26 08:43:58 UTC
  13. OWASP ModSecurity Core Rule Set at 2019-09-27 22:28:24 UTC
  14. acme2certifier at 2019-09-29 13:18:35 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: CII Best Practices badge site continues to get updates

David A. Wheeler
 

FYI: We continue the work keep the CII Best Practices badge site working smoothly. In particular, we've done a number of updates to keep things going over the last several months. You generally should NOT notice these updates from the user side. If you're curious, I've listed below some of the updates we've done.

That's not including various functional refinements, such as inserting word breaks in the projects page (so the display is better on small screens).

As you can see by the recent progress email, the number of participating & passing projects continues to grow. My thanks to everyone!!

--- David A. Wheeler

====== DETAILS ======

Various updates:
* We've updated from PostgreSQL 9.4 to 11.5.
* We've updated from Ruby 2.5.1 to Ruby 2.6.3
* Our test infrastructure (on CircleCI) uses an updated image.  We had been running on an old Ubuntu 14.04 image.  We're now running on a custom ruby:2.5.1-stretch image, and we have a posted Docker file to create the custom image.
* We've updated our JavaScript test framework to Capybara+Selenium+ChromeDriver.  We were previously using PhantomJS, but its development had suspended as of 2019-03-03.
* We continue to update individual libraries.  This includes nokogiri, webmock, hashdiff, mini_mime, public_suffix, bundler, railroader, addressable, archive-zip, autoprefixer-rails, bindex, docile, ffi, gitlab, jwt, mime-types-data, and more.
* We've countered CVE-2015-9284 in omniauth.  Unfortunately, at the time of this
 writing the omniauth folks STILL have not fixed it (!). That is, of course, very concerning.
  There is a shim by a third party that *does* fix it: omniauth-rails_csrf_protection.
 I reviewed the code and it looks okay.
  To provide a stronger guarantee that what I reviewed is what will
  be loaded, I'm specifying a specific hash reference.  That's no
 guarantee, but it does make attacks harder to perform.
  See: https://github.com/omniauth/omniauth/pull/809


Projects that received badges (monthly summary)

badgeapp@...
 

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

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-07-302019-08-30
Total Projects25162586
Projects 25%+961993
Projects 50%+795824
Projects 75%+639669
Projects passing328341

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

  1. kyma at 2019-08-01 20:34:50 UTC
  2. SimpleStore at 2019-08-05 20:31:01 UTC
  3. libbsd at 2019-08-08 02:21:34 UTC
  4. Zend Framework at 2019-08-08 16:26:22 UTC
  5. jpa-spec at 2019-08-13 08:06:04 UTC
  6. Matterpoll at 2019-08-15 13:36:39 UTC
  7. manifold at 2019-08-16 17:06:35 UTC
  8. solid-instruments at 2019-08-17 22:25:11 UTC
  9. pyro at 2019-08-22 19:41:45 UTC
  10. mattermost-plugin-remind at 2019-08-25 04:41:26 UTC
  11. date_time at 2019-08-29 18:41:32 UTC
  12. helm at 2019-08-29 23:49:37 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


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!


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!


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-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!


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-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!