Date   

GnuPG efail - researcher discussion failure

Luis R. Rodriguez <mcgrof@...>
 

As you may know there is tons of media coverage over efail:

https://efail.de/

The GnuPG team response seems to indicate that the researchers really
didn't properly engage or tune their message to avoid such hype over
such issues:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html

The tone should therefore have been more about tons of MUAs needing fixing. But
everything else seems hype.

Since CII started in part as a response to Heartbleed, and the badge program is
IMHO a success story considering the number of projects which have been shaping
up to meet the requirements, it has me thinking that despite the badge program
something is still missing here.

What could be done, from a community, or even CII perspective, to avoid further
cross channel miscommunication mishaps between security researchers and our broad
set of FOSS projects in the community?

Cc'ing two folks which I believe are not subscribed. Perhaps this is Off topic,
but, not sure where *else* could such a topic be discussed in a proactive
manner.

Luis


Re: GDPR - we think we're ready, let me know of any issues

Georg Link
 

Sounds reasonable, thanks David.

On Mon, May 14, 2018 at 5:24 PM, Wheeler, David A <dwheeler@...> wrote:

Georg Link:
> It might be helpful to additionally document how long activity logs are kept and when they are either anonymized or deleted. Because the goal "to detect and fix erroneous behavior, as well to detect and counter malicious behavior" might not require the data for eternity.

 

Fair enough.

 

The log of activity records requests to the system and related activity.  Logs are rotated daily and log data is archived for 1 year.  After that, it’s gone.

 

Some bugs are intermittent, and some attackers use “low and slow” kinds of attacks.  Thus, we need to log things for a period of time to deal with those cases.  A year seems like a reasonable period of time.

 

Does that help?

 

--- David A. Wheeler

 

Sent: Monday, May 14, 2018 5:55 PM
To: Wheeler, David A
Cc: cii-badges@lists.coreinfrastructure.org
Subject: Re: [CII-badges] GDPR - we think we're ready, let me know of any issues

 

Thanks David,

 

 

Best,

Georg

 

On Mon, May 14, 2018, 15:14 Wheeler, David A <dwheeler@...> wrote:


The system does store activity logs for all requests to the website.  These logs are necessary to detect and fix erroneous behavior, as well to detect and counter malicious behavior.  For logging to meet these requirements, it is necessary and important to record a variety of information, including the specific request, a summary of what action was performed on the request, the IP address of the requester, and also the user id of a logged-in user where relevant.  Therefore, our logs (like most logs) record this data (IP addresses and user id numbers).  We believe that being able to fix erroneous behaviors of the website, and counter malicious behaviors directed against this website, is a legitimate interest.  We do not use the logs for profiling users for marketing or anything like that; we use the logs to help ensure that the site continues to work in spite of errors or network attack.  We do not provide log data to external users, as that could breach others' privacy.  We b
 elieve this is fine under the GDPR; the GDPR requires "data portability" where consent is granted or the data is provided in performance of a contract, but log data is recorded to support a legitimate interest (and thus is not subject to data portability requirements).



Re: GDPR - we think we're ready, let me know of any issues

David A. Wheeler
 

Georg Link:
> It might be helpful to additionally document how long activity logs are kept and when they are either anonymized or deleted. Because the goal "to detect and fix erroneous behavior, as well to detect and counter malicious behavior" might not require the data for eternity.

 

Fair enough.

 

The log of activity records requests to the system and related activity.  Logs are rotated daily and log data is archived for 1 year.  After that, it’s gone.

 

Some bugs are intermittent, and some attackers use “low and slow” kinds of attacks.  Thus, we need to log things for a period of time to deal with those cases.  A year seems like a reasonable period of time.

 

Does that help?

 

--- David A. Wheeler

 

Sent: Monday, May 14, 2018 5:55 PM
To: Wheeler, David A
Cc: cii-badges@...
Subject: Re: [CII-badges] GDPR - we think we're ready, let me know of any issues

 

Thanks David,

 

 

Best,

Georg

 

On Mon, May 14, 2018, 15:14 Wheeler, David A <dwheeler@...> wrote:


