Date   

Re: FYI: Sam Lambert (GitHub) elected on the TOC

Ihor Dvoretskyi
 

Congratulations, Sam!

On Mon, Oct 2, 2017 at 11:47 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Hey TOC and wider CNCF community, just wanted to let you know our election ended for the End User TOC seat today: https://github.com/cncf/toc/blob/master/process/election-schedule.md

Sam Lambert won the election and will be joining us on the TOC officially, representing the end user community: https://www.cncf.io/people/end-user-community/

Sam is a Senior Director of Infrastructure Engineering at GitHub and as you're aware, GitHub has recently started to adopt Kubernetes in a big way: https://githubengineering.com/kubernetes-at-github (they are also users of other CNCF projects too).

Anyways, everyone please welcome Sam to the community!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



FYI: Sam Lambert (GitHub) elected on the TOC

Chris Aniszczyk
 

Hey TOC and wider CNCF community, just wanted to let you know our election ended for the End User TOC seat today: https://github.com/cncf/toc/blob/master/process/election-schedule.md

Sam Lambert won the election and will be joining us on the TOC officially, representing the end user community: https://www.cncf.io/people/end-user-community/

Sam is a Senior Director of Infrastructure Engineering at GitHub and as you're aware, GitHub has recently started to adopt Kubernetes in a big way: https://githubengineering.com/kubernetes-at-github (they are also users of other CNCF projects too).

Anyways, everyone please welcome Sam to the community!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] Notary/TUF project proposal (incubation)

Quinton Hoole
 

+1 (non-binding)

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc-bounces@...> on behalf of Benjamin Hindman via cncf-toc <cncf-toc@...>
Reply-To: Benjamin Hindman <benh@...>
Date: Monday, October 2, 2017 at 09:25
To: Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Notary/TUF project proposal (incubation)

+1

On Mon, Oct 2, 2017 at 8:41 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

All New DC/OS 1.10 


Re: [VOTE] Notary/TUF project proposal (incubation)

Benjamin Hindman
 

+1

On Mon, Oct 2, 2017 at 8:41 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

All New DC/OS 1.10 


Re: [VOTE] Notary/TUF project proposal (incubation)

Justin Cormack
 

+1 (non binding)

On Mon, Oct 2, 2017 at 4:41 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] Notary/TUF project proposal (incubation)

Gomez, Emmanuel <Emmanuel.Gomez@...>
 

+1, non-binding

On Oct 2, 2017, at 9:18 AM, Jon Mittelhauser via cncf-toc <cncf-toc@...> wrote:

+1
 
From: <cncf-toc-bounces@...> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Monday, October 2, 2017 at 9:11 AM
To: Alexis Richardson <alexis@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Notary/TUF project proposal (incubation)
 
+1
 
On Mon, Oct 2, 2017 at 8:46 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
+1
 
 
On Mon, Oct 2, 2017 at 4:41 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:
 
The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.
 
Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38
 
Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!
 
-- 
Chris Aniszczyk (@cra) | +1-512-961-6719
 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

 


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

 
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [VOTE] Notary/TUF project proposal (incubation)

Solomon Hykes
 

+1


On Monday, October 2, 2017, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] Notary/TUF project proposal (incubation)

Jon Mittelhauser
 

+1

 

From: <cncf-toc-bounces@...> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Monday, October 2, 2017 at 9:11 AM
To: Alexis Richardson <alexis@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Notary/TUF project proposal (incubation)

 

+1

 

On Mon, Oct 2, 2017 at 8:46 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

+1

 

 

On Mon, Oct 2, 2017 at 4:41 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:

The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

 

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

 

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

 

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719

 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

 


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

 

_______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=LSrohUjRVWJ_ZB3WX4hfagBYNZgHw_zIDvNmFnO1u8M&m=u-fZ88UTyig6NOLsMFwpLVC36xVfDGMk--25XIefxqQ&s=4_iFNbz6MUu7f7TpgpmWeIL8GhsJ5T0u-Y3wqVnKMQU&e=


Re: [VOTE] Notary/TUF project proposal (incubation)

Brian Grant
 

+1

On Mon, Oct 2, 2017 at 8:46 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
+1


