Date   
Re: Https links are not accepted in CII badging

David A. Wheeler
 

Seshu m:

> I finding issue while trying to update the https link in the CII badging for the following project

> https://bestpractices.coreinfrastructure.org/en/projects/1702

> when we provide a https link (or keep it blank) , the website throws an error

 

That shouldn’t happen.  Thanks for letting us know!  I’ll check it out.

 

--- David A. Wheeler

 

Silver crypto (TLS) requirements - thoughts from Zephyr

Andy Gross
 

David Wheeler:
We do that already; several criteria have "if" clauses. E.g.:
* If the software produced by the project requires building for use, the project
* MUST provide a working build system that can automatically rebuild the
* software from source code. [build]
* The project MUST enable one or more compiler warning flags, a "safe" language
* mode, or use a separate "linter" tool to look for code quality errors or
* common simple mistakes, if there is at least one FLOSS tool that can implement
* this criterion in the selected language. [warnings]

Suggestions on an "if" clause for this case are welcome; we can then discuss
them.
We've discussed this at some length in the Zephyr Security subcommittee and have
come up with the following changes:

I've listed the two requirements (Silver - Security #7 and #8) below with the
addition of an if clause to cover the Zephyr RTOS case. The changes are
encased in << >>.

The software produced by the project MUST, if it supports TSL, perform TLS
certificate verification by default when using TLS, including on subresources.
<<If the software is not an application that directly uses TLS select “not
applicable” (N/A).>>


The software produced by the project MUST, if it supports TLS, perform
certificate verification before sending HTTP headers with private information
(such as secure cookies). <<If the software is not an application that directly
uses TLS, select "not applicable" (N/A)>>

Regards,

Andy Gross
Linaro
Zephyr Security Subcommittee chair

We now have over 1,500 participating projects!

David A. Wheeler
 

We now have over 1,500 participating projects!  As of Sunday, 2018-04-29, we had 1,501 participating projects.  Of them, 168 projects have earned a passing badge.  We’ve had generally steady growth from 2016-05-24, when we had 83 participating projects.

 

My thanks to all!

 

You can see the latest statistics about the badging project here:

  https://bestpractices.coreinfrastructure.org/en/project_stats

 

--- David A. Wheeler

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

Mark Rader:
We may want to start caveating the advanced criteria for areas where a specific point may not apply.
We do that already; several criteria have "if" clauses. E.g.:
* If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. [build]
* The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings]

Suggestions on an "if" clause for this case are welcome; we can then discuss them.

--- David A. Wheeler

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Mark Rader
 

David

We may want to start caveating the advanced criteria for areas where a specific point may not apply. 

Mark

On Mon, Apr 16, 2018 at 2:44 PM, Wheeler, David A <dwheeler@...> wrote:
David Brown:
> This probably starts to become more of a Zephyr decision, but what I'm
> trying to make is so that we have a "demo" application that demonstrates
> the full solution, and does all that is needed to be secure.  If we do this
> right, this application won't be very large, and I see no reason to not
> include it in the sample applications in the tree.

That's an interesting approach, but I'm not sure requiring a project to create a "demo"
application just to pass some criteria really adds value.  We want the criteria to
add value!  If you need to do that for testing, though, I can see value in
a requirement like that.

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

David Brown:
This probably starts to become more of a Zephyr decision, but what I'm
trying to make is so that we have a "demo" application that demonstrates
the full solution, and does all that is needed to be secure. If we do this
right, this application won't be very large, and I see no reason to not
include it in the sample applications in the tree.
That's an interesting approach, but I'm not sure requiring a project to create a "demo"
application just to pass some criteria really adds value. We want the criteria to
add value! If you need to do that for testing, though, I can see value in
a requirement like that.

--- David A. Wheeler

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David Brown
 

On Mon, Apr 16, 2018 at 01:52:12PM -0500, Kate Stewart wrote:

On Mon, Apr 16, 2018 at 1:39 PM, Dan Kohn <[1]@dankohn> wrote:

