Notary/TuF & GPG (& Harbor)


alexis richardson
 

Hi all 

Thanks Patrick & Docker people for Notary pres.  I personally found it very useful & educational, having avoided package signing myself as much as possible ;-)

I would love to understand how a GPG person would make the case for sticking with just that.

I would love to hear more from Mark about Harbor as a broader use case for Notary.

alexis




Mark Peek
 

Harbor is an open source enterprise registry built on top of Docker distribution. It adds enterprise features such as RBAC, LDAP/AD support, auditing, Notary, and other features (follow link below). While standalone, it is also being shipped with the vSphere Integrated Containers product.

 

https://github.com/vmware/harbor

 

My apologies if there was confusion on my Notary/Harbor comment on the call. The Notary team was asked about the number of github stars and/or the broader community. The point I was trying to make in support is since Notary is included into Harbor (with over 2k stars) and shipping to enterprise customers, the Notary project has more scope than just their own repo.

 

Mark

 

From: Alexis Richardson <alexis@...>
Date: Tuesday, June 20, 2017 at 9:03 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Cc: Patrick Chanezon <patrick.chanezon@...>
Subject: Notary/TuF & GPG (& Harbor)

 

Hi all 

 

Thanks Patrick & Docker people for Notary pres.  I personally found it very useful & educational, having avoided package signing myself as much as possible ;-)

 

I would love to understand how a GPG person would make the case for sticking with just that.

 

I would love to hear more from Mark about Harbor as a broader use case for Notary.

 

alexis

 

 

 


Solomon Hykes <solomon.hykes@...>
 

Notary has also been shipping to enterprise customers as part of Docker EE. Good to know Vmware has followed suit. If enterprise adoption is a point of evaluation we can put together a few case studies.


On Tuesday, June 20, 2017, Mark Peek via cncf-toc <cncf-toc@...> wrote:

Harbor is an open source enterprise registry built on top of Docker distribution. It adds enterprise features such as RBAC, LDAP/AD support, auditing, Notary, and other features (follow link below). While standalone, it is also being shipped with the vSphere Integrated Containers product.

 

https://github.com/vmware/harbor

 

My apologies if there was confusion on my Notary/Harbor comment on the call. The Notary team was asked about the number of github stars and/or the broader community. The point I was trying to make in support is since Notary is included into Harbor (with over 2k stars) and shipping to enterprise customers, the Notary project has more scope than just their own repo.

 

Mark

 

From: Alexis Richardson <alexis@...>
Date: Tuesday, June 20, 2017 at 9:03 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Cc: Patrick Chanezon <patrick.chanezon@...>
Subject: Notary/TuF & GPG (& Harbor)

 

Hi all 

 

Thanks Patrick & Docker people for Notary pres.  I personally found it very useful & educational, having avoided package signing myself as much as possible ;-)

 

I would love to understand how a GPG person would make the case for sticking with just that.

 

I would love to hear more from Mark about Harbor as a broader use case for Notary.

 

alexis

 

 

 


alexis richardson
 

That's good info.

Keen to learn more from the community about this use case and project!


On Tue, 20 Jun 2017, 18:05 Solomon Hykes, <solomon.hykes@...> wrote:
Notary has also been shipping to enterprise customers as part of Docker EE. Good to know Vmware has followed suit. If enterprise adoption is a point of evaluation we can put together a few case studies.

On Tuesday, June 20, 2017, Mark Peek via cncf-toc <cncf-toc@...> wrote:

Harbor is an open source enterprise registry built on top of Docker distribution. It adds enterprise features such as RBAC, LDAP/AD support, auditing, Notary, and other features (follow link below). While standalone, it is also being shipped with the vSphere Integrated Containers product.

 

https://github.com/vmware/harbor

 

My apologies if there was confusion on my Notary/Harbor comment on the call. The Notary team was asked about the number of github stars and/or the broader community. The point I was trying to make in support is since Notary is included into Harbor (with over 2k stars) and shipping to enterprise customers, the Notary project has more scope than just their own repo.

 

Mark

 