On Mon, Oct 2, 2017 at 4:41 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: [VOTE] Notary/TUF project proposal (incubation)

alexis richardson
 

+1


On Mon, Oct 2, 2017 at 4:41 PM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



[VOTE] Notary/TUF project proposal (incubation)

Chris Aniszczyk
 

The TOC has decided to invite Notary (https://github.com/docker/notary) and the TUF (https://github.com/theupdateframework) as an incubation level CNCF project, sponsored by Solomon Hykes from the TOC:

The Update Framework (TUF) is a specification designed to solve specifically provenance and trust problems as part of a larger distribution framework. Notary is a content signing framework implementing the TUF specification in the Go language. The project provides both a client, and a pair of server applications to host signed metadata and perform limited online signing functions.

Please vote (+1/0/-1) on the full project proposal located here on GitHub: https://github.com/cncf/toc/pull/38

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: TOC Agenda for 10/3/17

Chris Aniszczyk
 

...and of course I sent the email out early, here's the deck: https://goo.gl/nsYz4j

See everyone Tuesday.

On Sun, Oct 1, 2017 at 7:58 PM, Chris Aniszczyk <caniszczyk@...> wrote:
Here's the deck for


--
Chris Aniszczyk (@cra) | +1-512-961-6719



--
Chris Aniszczyk (@cra) | +1-512-961-6719


TOC Agenda for 10/3/17

Chris Aniszczyk
 

Here's the deck for


--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Notary/TUF: marshalled and ready to activate

Chris Aniszczyk
 

Thanks Quinton for the detailed followup.

I plan on calling a vote by Monday at the latest.

On Mon, Sep 25, 2017 at 5:52 PM, Quinton Hoole via cncf-toc <cncf-toc@...> wrote:
I think we’re good to go, with the caveat that the comparison matrices covering other update frameworks are still somewhat misleading and/or inaccurate (depending on your perspective), and should IMO be disregarded, and ultimately updated or deleted.

Most widely used trusted software update mechanisms can, in practice, check most of the boxes in the matrices, but TUF/Notary consolidates the required functionality into a single, well-defined, reviewed framework.

As long as we’re clear on that, I think that we have all of the info necessary to vote.  Thanks to the Notary folks (and @endophage in particular) for your diligence and patience attempting to address all of the questions and concerns expressed.

FYI to the voting TOC members as context, below are a few illustrative comments that have been made by the community regarding the comparison matrices:


FWIW, the YUM part above is not correct as such.

At SUSE we use GPG detach signed YUM repositories and it gives most if not all security features needed.

YUM has a root repomd.xml with sha256 hashes of dependend files all the way down. SUSE and likely others sign to repomd.xml with a trusted GPG key with detached signature.

  • freshness: at SUSE we have added an expiry tag to guarantee this
  • mix and match: is caught implicitly (the whole YUM repo is signed as a single blob)
  • endless data attack: needs to be caught by YUM processing stack, YUM format includes sizes everywhere
  • extraneous dependencies: implictly caught (whole YUM state is signed as a single blob)
  • fast forward: implicitly caught (whole YUM state is signed as a single blob)
  • indefinite freeze: caught by freshness attribute
  • malicious mirrors ... well, notary has the same trouble. the freshness will show this to the user.
  • rollback attacks: depends on how YUM is used, but RPM based installations usually only have increasing versions only.
  • slow retrieval: depends on YUM downloader, but with the sizes known ahead in YUM its at the same level as in TUF

What is a problem is that YUM is a bit RPM centric and does not support plain files, so a new XML part that handles generic files would need to be added.

I also admit that key handling is limited to a single GPG key signing the whole YUM repository instead of multiple roles/keys like in Notary, so some of the key attacks are present in YUM+GPG.

But its not as bad as your graphics makes it to be.


————————


https://github.com/cncf/toc/pull/38#issuecomment-329091834


I just spoke to one of the APT developers while at OSS and it appears that Debian/Ubuntu packaging also solves most of the problems you've marked as "not handled" (similarly to what @msmeissn has been describing for zypper/yumrepo). I would be also shocked to discover that RedHat's dnf and yum do not solve these problems (to the same degree as zypper/apt/etc) as well…


———————


https://github.com/cncf/toc/pull/38#issuecomment-329758267


…I agree however, that the comparison table should be updated to match how the actual package managers in distributions behave to mitigate individual risks.


————————


It is clear that many of the Linux vendors have started to construct parts of a protocol set similar to TUF using GPG, but there does not appear to be a formal reviewed specification in the same way as TUF has defined, with detailed security review, at least as far as I can find. The discussion about which boxes in the table should be ticked, and the fact that no one can easily find definitive answers does suggest that the specification is ad hoc rather than formally specified like TUF, or the answers would be much easier to find.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc-bounces@....io> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Friday, September 22, 2017 at 06:33
To: Alexis Richardson <alexis@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Notary/TUF: marshalled and ready to activate

I am ready

On Sep 22, 2017 1:16 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:
Hi all

I think we are ready to start soliciting votes for Notary.  Please shout now if you disagree, especially if you have been a TOC Contributor carrying out DD.

There were questions about TUF.

My understanding from OCI is that container signatures are expected to be attached metadata that could be associated with any popular method eg gpg, tuf.  If the OCI standardise this then they will focus on making it possible to attach signatures, rather than on picking gpg vs tuf for example.

By the same token (no pun intended) the CNCF is not, I repeat not, blessing a standard.  We should make this clear beyond the possibility of confusion.  TUF is a spec.  But we are not saying it is a standard.  See the github thread for more.

I want to thank Dan and all the DD folks for help thus far.

Are we ready to start voting?


Alexis




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: Notary/TUF: marshalled and ready to activate

Quinton Hoole
 

I think we’re good to go, with the caveat that the comparison matrices covering other update frameworks are still somewhat misleading and/or inaccurate (depending on your perspective), and should IMO be disregarded, and ultimately updated or deleted.

Most widely used trusted software update mechanisms can, in practice, check most of the boxes in the matrices, but TUF/Notary consolidates the required functionality into a single, well-defined, reviewed framework.

As long as we’re clear on that, I think that we have all of the info necessary to vote.  Thanks to the Notary folks (and @endophage in particular) for your diligence and patience attempting to address all of the questions and concerns expressed.

FYI to the voting TOC members as context, below are a few illustrative comments that have been made by the community regarding the comparison matrices:


FWIW, the YUM part above is not correct as such.

At SUSE we use GPG detach signed YUM repositories and it gives most if not all security features needed.

YUM has a root repomd.xml with sha256 hashes of dependend files all the way down. SUSE and likely others sign to repomd.xml with a trusted GPG key with detached signature.

  • freshness: at SUSE we have added an expiry tag to guarantee this
  • mix and match: is caught implicitly (the whole YUM repo is signed as a single blob)
  • endless data attack: needs to be caught by YUM processing stack, YUM format includes sizes everywhere
  • extraneous dependencies: implictly caught (whole YUM state is signed as a single blob)
  • fast forward: implicitly caught (whole YUM state is signed as a single blob)
  • indefinite freeze: caught by freshness attribute
  • malicious mirrors ... well, notary has the same trouble. the freshness will show this to the user.
  • rollback attacks: depends on how YUM is used, but RPM based installations usually only have increasing versions only.
  • slow retrieval: depends on YUM downloader, but with the sizes known ahead in YUM its at the same level as in TUF

What is a problem is that YUM is a bit RPM centric and does not support plain files, so a new XML part that handles generic files would need to be added.

I also admit that key handling is limited to a single GPG key signing the whole YUM repository instead of multiple roles/keys like in Notary, so some of the key attacks are present in YUM+GPG.

But its not as bad as your graphics makes it to be.


————————


https://github.com/cncf/toc/pull/38#issuecomment-329091834


I just spoke to one of the APT developers while at OSS and it appears that Debian/Ubuntu packaging also solves most of the problems you've marked as "not handled" (similarly to what @msmeissn has been describing for zypper/yumrepo). I would be also shocked to discover that RedHat's dnf and yum do not solve these problems (to the same degree as zypper/apt/etc) as well…


———————


https://github.com/cncf/toc/pull/38#issuecomment-329758267


…I agree however, that the comparison table should be updated to match how the actual package managers in distributions behave to mitigate individual risks.


————————


It is clear that many of the Linux vendors have started to construct parts of a protocol set similar to TUF using GPG, but there does not appear to be a formal reviewed specification in the same way as TUF has defined, with detailed security review, at least as far as I can find. The discussion about which boxes in the table should be ticked, and the fact that no one can easily find definitive answers does suggest that the specification is ad hoc rather than formally specified like TUF, or the answers would be much easier to find.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc-bounces@...> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Friday, September 22, 2017 at 06:33
To: Alexis Richardson <alexis@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Notary/TUF: marshalled and ready to activate

I am ready

On Sep 22, 2017 1:16 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:
Hi all

I think we are ready to start soliciting votes for Notary.  Please shout now if you disagree, especially if you have been a TOC Contributor carrying out DD.

There were questions about TUF.

My understanding from OCI is that container signatures are expected to be attached metadata that could be associated with any popular method eg gpg, tuf.  If the OCI standardise this then they will focus on making it possible to attach signatures, rather than on picking gpg vs tuf for example.

By the same token (no pun intended) the CNCF is not, I repeat not, blessing a standard.  We should make this clear beyond the possibility of confusion.  TUF is a spec.  But we are not saying it is a standard.  See the github thread for more.

I want to thank Dan and all the DD folks for help thus far.

Are we ready to start voting?


Alexis




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: Notary/TUF: marshalled and ready to activate

Brian Grant
 

I am ready

On Sep 22, 2017 1:16 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:
Hi all

I think we are ready to start soliciting votes for Notary.  Please shout now if you disagree, especially if you have been a TOC Contributor carrying out DD.

There were questions about TUF.

My understanding from OCI is that container signatures are expected to be attached metadata that could be associated with any popular method eg gpg, tuf.  If the OCI standardise this then they will focus on making it possible to attach signatures, rather than on picking gpg vs tuf for example.

By the same token (no pun intended) the CNCF is not, I repeat not, blessing a standard.  We should make this clear beyond the possibility of confusion.  TUF is a spec.  But we are not saying it is a standard.  See the github thread for more.

I want to thank Dan and all the DD folks for help thus far.

Are we ready to start voting?


Alexis




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Re: TOC Principles pull request

alexis richardson
 

Dan,

Thank-you.   I think the TOC & community could probably get to voting soon.  It would be even better if the broader CNCF was +1 too.  Eg: GB, EUC, ...

Would it be possible for you and Todd (cc'd) to rally round some of the GB and make sure they are ok with the text?  For example Ike (cc'd) had some questions about governance that were in the g/doc comments.  

alexis


On Fri, Sep 22, 2017 at 12:00 PM, Dan Kohn <dan@...> wrote:
The pull request has been open for 5 days, but the original document that the wording is taken from was published months ago.

Alexis, I think it's appropriate for you to call for a vote on approving the TOC principles if you're ready.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io

On Fri, Sep 22, 2017 at 2:52 AM, Alexis Richardson <alexis@...> wrote:

GovOps? GitGov?


On Fri, 22 Sep 2017, 06:33 Brian Grant <briangrant@...> wrote:
Thanks. LGTM. There don't appear to be any comments. I'm itching to click the merge button. :-)

