Re: Notary/TuF & GPG (& Harbor)

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.



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.


cncf-toc mailing list

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smccarty@...

Phone: 312-660-3535

Cell: 330-807-1043


When should you split your application into multiple containers?

Join to automatically receive all group messages.