From: Alexis Richardson <alexis@...>
Date: Tuesday, June 20, 2017 at 9:03 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Cc: Patrick Chanezon <patrick.chanezon@...>
Subject: Notary/TuF & GPG (& Harbor)

 

Hi all 

 

Thanks Patrick & Docker people for Notary pres.  I personally found it very useful & educational, having avoided package signing myself as much as possible ;-)

 

I would love to understand how a GPG person would make the case for sticking with just that.

 

I would love to hear more from Mark about Harbor as a broader use case for Notary.

 

alexis

 

 

 


Richard Hartmann
 

On Tue, Jun 20, 2017 at 6:03 PM, Alexis Richardson via cncf-toc
<cncf-toc@...> wrote:

Thanks Patrick & Docker people for Notary pres. I personally found it very
useful & educational, having avoided package signing myself as much as
possible ;-)

I would love to understand how a GPG person would make the case for sticking
with just that.
Speaking as a Debian Developer, most of my work in that regard is
underpinned by GnuPG. A lot of the functionality mentioned could be
built with GnuPG and installed base and integration in many, many
workflows and systems is a huge advantage in potential adaption. That
being said, features like built-in quorum, expiring signatures, and
other mechanisms can't easily be replicated with GnuPG, or its
brethren, in their current form.

I can see merit in both extending the PGP world to cover these aspects
and in creating a new infrastructure.

I am willing to bet that feature velocity will be higher outside of
the PGP ecosystem as the installed base could be a disadvantage in
this context. Also, some mechanisms are not designed for anything
exceeding a certain scale.


While this is not an endorsement of any particular project or path
forward, I can say that the general functionality is highly needed.
Years ago, I implemented a data store for a financial customer with
third-party commercial hashsum timestamping services; that was not
very pleasant at all. The functionality in and as of itself would be
useful in a _lot_ of regards.


Richard


alexis richardson
 

Thanks Richard.  +1 on .debs.  My 2c is that signing functionality used to be quite inhumane, and any project seeking to do better could certainly focus on being "pleasant".  Although the Notary didn't highlight this specifically, it sounded like they haven't ignored it either.


On Tue, Jun 20, 2017 at 7:38 PM, Richard Hartmann <richih@...> wrote:
On Tue, Jun 20, 2017 at 6:03 PM, Alexis Richardson via cncf-toc
<cncf-toc@...> wrote:

> Thanks Patrick & Docker people for Notary pres.  I personally found it very
> useful & educational, having avoided package signing myself as much as
> possible ;-)
>
> I would love to understand how a GPG person would make the case for sticking
> with just that.

Speaking as a Debian Developer, most of my work in that regard is
underpinned by GnuPG. A lot of the functionality mentioned could be
built with GnuPG and installed base and integration in many, many
workflows and systems is a huge advantage in potential adaption. That
being said, features like built-in quorum, expiring signatures, and
other mechanisms can't easily be replicated with GnuPG, or its
brethren, in their current form.

I can see merit in both extending the PGP world to cover these aspects
and in creating a new infrastructure.

I am willing to bet that feature velocity will be higher outside of
the PGP ecosystem as the installed base could be a disadvantage in
this context. Also, some mechanisms are not designed for anything
exceeding a certain scale.


While this is not an endorsement of any particular project or path
forward, I can say that the general functionality is highly needed.
Years ago, I implemented a data store for a financial customer with
third-party commercial hashsum timestamping services; that was not
very pleasant at all. The functionality in and as of itself would be
useful in a _lot_ of regards.


Richard


Scott McCarty
 

Per the comments on GnuPG - the ubiquitous use of GPG is what drove Red Hat to work on what we call "simple signing" [1][2]. We would love to partner on more of this work.


[1]: http://www.projectatomic.io/blog/2016/07/working-with-containers-image-made-easy/

[2]: https://access.redhat.com/articles/2750891

Best Regards

Scott M

On 06/20/2017 05:23 PM, Alexis Richardson via cncf-toc wrote:
Thanks Richard. +1 on .debs. My 2c is that signing functionality used to be quite inhumane, and any project seeking to do better could certainly focus on being "pleasant". Although the Notary didn't highlight this specifically, it sounded like they haven't ignored it either.