On Mon, Sep 18, 2017 at 12:45 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

Thanks Dan

All, please do take a last look over the g/doc comments.  If you see discussion there that you feel is not in GH or still unresolved, please update the GH doc.

Alexis


On Mon, 18 Sep 2017, 04:01 Dan Kohn via cncf-toc <cncf-toc@...> wrote:
I took the TOC Principles document created by several TOC members and:

1. Converted it to markdown.
2. Left out the notes and comments on the budget.

The notes and comments are important (and remain in the original Google Doc), but will hopefully be addressed by the CNCF ServiceDesk and Service Dashboard that we'll be announcing in the next couple weeks.

For now, the TOC and I would appreciate your comments on the Principles themselves. If you don't think they adequately describe the way the TOC operates (and/or how it should operate), then please comment on the pull request.

Once comments are addressed, the goal is for the TOC to vote that this document represents the TOC Principles, and to have the CNCF governing board vote to endorse the Principles as well.

Rendered version

Pull request (comments welcome)

TOC Principles (i.e., the original document)

Thanks.
--
Dan Kohn <mailto:dan@...g>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc





Re: TOC Principles pull request

Dan Kohn <dan@...>
 

The pull request has been open for 5 days, but the original document that the wording is taken from was published months ago.

Alexis, I think it's appropriate for you to call for a vote on approving the TOC principles if you're ready.

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