The system does store activity logs for all requests to the website.  These logs are necessary to detect and fix erroneous behavior, as well to detect and counter malicious behavior.  For logging to meet these requirements, it is necessary and important to record a variety of information, including the specific request, a summary of what action was performed on the request, the IP address of the requester, and also the user id of a logged-in user where relevant.  Therefore, our logs (like most logs) record this data (IP addresses and user id numbers).  We believe that being able to fix erroneous behaviors of the website, and counter malicious behaviors directed against this website, is a legitimate interest.  We do not use the logs for profiling users for marketing or anything like that; we use the logs to help ensure that the site continues to work in spite of errors or network attack.  We do not provide log data to external users, as that could breach others' privacy.  We b
 elieve this is fine under the GDPR; the GDPR requires "data portability" where consent is granted or the data is provided in performance of a contract, but log data is recorded to support a legitimate interest (and thus is not subject to data portability requirements).


Re: GDPR - we think we're ready, let me know of any issues

Georg Link
 

Thanks David,

It might be helpful to additionally document how long activity logs are kept and when they are either anonymized or deleted. Because the goal "to detect and fix erroneous behavior, as well to detect and counter malicious behavior" might not require the data for eternity.

Best,
Georg


On Mon, May 14, 2018, 15:14 Wheeler, David A <dwheeler@...> wrote:

The system does store activity logs for all requests to the website.  These logs are necessary to detect and fix erroneous behavior, as well to detect and counter malicious behavior.  For logging to meet these requirements, it is necessary and important to record a variety of information, including the specific request, a summary of what action was performed on the request, the IP address of the requester, and also the user id of a logged-in user where relevant.  Therefore, our logs (like most logs) record this data (IP addresses and user id numbers).  We believe that being able to fix erroneous behaviors of the website, and counter malicious behaviors directed against this website, is a legitimate interest.  We do not use the logs for profiling users for marketing or anything like that; we use the logs to help ensure that the site continues to work in spite of errors or network attack.  We do not provide log data to external users, as that could breach others' privacy.  We b
 elieve this is fine under the GDPR; the GDPR requires "data portability" where consent is granted or the data is provided in performance of a contract, but log data is recorded to support a legitimate interest (and thus is not subject to data portability requirements).


May 16 - mailing list will undergo some changes

David A. Wheeler
 

All: On May 16th the CII-badges mailing list will undergo some changes, courtesy of the Linux Foundation’s IT group.

 

If the only thing you do is receive emails on the mailing list, I’m told that nothing should change for you.  But sometimes problems happen, so I thought it’d be wise to warn people now!

 

Thanks.

 

--- David A. Wheeler


GDPR - we think we're ready, let me know of any issues

David A. Wheeler
 

The EU General Data Protection Regulation (GDPR)'s official beginning enforcement date is 2018-05-25, which is just 11 days away.

As far as I know, we don't have any GDPR issues - but if you think we do, PLEASE let me know.

Below is a quick set of highlights of why we think we're okay from a GDPR viewpoint. This isn't a complete rationale for why we think we meet the GDPR, but hopefully it gives you a sense of the situation.

Now, a caveat. I'm a US citizen, who works for a US company, and I am *not* a lawyer. European law is *way* outside my field of expertise. What's more, the GDPR is intentionally worded in a very high-level aspirational way, making it a little hard for a non-lawyer to be sure we've addressed absolutely everything.

That said, I can say that we've honestly tried to meet and in many places exceed the GDPR requirements. We want the BadgeApp to respect user privacy, regardless of where the user lives. As always, please let us know if there's a problem.

Thank you!

--- David A. Wheeler

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