OK, then I'm suggesting that perhaps Zephyr should only be able to get a
passing badge, but the combination of Zephy + a suitable bundled
application could get silver.

However, I don't feel strongly about this.

A "suitably bundled application" could open the door for a dependency outside
the project to be considered in assessment.
There's no real way of expressing this in the system as it stands today.   ie. 
if project "a" is "passing",   
application "b" relying on services from project "a" is "silver", but
application "b" relying on services from project "c" doesn't pass.
This probably starts to become more of a Zephyr decision, but what I'm
trying to make is so that we have a "demo" application that
demonstrates the full solution, and does all that is needed to be
secure. If we do this right, this application won't be very large,
and I see no reason to not include it in the sample applications in
the tree.

Somewhat unrelated to the security aspects themselves, I'd like this
application itself to be able to be fairly small, meaning that a lot
of the functionality, such as certificate verification, would be taken
care of by the libraries within Zephyr.

I'm not sure how this will fit in with what could be considered
passing the Silver requirements, though.

David

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Kate Stewart
 



On Mon, Apr 16, 2018 at 1:39 PM, Dan Kohn <dan@...> wrote:
OK, then I'm suggesting that perhaps Zephyr should only be able to get a passing badge, but the combination of Zephy + a suitable bundled application could get silver.

However, I don't feel strongly about this.

A "suitably bundled application" could open the door for a dependency outside the project to be considered in assessment.
There's no real way of expressing this in the system as it stands today.   ie.  if project "a" is "passing",   
application "b" relying on services from project "a" is "silver", but application "b" relying on services from project "c" doesn't pass.

I think it useful to maintain the scope of a badge associated within a single project, rather than 
combinations of projects.   To that end,  can the two criteria be rephased to take into account the difference
between applications and projects that supply services to applications?

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Dan Kohn
 

OK, then I'm suggesting that perhaps Zephyr should only be able to get a passing badge, but the combination of Zephy + a suitable bundled application could get silver.

However, I don't feel strongly about this.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Mon, Apr 16, 2018 at 2:35 PM, Kate Stewart <kstewart@...> wrote:


On Mon, Apr 16, 2018 at 1:25 PM, Dan Kohn <dan@...> wrote:
I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

Sorry my mistake.   I overloaded the term passing to 
mean "passing for a silver" badge in the context of this thread.

Zephyr already has had the "passing" badge for quite a while,  and we're 
93% of the way there for a Silver badge.


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Kate Stewart
 



On Mon, Apr 16, 2018 at 1:25 PM, Dan Kohn <dan@...> wrote:
I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

Sorry my mistake.   I overloaded the term passing to 
mean "passing for a silver" badge in the context of this thread.

Zephyr already has had the "passing" badge for quite a while,  and we're 
93% of the way there for a Silver badge.

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Dan Kohn
 

I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Mon, Apr 16, 2018 at 1:41 PM, Kate Stewart <kstewart@...> wrote:
Dan Kohn:
> I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

Challenge here is that Zephyr can't get a passing badge as the criteria is specified without writing 
and incorporating a reference application using its services.

Its not so much relaxing the criteria, as taking into account there are different types of software at play.
Operating systems and possibly language libraries are meant to have applications running on them, and 
call services they provide to enable functionality.  As a result,  its not clear how they can meet the criteria 
as specified without a contrived example application being  bundled/available with them as a reference 
(or at least that's the only path we've thought of so far). 

CII criteria here is specified for a running system,  which translates to the application perspective,  not
the OS/Library perspective.    

Are there any other OSes or language specific libraries,  that have met these two specific criteria
that you can point us to,  to see how they handled the criteria?

Thanks, Kate


_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


Silver crypto (TLS) requirements - thoughts from Zephyr

Kate Stewart
 

Dan Kohn:
> I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

Challenge here is that Zephyr can't get a passing badge as the criteria is specified without writing 
and incorporating a reference application using its services.

Its not so much relaxing the criteria, as taking into account there are different types of software at play.
Operating systems and possibly language libraries are meant to have applications running on them, and 
call services they provide to enable functionality.  As a result,  its not clear how they can meet the criteria 
as specified without a contrived example application being  bundled/available with them as a reference 
(or at least that's the only path we've thought of so far). 