On Fri, Sep 22, 2017 at 2:52 AM, Alexis Richardson <alexis@...> wrote:

GovOps? GitGov?


On Fri, 22 Sep 2017, 06:33 Brian Grant <briangrant@...> wrote:
Thanks. LGTM. There don't appear to be any comments. I'm itching to click the merge button. :-)

On Mon, Sep 18, 2017 at 12:45 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

Thanks Dan

All, please do take a last look over the g/doc comments.  If you see discussion there that you feel is not in GH or still unresolved, please update the GH doc.

Alexis


On Mon, 18 Sep 2017, 04:01 Dan Kohn via cncf-toc <cncf-toc@...> wrote:
I took the TOC Principles document created by several TOC members and:

1. Converted it to markdown.
2. Left out the notes and comments on the budget.

The notes and comments are important (and remain in the original Google Doc), but will hopefully be addressed by the CNCF ServiceDesk and Service Dashboard that we'll be announcing in the next couple weeks.

For now, the TOC and I would appreciate your comments on the Principles themselves. If you don't think they adequately describe the way the TOC operates (and/or how it should operate), then please comment on the pull request.

Once comments are addressed, the goal is for the TOC to vote that this document represents the TOC Principles, and to have the CNCF governing board vote to endorse the Principles as well.

Rendered version