There are many reasons we think we don't have any GDPR issues. From the very beginning, we have always considered user privacy very important. For example:
* We *never* give user data to anyone else unless we're legally required to do so. We don't sell (or display) ads. We don't sell tracking info or perform services for others who want users tracked.
* We only use personal data to perform badge-related functions, for example, to authenticate users, to determine if users are authorized to make changes, to log which user modified data, to communicate with users (e.g., via email) about badge-related issues (including reminder emails and password resets), to help users grant edit rights to others, to help users ensure that they are granting addition rights to the correct user, to display to others who "owns" the project entry, and to display to others which users are allowed to make modifications.
* We don't collect/store much. The main private data we store is user email addresses. Email addresses are *only* used for badging-related activities. We do send reminders to projects who don't have passing badge, but those are focused emails to specific users who already specifically told us that they want to actively pursue a badge & yet have not made any edits for a long time. If a user keeps pursuing a badge (via edits), or the project gets a passing badge, that user will never see a reminder message. Reminder emails are NOT sent as part of a mailing list.
* Users can always delete their accounts at any time if they want to (though we hope they won't want to). I think that meets the "right of erasure" aka "right to be forgotten".
* Unlike many web sites, we *intentionally* directly host files (like jquery), and our links to social networks (like Facebook) do *NOT* provide any tracking data unless the user actively clicks on a link that social network.
* We have a really good security story. See: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md

The big issue we dealt with months ago was user "data portability" - a GDPR requirement that users be able to get data about themselves in some standard format. It's not clear how *useful* this is, because we don't store much information about users. That said, we don't need to apologize for "not storing much information about users". In any case, I think we've completely met that GDPR requirement - a while ago we added the ability for users to get information about themselves in JSON format.

The system does store activity logs for all requests to the website. These logs are necessary to detect and fix erroneous behavior, as well to detect and counter malicious behavior. For logging to meet these requirements, it is necessary and important to record a variety of information, including the specific request, a summary of what action was performed on the request, the IP address of the requester, and also the user id of a logged-in user where relevant. Therefore, our logs (like most logs) record this data (IP addresses and user id numbers). We believe that being able to fix erroneous behaviors of the website, and counter malicious behaviors directed against this website, is a legitimate interest. We do not use the logs for profiling users for marketing or anything like that; we use the logs to help ensure that the site continues to work in spite of errors or network attack. We do not provide log data to external users, as that could breach others' privacy. We believe this is fine under the GDPR; the GDPR requires "data portability" where consent is granted or the data is provided in performance of a contract, but log data is recorded to support a legitimate interest (and thus is not subject to data portability requirements).


Proposal: Minor clarification of license_location

David A. Wheeler
 

I’m proposing a minor clarification of the license_location criterion here:

  https://github.com/coreinfrastructure/best-practices-badge/issues/1133

 

Comments welcome!

 

--- 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 2018-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 dates2018-03-302018-04-29
Total Projects14591501
Projects 25%+526544
Projects 50%+449463
Projects 75%+357370
Projects passing159168

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

  1. Cloud Native Interactive Landscape at 2018-04-02 13:52:17 UTC
  2. mbt at 2018-04-03 23:08:20 UTC
  3. BIND9 at 2018-04-06 23:48:56 UTC
  4. byobu at 2018-04-09 01:53:28 UTC
  5. libcluon at 2018-04-13 19:16:24 UTC
  6. Fluentd at 2018-04-16 16:26:18 UTC
  7. vinnie at 2018-04-27 23:43:20 UTC
  8. Nelson numerical interpreter at 2018-04-29 09:27:23 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: Https links are not accepted in CII badging

David A. Wheeler
 

Seshu m:

 

The picture you sent me of:

  https://bestpractices.coreinfrastructure.org/en/projects/1702#sites_https

does show an “X” (unsatisfied criterion), but in the picture it appears that someone (at the time) expressly told the system that the criterion was “Unmet”.  That would be the correct result if the BadgeApp was told that this criterion was “Unmet”.  Our automated checkers will sometimes set something as “met” if they weren’t known before, but if a human expressly says they’re unmet, we normally presume the human is right.

 

It looks like someone has *CHANGED* the value of the sites_https criterion for project 1702 since you posted your question.  Here’s what I see.  Notice that it is now marked as “Met” and thus has a green checkmark (“satisfied”):

 

When I view the badging site, the only criterion left for ONAP is this one:

https://bestpractices.coreinfrastructure.org/en/projects/1702#vulnerabilities_fixed_60_days

 

In short, I think everything is working properly.  Please let me know if I’ve misunderstood something!

 

--- David A. Wheeler

 

 


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