CII criteria here is specified for a running system,  which translates to the application perspective,  not
the OS/Library perspective.    

Are there any other OSes or language specific libraries,  that have met these two specific criteria
that you can point us to,  to see how they handled the criteria?

Thanks, Kate

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

Dan Kohn:

> I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

 

I think it’s *too* restrictive, because our goal is to make sure that the overall system is secure.  If a library cannot get a higher badge, because it provides a clearly-documented lower-level interface, that will discourage the use of software that may in fact be better.

 

The original impetus for these TLS requirements, IIRC, was the botch in the built-in Python library where it accepted “https:” URLs, used the TLS protocol, but never checked the certificate, a sequence that led regular vulnerabilities.  See:

“PEP 476 -- Enabling certificate verification by default for stdlib http clients”

https://www.python.org/dev/peps/pep-0476/

 

But I think we overgeneralized.  The problem here was that the system accepted “https:” URLs without really implementing the full https protocol.

 

Indeed, even in Python, there’s a separation of “certificate checking” from “TLS implementation” because a lot of systems use specialized certificates.

 

--- David A. Wheeler

 

 

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Dan Kohn
 

I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Fri, Apr 13, 2018 at 10:00 AM, Wheeler, David A <dwheeler@...> wrote:
Kevin W. Wall:
> Instead, I think a better approach is to set up some sort of manual 'appeals
> process' whereby any given project can appear for an exclusion in regards
> to meeting some specific set of requirements and argue how it is either not
> applicable to them or how they have been the requirements _intent_ (i.e.,
> the spirit of the law) if not the letter of the law (requirement). I think that's
> preferable to removing / relaxing a requirement. This approach is common
> in policy governance. Unfortunately, it will require some "governing
> authority"
> to review the (hopefully) occasional appeal. One would hope that such
> appeals would be a relatively rare occurrence.

Our current appeals process has been to post proposed
changes/interpretations to this mailing list for comment
(skipping typos & such).  Then we (supporting the LF) make the final call.
Hence the email :-).

We've discussed several times creating a "governing body."
I (still) think it's a good idea, but we so seldom get questions like this
that it keeps getting pushed into the "sometime in the future" column.

I think you make a good point, though.  Maybe "we don't need to do it often"
is a selling point :-).

> In general, I am against relaxing the 2 silver requirements for Zephyr or any
> other project. And not just these TLS requirements, but conceptually I am
> against relaxing _any_ requirements for any level.
> If we have to do that, it seems to me that that's an admission that those
> requirements re too difficult for some particular level.

I have a slightly different view.  I think that if the requirements get relaxed
for *any* project, then *all* projects should have the opportunity to use those
relaxed requirements.  So if we really *do* relax a requirement, it should
be reflected in the criteria text that people read.  Nobody should have to
read the "special interpretations" of all other projects, they should be able to
read the criteria and see exactly what it means.
My goal is that over time this will clarify the "true intent"
of the underlying requirement.

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

Kevin W. Wall:
Instead, I think a better approach is to set up some sort of manual 'appeals
process' whereby any given project can appear for an exclusion in regards
to meeting some specific set of requirements and argue how it is either not
applicable to them or how they have been the requirements _intent_ (i.e.,
the spirit of the law) if not the letter of the law (requirement). I think that's
preferable to removing / relaxing a requirement. This approach is common
in policy governance. Unfortunately, it will require some "governing
authority"
to review the (hopefully) occasional appeal. One would hope that such
appeals would be a relatively rare occurrence.
Our current appeals process has been to post proposed
changes/interpretations to this mailing list for comment
(skipping typos & such). Then we (supporting the LF) make the final call.
Hence the email :-).

We've discussed several times creating a "governing body."
I (still) think it's a good idea, but we so seldom get questions like this
that it keeps getting pushed into the "sometime in the future" column.

I think you make a good point, though. Maybe "we don't need to do it often"
is a selling point :-).