Pull request (comments welcome)

TOC Principles (i.e., the original document)

Thanks.
--
Dan Kohn <mailto:dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




Notary/TUF: marshalled and ready to activate

alexis richardson
 

Hi all

I think we are ready to start soliciting votes for Notary.  Please shout now if you disagree, especially if you have been a TOC Contributor carrying out DD.

There were questions about TUF.

My understanding from OCI is that container signatures are expected to be attached metadata that could be associated with any popular method eg gpg, tuf.  If the OCI standardise this then they will focus on making it possible to attach signatures, rather than on picking gpg vs tuf for example.

By the same token (no pun intended) the CNCF is not, I repeat not, blessing a standard.  We should make this clear beyond the possibility of confusion.  TUF is a spec.  But we are not saying it is a standard.  See the github thread for more.

I want to thank Dan and all the DD folks for help thus far.

Are we ready to start voting?


Alexis




Re: TOC Principles pull request

alexis richardson
 

GovOps? GitGov?


On Fri, 22 Sep 2017, 06:33 Brian Grant <briangrant@...> wrote:
Thanks. LGTM. There don't appear to be any comments. I'm itching to click the merge button. :-)

On Mon, Sep 18, 2017 at 12:45 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

Thanks Dan

All, please do take a last look over the g/doc comments.  If you see discussion there that you feel is not in GH or still unresolved, please update the GH doc.

Alexis


On Mon, 18 Sep 2017, 04:01 Dan Kohn via cncf-toc <cncf-toc@...> wrote:
I took the TOC Principles document created by several TOC members and:

1. Converted it to markdown.
2. Left out the notes and comments on the budget.

The notes and comments are important (and remain in the original Google Doc), but will hopefully be addressed by the CNCF ServiceDesk and Service Dashboard that we'll be announcing in the next couple weeks.

For now, the TOC and I would appreciate your comments on the Principles themselves. If you don't think they adequately describe the way the TOC operates (and/or how it should operate), then please comment on the pull request.

Once comments are addressed, the goal is for the TOC to vote that this document represents the TOC Principles, and to have the CNCF governing board vote to endorse the Principles as well.

Rendered version

Pull request (comments welcome)

TOC Principles (i.e., the original document)

Thanks.
--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


6081 - 6100 of 7342