On Tue, Jun 20, 2017 at 7:38 PM, Richard Hartmann <richih@... <mailto:richih@...>> wrote:

On Tue, Jun 20, 2017 at 6:03 PM, Alexis Richardson via cncf-toc
<cncf-toc@... <mailto:cncf-toc@...>> wrote:

> Thanks Patrick & Docker people for Notary pres. I personally
found it very
> useful & educational, having avoided package signing myself as
much as
> possible ;-)
>
> I would love to understand how a GPG person would make the case
for sticking
> with just that.

Speaking as a Debian Developer, most of my work in that regard is
underpinned by GnuPG. A lot of the functionality mentioned could be
built with GnuPG and installed base and integration in many, many
workflows and systems is a huge advantage in potential adaption. That
being said, features like built-in quorum, expiring signatures, and
other mechanisms can't easily be replicated with GnuPG, or its
brethren, in their current form.

I can see merit in both extending the PGP world to cover these aspects
and in creating a new infrastructure.

I am willing to bet that feature velocity will be higher outside of
the PGP ecosystem as the installed base could be a disadvantage in
this context. Also, some mechanisms are not designed for anything
exceeding a certain scale.


While this is not an endorsement of any particular project or path
forward, I can say that the general functionality is highly needed.
Years ago, I implemented a data store for a financial customer with
third-party commercial hashsum timestamping services; that was not
very pleasant at all. The functionality in and as of itself would be
useful in a _lot_ of regards.


Richard




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

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smccarty@...

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? http://red.ht/22xKw9i


alexis richardson
 

Scott

What are your thoughts on Notary?

a


On Wed, Jun 21, 2017 at 6:41 PM, Scott McCarty via cncf-toc <cncf-toc@...> wrote:
Per the comments on GnuPG - the ubiquitous use of GPG is what drove Red Hat to work on what we call "simple signing" [1][2]. We would love to partner on more of this work.


[1]: http://www.projectatomic.io/blog/2016/07/working-with-containers-image-made-easy/

[2]: https://access.redhat.com/articles/2750891

Best Regards

Scott M


On 06/20/2017 05:23 PM, Alexis Richardson via cncf-toc wrote:
Thanks Richard.  +1 on .debs.  My 2c is that signing functionality used to be quite inhumane, and any project seeking to do better could certainly focus on being "pleasant".  Although the Notary didn't highlight this specifically, it sounded like they haven't ignored it either.


On Tue, Jun 20, 2017 at 7:38 PM, Richard Hartmann <richih@... <mailto:richih@...>> wrote:

    On Tue, Jun 20, 2017 at 6:03 PM, Alexis Richardson via cncf-toc
    <cncf-toc@... <mailto:cncf-toc@...>> wrote:

    > Thanks Patrick & Docker people for Notary pres. I personally
    found it very
    > useful & educational, having avoided package signing myself as
    much as
    > possible ;-)
    >
    > I would love to understand how a GPG person would make the case
    for sticking
    > with just that.

    Speaking as a Debian Developer, most of my work in that regard is
    underpinned by GnuPG. A lot of the functionality mentioned could be
    built with GnuPG and installed base and integration in many, many
    workflows and systems is a huge advantage in potential adaption. That
    being said, features like built-in quorum, expiring signatures, and
    other mechanisms can't easily be replicated with GnuPG, or its
    brethren, in their current form.

    I can see merit in both extending the PGP world to cover these aspects
    and in creating a new infrastructure.

    I am willing to bet that feature velocity will be higher outside of
    the PGP ecosystem as the installed base could be a disadvantage in
    this context. Also, some mechanisms are not designed for anything
    exceeding a certain scale.


    While this is not an endorsement of any particular project or path
    forward, I can say that the general functionality is highly needed.
    Years ago, I implemented a data store for a financial customer with
    third-party commercial hashsum timestamping services; that was not
    very pleasant at all. The functionality in and as of itself would be
    useful in a _lot_ of regards.


    Richard




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

--

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smccarty@...

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? http://red.ht/22xKw9i

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