In general, I am against relaxing the 2 silver requirements for Zephyr or any
other project. And not just these TLS requirements, but conceptually I am
against relaxing _any_ requirements for any level.
If we have to do that, it seems to me that that's an admission that those
requirements re too difficult for some particular level.
I have a slightly different view. I think that if the requirements get relaxed
for *any* project, then *all* projects should have the opportunity to use those
relaxed requirements. So if we really *do* relax a requirement, it should
be reflected in the criteria text that people read. Nobody should have to
read the "special interpretations" of all other projects, they should be able to
read the criteria and see exactly what it means.
My goal is that over time this will clarify the "true intent"
of the underlying requirement.

--- David A. Wheeler

Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Kevin W. Wall
 

David,

First, apologies for top posting. I don't usually do that, but I have
a bunch of emails to reply to tonight.

In general, I am against relaxing the 2 silver requirements for Zephyr
or any other project. And not just these TLS requirements, but
conceptually I am against relaxing _any_ requirements for any level.
If we have to do that, it seems to me that that's an admission that
those requirements re too difficult for some particular level.

Instead, I think a better approach is to set up some sort of manual
'appeals process' whereby any given project can appear for an
exclusion in regards to meeting some specific set of requirements and
argue how it is either not applicable to them or how they have been
the requirements _intent_ (i.e., the spirit of the law) if not the
letter of the law (requirement). I think that's preferable to removing
/ relaxing a requirement. This approach is common in policy
governance. Unfortunately, it will require some "governing authority"
to review the (hopefully) occasional appeal. One would hope that such
appeals would be a relatively rare occurrence. And as far as Zephyr is
concerned, it sounds as though they have already made an appeal and
sounds like their appeal is justified to me (which perhaps additional
documentation requirements as you mentioned).

My $.02,
-kevin

On Wed, Apr 11, 2018 at 5:43 PM, Wheeler, David A <@dwheeler> wrote:
We have a request for tweaking two silver requirements involving crypto
(specifically TLS) from the Zephyr project. Some details below. We don’t
have any particular text change proposals yet. If you have thoughts about
this, please comment or reply.



Thanks.



--- David A. Wheeler



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



The silver badge requirements include the following:

* The software produced by the project MUST, if it supports TLS, perform TLS
certificate verification by default when using TLS, including on
subresources. If the software does not use TLS, select "not applicable"
(N/A). [crypto_certificate_verification]

* The software produced by the project MUST, if it supports TLS, perform
certificate verification before sending HTTP headers with private
information (such as secure cookies). If the software does not use TLS,
select "not applicable" (N/A).[crypto_verification_private]



However, we have some interesting comments from the Zephyr team (who are
working on a silver badge).



They note that, “Zephyr is an embedded operating system, and applications
would be bound to it, to go on a device to provide specific functions.”
Zephyr includes a code library that implements parts of TLS, but it’s not
*used* unless an application (running on top of Zephyr) calls this
TLS-related code. In Zephyr, the application needs to perform the
verification for the TLS certificates.



Of course, our real goal is that the "system as a whole" perform certificate
validation. From a security viewpoint, as long as it's *done* it's okay…
never mind *where* it’s done.



If Zephyr only provides the certificate information to something else, then
I think Zephyr needs to *clearly* document that the "other piece" *must*
complete the job of certificate validation, hopefully with clear warnings.
That's been a problem with Python, for example - people thought it was doing
certificate validation when it was *not*. IIRC, these criteria were
developed in part based on the experience with the Python libraries. But if
Zephyr makes it clear that it only does *part*, and does *NOT* do
certificate validation, then I think we should allow that kind of library
design. Basically, we want *apps* to do the full certificate validation…
but a library might not be doing the validation internally.



That said, we’ll need to be careful about any relaxing, including this case.
And if that’s just a terrible idea, I’d like to know that too.


_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges
--
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

We have a request for tweaking two silver requirements involving crypto (specifically TLS) from the Zephyr project.  Some details below.  We don’t have any particular text change proposals yet.  If you have thoughts about this, please comment or reply.

 

