|
Renaming whitelist->acceptlist, blacklist->denylist
All: This pull request: https://github.com/coreinfrastructure/best-practices-badge/pull/1449renames “whitelist” to “acceptlist” and “blacklist” to “denylist" everywhere in the CII Best Practices badge material, including the criteria text. Note that “a whitelist” becomes “an acceptlist” (where “a” becomes “an”). This is technically a change to the criteria text, but it does not change the *meaning* of the text in any way. As always, if you have issues or see an error, please comment on the pull request. Thank you! — David A. Wheeler
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: has anyone scripted doing updates to the CII site?
On Aug 12, 2020, at 5:43 PM, HANSEN, TONY L <tony@att.com> wrote:
David, here are some questions not answered by that page:It uses TLS to authenticate the best practices server, as well as provide confidentiality & integrity between client & server. Login session management uses an HTTP cookie, not basic authentication. A quick summary is “do what a human user would do”. You use a POST to log in (with username & password), and get a cookie that represents your session. That cookie can then be used (for a period of time) by sending it as part of future requests, and grants you whatever your account is authorized to do. * When using the PATCH verb, what is the JSON input expected to look like?This is actually implemented by the underlying Rails framework. I’ll have to search, but I believe there’s lots of sites that go into this. — David A. Wheeler
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: has anyone scripted doing updates to the CII site?
Tony Hansen
David, here are some questions not answered by that page:
toggle quoted messageShow quoted text
* Does the REST API support basic authentication (over TLS)? Or some other HTTPS authentication method? * When using the PATCH verb, what is the JSON input expected to look like? PATCH /projects/:id(.:format) projects#update Thank you Tony On 8/12/20, 9:22 AM, "David A. Wheeler" <dwheeler@linuxfoundation.org> wrote:
On Wed, Aug 12, 2020 at 12:10 AM Tony Hansen <tony@att.com> wrote:
... > So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such as > Of course, it would need to log in correctly with an ID that has been authorized on each of the projects. > I started writing such a tool, but I keep getting caught up with issues with CSRF. Tony: We developed the API so it *could* be done. But I have never needed to do it, so I don't have code lying around to do it. I'd be delighted to help anyone who starts down that path. I believe it shouldn't be *too* hard, the problem is that it has to be exactly right or it gets (rightly) rejected. The current API documentation may help: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/api.md ... and if such code is created, we should add it to the API documentation. --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: has anyone scripted doing updates to the CII site?
On Wed, Aug 12, 2020 at 12:10 AM Tony Hansen <tony@att.com> wrote:
... So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such asTony: We developed the API so it *could* be done. But I have never needed to do it, so I don't have code lying around to do it. I'd be delighted to help anyone who starts down that path. I believe it shouldn't be *too* hard, the problem is that it has to be exactly right or it gets (rightly) rejected. The current API documentation may help: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/api.md ... and if such code is created, we should add it to the API documentation. --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
has anyone scripted doing updates to the CII site?
Tony Hansen
I’m one of the many people working on the Linux ONAP (Open Networking Automation Platform) Project. We chose to pursue CII badges from the very beginning, but because of the size of the project, we chose several years ago to use separate CII projects for each of the ONAP sub-projects. We currently have close to 40 CII projects covering the ONAP sub-projects.
For all of the application-specific questions, we rely on our project team leaders to answer the questions. However, when we do something (say, updating our build infrastructure to better satisfy one of the Gold questions), we are faced with updating all 40 CII pages with an identical update. Getting the project team leaders to do the updates has proven unreliable, and doing the update one project at a time is tedious at best.
So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such as
projects: 3777, . . . mods: signed_releases_justification: "All release artifacts are signed by the Linux Foundation prior to release.."
Of course, it would need to log in correctly with an ID that has been authorized on each of the projects.
I started writing such a tool, but I keep getting caught up with issues with CSRF.
Has anyone successfully scripted doing updates to the CII site? If no one has, is anyone interested in working with me on such a tool?
Thank you
Tony Hansen tony@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Software report on Zephyr notes CII Best Practices badge
All:
Here's a team report, as part of an architecture class, where they examined open source software projects: https://se.ewi.tudelft.nl/desosa2019/ If you look at a part that discusses Zephyr: https://se.ewi.tudelft.nl/desosa2019/chapters/zephyr/#Autotools You can see a reference to the CII Best Practices badge! It sayd: "In conclusion, Zephyr could serve as a role model not only for Real-time Operating Systems, but also for open-source software projects in general. It is a good example of how successful management of open-source contributions and a well defined and documented architecture can ensure and retain the software’s quality. They follow some of the [CII best] practices as can be seen from their gold badge and this process goes a long way in avoiding technical debt." This report came out in Dec 2019, so it's a bit dated in terms of the Zephyr release they're looking at (pre-LTS). However, as Kate Stewart noted, "it has some nice creative ways of showing the info... I like how they did some of the classifications." My sincere thanks to Brett, and Kate Stewart, for noticing this & telling me about it! --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation -- --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
CHAOSS Podcast #10 posted, notes the CII Best Practices Badge
All:
CHAOSS Podcast #10 is now available, titled "Managing Risks and Opportunities in Open Source with Frank Nagle & David A. Wheeler". The hosts were Georg Link, Sean Goggins, and Kate Stewart. The podcast mentions the CII Best Practices badge specifically. You can hear it here: https://podcast.chaoss.community/10 --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Mailing list server will be moving the Linux Foundation Single Sign-On (SSO)
All:
The CII mailing list service is expected to soon switch to the “Linux Foundation Single Sign-on (SSO)” system for logging in to the mailing list service. This is part of an LF effort to have *one* strong authentication service for all LF work, so that people don’t need an endless numbers of accounts for LF work. If you just receive emails, or you already use the LF SSO, then there’ll be no change. Otherwise, when this change happens, you’ll need to do a one-time account creation with the new LF SSO service. It should be very easy. — David A. Wheeler
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Please participate in the LF CII / Harvard LIST FOSS Survey!
If you're a contributor to Free/Libre and Open Source Software (FOSS),
please participate in the LF CII / Harvard FOSS survey! Here are more details, with a link at the bottom to the actual survey: https://www.linuxfoundation.org/blog/2020/06/linux-foundation-harvard-announce-free-libre-and-open-source-software-foss-contributor-survey/ Thanks! --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
FYI: “The Impact of a Major Security Event on an Open Source Project:The Case of OpenSSL”
All:
A recent paper looked at Heartbleed’s impact on OpenSSL: “The Impact of a Major Security Event on an Open Source Project:The Case of OpenSSL” by James Walden, 2020, https://arxiv.org/abs/2005.14242 Two interesting points: * "the number of reported vulnerabilities is a poor indicator of security." Basically, small numbers can mean "there's little to find" OR "no one is looking. * "Project activity and software engineering practices required by the CII best practices badge may be better indicators of project security.” They found that OpenSSL made a number of changes to earn the badge, *AND* that those changes had stuck around years later. Overall it's an interesting paper. They basically examine the OpenSSL project before & after Heartbleed to see what they changed, and how it changed their results. It's nice to see the best practices badging project get positive comments :-). --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
"Why CII best practices gold badges are important":
All - I thought you might like to know that I recently posted a blog
post titled "Why CII best practices gold badges are important": https://www.linuxfoundation.org/blog/2020/06/why-cii-best-practices-gold-badges-are-important/ It's on the Linux Foundation's blog, so hopefully at least some others will notice. The post emphasizes advantages of badges, including the gold level. People here already know this info, I think, but I thought you'd like to know about efforts to let *others* know. --- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: The Linux kernel has earned a gold badge!
Kate Stewart
Excellent news! Kudo's to Greg and the other contributors to making this happen!
On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote: All: I want to formally congratulate the Linux kernel project for
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: The Linux kernel has earned a gold badge!
Georg Link
This is fantastic news! Congratulations to the Linux Kernel. Thanks for highlighting this achievement. Georg
On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote: All: I want to formally congratulate the Linux kernel project for -- Georg Link, PhD (he/him)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
The Linux kernel has earned a gold badge!
All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here: https://bestpractices.coreinfrastructure.org/en/projects/34 The Linux kernel has been close for a while. The final one they completed was to add some HTTP hardening headers to key websites. Of course, a gold badge doesn't mean that there are no vulnerabilities, or that it's impossible to improve their development processes. Perfection is rare in this life. But it *does* mean that they've implemented a large number of good practices to keep the project sustainable, to counter vulnerabilities from entering their software, and to address vulnerabilities when they are found. The Linux kernel project take many steps to do this, and it's good to see. The Linux kernel joins some of the few other gold applications, such as the Zephyr project who have been at gold for a while. You can see the current gold holders here: https://bestpractices.coreinfrastructure.org/en/projects?gteq=300 My thanks to Greg KH, who spearheaded getting the badge "over the finish line". Thank you for your effort. I hope that this result will help inspire other projects to pursue - and earn - a gold badge. Of course, the real goal isn't a badge - the real goal is to make our software much more secure. But I think it's clear that good practices can help make our software more secure, and we want to praise & encourage projects to have good practices. -- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Should the badge app switch to a different translation management system (from translation.io)?
Georg Link has proposed that we switch from the translation.io translation management system to a different system (in particular, Weblate). If you have thoughts on such a potential change, or information that could help in that decision, please add that information to this issue: 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 2020-05. Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.
Here are the projects that first achieved a Passing badge in 2020-05:
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: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites
Wow, unanimous agreement is rare! Thank you everyone for your comments. While we’re changing this text, I propose that we make a few more tweaks: - I checked, and GitLab-hosted project repos have the same protections. I confirmed this by viewing the Inkscape repo at https://gitlab.com/inkscape/inkscape . GitHub is a great service, but where possible I want to *not* imply that people must lock into any specific services. - I think the text about static sites should be tweaked so that if headers are added/removed later it’ll still make sense, and also just to shorten it. - securityheaders.io is now a redirect to securityheaders.com (it seems to be otherwise the same). As always, we mention this service as an easy way to get useful information (“such as”), we don’t mandate its use. So here’s one more tweak, turning this “details” text: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites." Into this: "Note that GitHub and GitLab are known to meet this. Sites such as https://securityheaders.com/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Fully static web sites with no ability to log in via the web pages could omit some hardening headers with less risk, but there's no reliable way to detect such sites, so we require these headers for both the project home page and repository.” The X-Frame-Options header’s mechanism can also be done via CSP. However, unlike X-XSS-Protection, it is basically universally supported (for DENY and SAMEORIGIN) and is still important in securityheaders.com. It even has an IETF RFC (RFC 7034, though note it’s just informational and not standards-track). More info here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options. So I think it’s reasonable to keep the X-Frame-Options header, at least for now, it seems to have far more support at this time. This is also being tracked here: --- David A. Wheeler
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites
Jason Dossett
This change makes perfect since.
toggle quoted messageShow quoted text
Best, Jason N. Dossett, Ph.D. Research Staff Member Institute for Defense Analyses 4850 Mark Center Drive, Alexandria, VA 22311 Phone: 703-578-2773 Email: jdossett@ida.org
-----Original Message-----
From: CII-badges@lists.coreinfrastructure.org <CII-badges@lists.coreinfrastructure.org> On Behalf Of David Wheeler Sent: Tuesday, June 2, 2020 4:49 PM To: CII-badges@lists.coreinfrastructure.org Subject: [EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites *** This email originated outside of IDA. Please verify that you recognize the sender and know the content is safe before proceeding. *** I propose that for the "hardened_sites" criterion we stop requiring the HTTP header X-XSS-Protection, and that we require CSP & explain why. Here's the background. The Linux kernel is failing to meet the "hardened sites" criterion: https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site The reason is that those sites' HTTP headers do not include something like this: X-XSS-Protection: 1 The criterion main text is: "The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values." with these details: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective." This issue with the Linux kernel is discussed here: https://github.com/coreinfrastructure/best-practices-badge/issues/1253 There are two problems. The first is that X-XSS-Protection has not aged well. It's supposed to enable some heuristic protections. These protections are largely unnecessary in modern browsers (CSP is recommended instead), and it's increasingly obvious that this header will never be standardized. Firefox won't add it, Edge has retired it. Perhaps most importantly, securityheaders.io doesn't even *report* the status of X-XSS-Protection, making it suddenly harder to see this header value for a site... and also providing additional evidence that X-XSS-Protection has outlived its purpose. Details here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection The second problem is that while CSP isn't really very helpful on static sites, it's impractical to detect if a site is a static site or not, and we very much *do* want to encourage CSP use. So I propose keeping the main criterion unchanged, but changing these details: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."To the following: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."--- David A. Wheeler Director of Open Source Supply Chain Security, The Linux Foundation
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites
Alton Blom
The change seems pragmatic, and makes sense to me.
On Wed, Jun 3, 2020 at 6:49 AM David Wheeler <dwheeler@...> wrote: I propose that for the "hardened_sites" criterion we stop requiring
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites
On Tue, Jun 2, 2020 8:49 PM, David Wheeler dwheeler@... wrote:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
