Topics

Proposal: For sites_https, allow GitHub pages + custom domain + CloudFlare to implement HTTPS for project site


David A. Wheeler
 

All: *Many* projects use GitHub pages with custom domains, but GitHub does not natively support HTTPS if you’re using GitHub pages with custom domains.

I think we should make it clear that using a CDN like CloudFlare as a workaround is acceptable if you’re using GitHub pages with custom domains. This is a common solution. GitHub *does* support HTTPS if you’re not using custom domains (that was a change made earlier this year). Some background:
https://help.github.com/articles/securing-your-github-pages-site-with-https/
https://konklone.com/post/github-pages-now-sorta-supports-https-so-use-it
https://github.com/isaacs/github/issues/156

Create an explicit exception for users of Github Pages who implement a Cloudfare proxy according to <https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/>; and set the non-HTTPS pages to redirect to HTTPS.

The current sites_https criterion says: “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.  You can get free certificates from [Let's Encrypt](https://letsencrypt.org/)”

Proposed addition:
If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) such as CloudFlare as a proxy to support HTTPS; see <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure and fast GitHub Pages with CloudFlare</a>.

Thoughts?

--- David A. Wheeler


David A. Wheeler
 

Wheeler, David A said on Wednesday, December 21, 2016 4:22 PM:
I think we should make it clear that using a CDN like CloudFlare as a
workaround is acceptable if you’re using GitHub pages with custom domains.
I haven't heard *any* objections, never mind a groundswell of opposition. So here's a proposed pull request that adds the proposed clarification to criteria.yml:
https://github.com/linuxfoundation/cii-best-practices-badge/pull/548
I'll obviously have to make the equivalent changes to doc/criteria.md if this is acceptable.

While there are pros and cons, I think this is a perfectly reasonable interpretation... and since it's not clear, we need to make it clear.

If you have issues with the general idea, or with this specific pull request, please speak up ASAP! I intend to merge this tomorrow (Friday December 23) unless I hear something soon. This issue is important to some projects, and there doesn't seem to be a lot of pushback against the idea.

--- David A. Wheeler


Kevin W. Wall
 

Quick question: Are there any CDNs that the security community should
NOT accept as okay, e.g., ones that have poor reputation wrt security?
If so, we should list them or criteria of what makes them bad. (I can
understand not wanting to name names and invite lawsuits for
defamation though.)

-kevin

On Thu, Dec 22, 2016 at 6:58 PM, Wheeler, David A <dwheeler@ida.org> wrote:
Wheeler, David A said on Wednesday, December 21, 2016 4:22 PM:
I think we should make it clear that using a CDN like CloudFlare as a
workaround is acceptable if you’re using GitHub pages with custom domains.
I haven't heard *any* objections, never mind a groundswell of opposition. So here's a proposed pull request that adds the proposed clarification to criteria.yml:
https://github.com/linuxfoundation/cii-best-practices-badge/pull/548
I'll obviously have to make the equivalent changes to doc/criteria.md if this is acceptable.

While there are pros and cons, I think this is a perfectly reasonable interpretation... and since it's not clear, we need to make it clear.

If you have issues with the general idea, or with this specific pull request, please speak up ASAP! I intend to merge this tomorrow (Friday December 23) unless I hear something soon. This issue is important to some projects, and there doesn't seem to be a lot of pushback against the idea.

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
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.


Mark Rader
 

David

For your explicit exception

Create an explicit exception for users of Github Pages who implement a Cloudfare proxy according to <https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/> and set the non-HTTPS pages to redirect to HTTPS.

Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.

Mark

On Wed, Dec 21, 2016 at 3:22 PM, Wheeler, David A <dwheeler@...> wrote:
All: *Many* projects use GitHub pages with custom domains, but GitHub does not natively support HTTPS if you’re using GitHub pages with custom domains.

I think we should make it clear that using a CDN like CloudFlare as a workaround is acceptable if you’re using GitHub pages with custom domains.  This is a common solution.  GitHub *does* support HTTPS if you’re not using custom domains (that was a change made earlier this year).  Some background:
https://help.github.com/articles/securing-your-github-pages-site-with-https/
https://konklone.com/post/github-pages-now-sorta-supports-https-so-use-it
https://github.com/isaacs/github/issues/156