Thanks.

 

--- David A. Wheeler

 

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

 

The silver badge requirements include the following:

* The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select "not applicable" (N/A). [crypto_certificate_verification]

* The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select "not applicable" (N/A).[crypto_verification_private]

 

However, we have some interesting comments from the Zephyr team (who are working on a silver badge).

 

They note that, “Zephyr is an embedded operating system, and applications would be bound to it, to go on a device to provide specific functions.”  Zephyr includes a code library that implements parts of TLS, but it’s not *used* unless an application (running on top of Zephyr) calls this TLS-related code.  In Zephyr, the application needs to perform the verification for the TLS certificates.

 

Of course, our real goal is that the "system as a whole" perform certificate validation.  From a security viewpoint, as long as it's *done* it's okay… never mind *where* it’s done.

 

If Zephyr only provides the certificate information to something else, then I think Zephyr needs to *clearly* document that the "other piece" *must* complete the job of certificate validation, hopefully with clear warnings.  That's been a problem with Python, for example - people thought it was doing certificate validation when it was *not*.  IIRC, these criteria were developed in part based on the experience with the Python libraries.  But if Zephyr makes it clear that it only does *part*, and does *NOT* do certificate validation, then I think we should allow that kind of library design.  Basically, we want *apps* to do the full certificate validation… but a library might not be doing the validation internally.

 

That said, we’ll need to be careful about any relaxing, including this case.  And if that’s just a terrible idea, I’d like to know that too.

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2018-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 dates2018-02-272018-03-30
Total Projects13871459
Projects 25%+492526
Projects 50%+412449
Projects 75%+327357
Projects passing142159

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

  1. Graph at 2018-03-01 19:14:11 UTC
  2. Mission Pinball Framework at 2018-03-01 21:14:25 UTC
  3. cws at 2018-03-05 10:09:56 UTC
  4. libqmatrixclient at 2018-03-06 09:09:50 UTC
  5. AppArmor at 2018-03-06 15:01:48 UTC
  6. Multi VIM/Cloud at 2018-03-07 08:54:51 UTC
  7. ONAP Operations Manager at 2018-03-07 15:53:53 UTC
  8. wrike-bundle at 2018-03-07 20:03:49 UTC
  9. wrike-php-sdk at 2018-03-07 20:03:56 UTC
  10. wrike-php-jmsserializer at 2018-03-07 20:04:03 UTC
  11. wrike-php-guzzle at 2018-03-07 20:04:09 UTC
  12. wrike-php-library at 2018-03-07 20:04:17 UTC
  13. ONAP Optimization Framework (OOF) at 2018-03-13 18:24:33 UTC
  14. vitess at 2018-03-14 23:53:28 UTC
  15. distrobuilder at 2018-03-16 13:15:27 UTC
  16. VIPERBuilder at 2018-03-16 17:21:00 UTC
  17. Helpers for node-postgres for Lazy devs. 👽 at 2018-03-17 20:27:20 UTC
  18. MUSIC at 2018-03-20 17:29:21 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 mailing list tweak planned by Linux Foundation IT department

David A. Wheeler
 

All, for your information:

The Linux Foundation's IT department has informed me that they are going to change how the mailing list works sometime in May 2018.

If you just read the emails you receive, you shouldn't notice a change. They've assured me that the archives will NOT be lost.

The management URLs will change from <https://lists.coreinfrastructure.org/mailman/listinfo/cii-discuss> to <https://lists.coreinfrastructure.org/g/cii-discuss>, but there will be a forwarding link - so if you use the old link you'll get forwarded to the new one.

If something DOES break, please let me know & I'll forward the issue to them.

--- David A. Wheeler

Native/fluent Spanish speaker willing to help translation?

David A. Wheeler
 

If you are a native/fluent Spanish speaker who’d be willing to do some translations for the best practices badge site, please contact me!  If you know someone trustworthy who fits that bill, please convince them to contact me.  We have some strings translated, but many aren’t done.

 

Thanks!

 

--- David A. Wheeler