Create an explicit exception for users of Github Pages who implement a Cloudfare proxy according to <https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/> and set the non-HTTPS pages to redirect to HTTPS.

The current sites_https criterion says: “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.  You can get free certificates from [Let's Encrypt](https://letsencrypt.org/)

Proposed addition:
If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) such as CloudFlare as a proxy to support HTTPS; see <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure and fast GitHub Pages with CloudFlare</a>.

Thoughts?

--- David A. Wheeler

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


David A. Wheeler
 

Quick question: Are there any CDNs that the security community should NOT
accept as okay, e.g., ones that have poor reputation wrt security?
If so, we should list them or criteria of what makes them bad. (I can
understand not wanting to name names and invite lawsuits for defamation
though.)
We could list criteria-for-criteria, but that would get really complex, I don't think that's a problem (and thus it's not worth trying to counter). CDNs have financial incentives to do a better job, and in practice there aren't many of them. Besides, the same could be said of HTTPS hosting sites. We can't require everything - we need people to be able to read & apply the criteria.

Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.
Any equivalent. I think it's very important to *not* mandate a specific vendor or technology.

Here's the proposed text, straight from https://github.com/linuxfoundation/cii-best-practices-badge/pull/548/files

+ If you are using GitHub pages without a custom domain, you can simply
+ <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/";>change its settings to enforce HTTPS</a>.
+ If you are using GitHub pages with a custom
+ domain, you MAY use a content delivery network
+ (CDN) such as CloudFlare as a proxy to support HTTPS; see <a
+ href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure
+ and fast GitHub Pages with CloudFlare</a>.
+ A project MAY also support HTTP, though we
+ encourage users to use HTTPS instead.

--- David A. Wheeler


Dan Kohn
 

I would change the end to be: we encourage projects to redirect http traffic to https. Counting on users to do the right thing seems hopeless. 


On Fri, Dec 23, 2016 at 09:01 Wheeler, David A <dwheeler@...> wrote:
> Quick question: Are there any CDNs that the security community should NOT

> accept as okay, e.g., ones that have poor reputation wrt security?

> If so, we should list them or criteria of what makes them bad. (I can

> understand not wanting to name names and invite lawsuits for defamation

> though.)



We could list criteria-for-criteria, but that would get really complex, I don't think that's a problem (and thus it's not worth trying to counter).  CDNs have financial incentives to do a better job, and in practice there aren't many of them.  Besides, the same could be said of HTTPS hosting sites.  We can't require everything - we need people to be able to read & apply the criteria.



> Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.



Any equivalent.  I think it's very important to *not* mandate a specific vendor or technology.



Here's the proposed text, straight from https://github.com/linuxfoundation/cii-best-practices-badge/pull/548/files



+          If you are using GitHub pages without a custom domain, you can simply

+          <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/">change its settings to enforce HTTPS</a>.

+          If you are using GitHub pages with a custom

+          domain, you MAY use a content delivery network

+          (CDN) such as CloudFlare as a proxy to support HTTPS; see <a

+          href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure

+          and fast GitHub Pages with CloudFlare</a>.

+          A project MAY also support HTTP, though we

+          encourage users to use HTTPS instead.



--- David A. Wheeler



_______________________________________________

CII-badges mailing list

CII-badges@...

https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


David A. Wheeler
 

Ok. Here's what I think that means...

change:
A project MAY also support HTTP, though we encourage users to use HTTPS instead.
to:
A project MAY also support HTTP, though we encourage projects to redirect HTTP traffic to HTTPS.
--- David A. Wheeler


Daniel Stenberg
 

On Fri, 23 Dec 2016, Wheeler, David A wrote:

A project MAY also support HTTP, though we encourage projects to redirect HTTP traffic to HTTPS.
I actually think that in 2017, that is about to start after all, there is *no* and I really mean zero, reasons to not offer all relevant info and services over HTTPS. I don't think there's any room left for a "MAY" do HTTP.

Sure, there are server and hosting offerings that don't give the users HTTPS. That's a perfect reason to NOT use them and NOT host your open source on those services.

I think a 100% best-practices project in 2017 shouldn't have anything significant on HTTP.

--

/ daniel.haxx.se


Mark Rader
 

David

Or maybe make that a criteria for moving from level 1 to level n.

Migration from http to https.


Mark

On Dec 23, 2016, at 9:55 AM, Daniel Stenberg <daniel@haxx.se> wrote:

On Fri, 23 Dec 2016, Wheeler, David A wrote:

A project MAY also support HTTP, though we encourage projects to redirect HTTP traffic to HTTPS.
I actually think that in 2017, that is about to start after all, there is *no* and I really mean zero, reasons to not offer all relevant info and services over HTTPS. I don't think there's any room left for a "MAY" do HTTP.

Sure, there are server and hosting offerings that don't give the users HTTPS. That's a perfect reason to NOT use them and NOT host your open source on those services.

I think a 100% best-practices project in 2017 shouldn't have anything significant on HTTP.

--

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


David A. Wheeler
 

-----Original Message-----
From: Daniel Stenberg [mailto:daniel@haxx.se]
I actually think that in 2017, that is about to start after all, there is *no* and I
really mean zero, reasons to not offer all relevant info and services over HTTPS.
And that's what this criterion already requires.

BTW, this is currently one of the most common criteria that projects *fail* at. For example, any project on Savannah (such as GNU make, binutils including cp, etc.) cannot currently meet this requirement, because Savannah doesn't support HTTPS for repos (!).

Even so, I think we should retain this criterion as-is. After some pleading by myself and others, the Savannah maintainers have agreed to add HTTPS for repos... it's just not there yet.


I don't think there's any room left for a "MAY" do HTTP.
That's different. The criterion currently requires HTTPS support, but it intentionally does not forbid HTTP support. Since HTTP support isn't forbidden, it is *already* permitted.

Explicitly *forbidding* HTTP support would be a big change to the "passing" criteria, and I think that's too harsh for "passing" at this time. We generally only have "passing" criteria if a lot of projects meet it already, and currently a *lot* of sites also support HTTP for a variety of reasons. Heck, we're having trouble getting projects to support HTTPS at all, never mind also dropping HTTP. In addition, users can *easily* see on their web browser if they're using HTTP or HTTPS, so the risks of *unknowingly* using HTTP are much smaller.

I agree with your point that supporting HTTPS-only would be better. However, because so many are *not* in that situation, let's add it to "passing+1" first . It'll be easier to have it trickle down later, and I expect it'll be a lot easier to forbid HTTP after a little more time. Something like this:

* The project sites (website, repository, and download URLs) MUST NOT support HTTP other than optionally upgrading HTTP requests to HTTPS requests.

--- David A. Wheeler


Kevin W. Wall
 

That's fine, but I think that it should be worded so that it doesn't come across as an endorsement for CloudFlare. E.g.,

     such as CloudFlare, Akamai, Rackspace, MaxCDN, <insert-your-favorite-CDN-provider-here>, etc.

At least then it won't be seen as an endorsement for any specific one.

Otherwise, I'm fine with the proposed wording.

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

On Dec 23, 2016 09:01, "Wheeler, David A" <dwheeler@...> wrote:
> Quick question: Are there any CDNs that the security community should NOT
> accept as okay, e.g., ones that have poor reputation wrt security?
> If so, we should list them or criteria of what makes them bad. (I can
> understand not wanting to name names and invite lawsuits for defamation
> though.)

We could list criteria-for-criteria, but that would get really complex, I don't think that's a problem (and thus it's not worth trying to counter).  CDNs have financial incentives to do a better job, and in practice there aren't many of them.  Besides, the same could be said of HTTPS hosting sites.  We can't require everything - we need people to be able to read & apply the criteria.

> Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.

Any equivalent.  I think it's very important to *not* mandate a specific vendor or technology.

Here's the proposed text, straight from https://github.com/linuxfoundation/cii-best-practices-badge/pull/548/files

+          If you are using GitHub pages without a custom domain, you can simply
+          <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/">change its settings to enforce HTTPS</a>.
+          If you are using GitHub pages with a custom
+          domain, you MAY use a content delivery network
+          (CDN) such as CloudFlare as a proxy to support HTTPS; see <a
+          href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure
+          and fast GitHub Pages with CloudFlare</a>.
+          A project MAY also support HTTP, though we
+          encourage users to use HTTPS instead.

--- David A. Wheeler



Dan Kohn
 

We currently say:

The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.  You can get free certificates from [Let's Encrypt](https://letsencrypt.org/).

I would suggest adding:

If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this requirement. If you use a CDN in this manner, you SHOULD redirect HTTP traffic to use HTTPS.

On Fri, Dec 23, 2016 at 1:17 PM, Kevin W. Wall <kevin.w.wall@...> wrote:
That's fine, but I think that it should be worded so that it doesn't come across as an endorsement for CloudFlare. E.g.,

     such as CloudFlare, Akamai, Rackspace, MaxCDN, <insert-your-favorite-CDN-provider-here>, etc.

At least then it won't be seen as an endorsement for any specific one.

Otherwise, I'm fine with the proposed wording.

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

On Dec 23, 2016 09:01, "Wheeler, David A" <dwheeler@...> wrote:
> Quick question: Are there any CDNs that the security community should NOT
> accept as okay, e.g., ones that have poor reputation wrt security?
> If so, we should list them or criteria of what makes them bad. (I can
> understand not wanting to name names and invite lawsuits for defamation
> though.)

We could list criteria-for-criteria, but that would get really complex, I don't think that's a problem (and thus it's not worth trying to counter).  CDNs have financial incentives to do a better job, and in practice there aren't many of them.  Besides, the same could be said of HTTPS hosting sites.  We can't require everything - we need people to be able to read & apply the criteria.

> Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.

Any equivalent.  I think it's very important to *not* mandate a specific vendor or technology.

Here's the proposed text, straight from https://github.com/linuxfoundation/cii-best-practices-badge/pull/548/files

+          If you are using GitHub pages without a custom domain, you can simply
+          <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/">change its settings to enforce HTTPS</a>.
+          If you are using GitHub pages with a custom
+          domain, you MAY use a content delivery network
+          (CDN) such as CloudFlare as a proxy to support HTTPS; see <a
+          href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure
+          and fast GitHub Pages with CloudFlare</a>.
+          A project MAY also support HTTP, though we
+          encourage users to use HTTPS instead.

--- David A. Wheeler



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




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


David A. Wheeler
 

From: Dan Kohn [mailto:dan@linuxfoundation.org]
If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this requirement. If you use a CDN in this manner, you SHOULD redirect HTTP traffic to use HTTPS.
I like this, mainly because "list all CDNs" is a problem itself :-). Technically the last part is an additional requirement, and it's not good to mix SHOULD and MUST in the same sentence... maybe we can get away with it in this case?!

--- David A. Wheeler


David A. Wheeler
 

All:

I think we're getting closer to the "detail text" for criterion sites_https, one that makes it clear that CDN proxies are okay. I really appreciate the feedback. Here's a new version that hopefully merges everyone's comments as well as recent information that's become available.

Just to recall, for criterion "sites_http" the current requirement text (which will be unchanged) is:
The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.
The current detail is:
You can get free certificates from <a href="https://letsencrypt.org/";>Let's Encrypt</a>.
Dan Kohn posted an updated addition to the detail based on earlier comments, and it nicely avoided trying to "list all CDNs" by adding this:
If you are using GitHub pages with custom domains, you MAY use a content
delivery network (CDN) as a proxy to support HTTPS, such as described in this
<a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-
cloudflare/”>blog post</a>, to satisfy this requirement. If you use a CDN in
this manner, you SHOULD redirect HTTP traffic to use HTTPS.
That's a nice start, but I think there are some tweaks we should do:
* It includes a "SHOULD", but we've learned that trying to combine SHOULD and MUST in a single criterion is a problem. The problem is that both MUST and SHOULD are keywords with different specific defined meanings, and the actual criterion text uses MUST. Let's avoid using SHOULD, and just use some other phrase like "urge" (or perhaps "encourage" or even "strongly encourage"). We could define that term earlier.
* As written it seems to suggest that you should always support HTTP. I think *only* supporting HTTPS is just fine, and in fact, many people are moving that way. Let's not encourage people to re-add HTTP if they only support HTTPS! So instead, let's say something like "If you support HTTP, we urge you to redirect to HTTPS". If we just use "urge" instead of a keyword like "SHOULD" then I think we can simply say that in all cases (we're not specifically requiring it). I think this might be plausible as a new criterion, but let's make it a separate criterion - it's not something we've required up to this point, so changing the requirement might lead to people silently failing to meet it.
* We now have several repos that directly support HTTPS, but you typically have to do something to make it work. I think we should add a few links for them too. Last I checked, sites_https is one of the most-missed criterion, so giving people some specific help and pointers might make this easier to implement.

So, here's the proposed updated detail:
You can get free certificates from <a href="https://letsencrypt.org/";>Let's Encrypt</a>.
Projects MAY implement this criterion using (for example)
<a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/";>GitHub pages</a>,
<a href="https://about.gitlab.com/2016/12/24/were-bringing-gitlab-pages-to-community-edition/";>GitLab pages</a>, or
<a href="https://sourceforge.net/blog/introducing-https-for-project-websites/";>SourceForge project pages</a>.
If you are using GitHub pages with custom domains, you MAY use a
content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this criterion. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS.

Thoughts?

--- David A. Wheeler


Dan Kohn
 

+1

On Wed, Dec 28, 2016 at 8:26 AM, Wheeler, David A <dwheeler@...> wrote:
All:

I think we're getting closer to the "detail text" for criterion sites_https, one that makes it clear that CDN proxies are okay.  I really appreciate the feedback.  Here's a new version that hopefully merges everyone's comments as well as recent information that's become available.

Just to recall, for criterion "sites_http" the current requirement text (which will be unchanged) is:
> The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.
The current detail is:
> You can get free certificates from <a href="https://letsencrypt.org/">Let's Encrypt</a>.

Dan Kohn posted an updated addition to the detail based on earlier comments, and it nicely avoided trying to "list all CDNs" by adding this:
> If you are using GitHub pages with custom domains, you MAY use a content
> delivery network (CDN) as a proxy to support HTTPS, such as described in this
> <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-
> cloudflare/”>blog post</a>, to satisfy this requirement. If you use a CDN in
> this manner, you SHOULD redirect HTTP traffic to use HTTPS.

That's a nice start, but I think there are some tweaks we should do:
* It includes a "SHOULD", but we've learned that trying to combine SHOULD and MUST in a single criterion is a problem.  The problem is that both MUST and SHOULD are keywords with different specific defined meanings, and the actual criterion text uses MUST.  Let's avoid using SHOULD, and just use some other phrase like "urge" (or perhaps "encourage" or even "strongly encourage").  We could define that term earlier.
* As written it seems to suggest that you should always support HTTP.  I think *only* supporting HTTPS is just fine, and in fact, many people are moving that way.  Let's not encourage people to re-add HTTP if they only support HTTPS!  So instead, let's say something like "If you support HTTP, we urge you to redirect to HTTPS".  If we just use "urge" instead of a keyword like "SHOULD" then I think we can simply say that in all cases (we're not specifically requiring it).  I think this might be plausible as a new criterion, but let's make it a separate criterion - it's not something we've required up to this point, so changing the requirement might lead to people silently failing to meet it.
* We now have several repos that directly support HTTPS, but you typically have to do something to make it work.  I think we should add a few links for them too.  Last I checked, sites_https is one of the most-missed criterion, so giving people some specific help and pointers might make this easier to implement.

So, here's the proposed updated detail:
You can get free certificates from <a href="https://letsencrypt.org/">Let's Encrypt</a>.
Projects MAY implement this criterion using (for example)
<a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/">GitHub pages</a>,
<a href="https://about.gitlab.com/2016/12/24/were-bringing-gitlab-pages-to-community-edition/">GitLab pages</a>, or
<a href="https://sourceforge.net/blog/introducing-https-for-project-websites/">SourceForge project pages</a>.
If you are using GitHub pages with custom domains, you MAY use a
content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this criterion. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS.

Thoughts?

--- David A. Wheeler

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



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