----- Original Message -----
> From: "Sam Whited" <s...@samwhited.com>
> To: "rprichard via golang-dev" <golang-...@googlegroups.com>
> Sent: Monday, March 4, 2019 7:06:37 PM
> Subject: Re: [golang-dev] proposal: public module authentication with the Go
> notary
>
> TL;DR — Right now when fetching a module Google isn't involved, and I'd
> like it to stay that way. Please let me configure and use different
> notaries without also using a proxy.
>
> > There is no plan to allow use of alternate notaries, which would add
> > complexity and potentially reduce the overall security of the system,
> > allowing different users to be attacked by compromising different
> > notaries.
>
> If you're somewhere that Google doesn't service (eg. due to U.S. export
> laws) does this mean you're entirely out of luck and can't use the new
> security features? It seems unfortunate that a developer in Iran would
> have to fall back to the TOFU model just because Google decided to bless
> themselves and not allow anyone else to run a notary or jump through
> extra hoops to configure or run a proxy.
>
> > We originally considered having multiple notaries signing individual
> > go.sum entries and requiring the go command to collect signatures from
> > a quorum of notaries before accepting an entry. That design depended
> > on the uptime of multiple services and could still be compromised
> > undetectably by compromising enough notaries. That is, that design
> > would blindly trust a quorum of notaries.
>
> This seems strictly superior to blindly trusting a single notary. Why
> does Google think it will be more secure than Google and Mozilla, or
> Google and Microsoft, or Google and <your company>?
>
> As far as uptime is concerned, you're always limited to the uptime of
> your least available notary, I don't necessarily think Google's uptime
> will be any better than any other large company that might choose to run
> a notary, so that seems fine: I have the option of trusting only
> notaries with high availability, meaning that it's likely no worse than
> if I just trusted Google.
>
> > The design presented here uses the transparent log eliminates blind
> > trust in a quorum of notaries and instead uses a “trust but verify”
> > model with a single notary.
>
> We could also "trust but verify" a quorum of notaries, so this seems
> like a false dichotomy.
>
> On a more personal note, having a non-Google controlled notary seems
> like an absolute requirement to me and I would prefer to avoid using a
> Google run service entirely if possible. Google doesn't need to know
> anything about what modules my company is using. I do appreciate the
> privacy section, which addresses this, but tying the notary use to using
> a proxy or running your own proxy is likely out of reach for many
> individuals (including me).
>
> —Sam
I have a similar fears and worries here. First thing that popped on my
mind(personally as a external observer) this is a move of Google to fully
productize(data mine) a Go users community(for very limited payback), even if
it is not a main driver it will make it irresistibly easy to do so(with google
hosted notary).
IMHO this feature should be opt-in and the actual default instance of the
notary should be run by trustworthy and independent 3rd party(ideally NPO) with
clear and transparent privacy policy and on community accessible
infrastructure(so a community members can actually participate in the
maintenance and verify policies surrounding it, i.e. not like a current Go
infra is run, only Google employees can contribute/touch it).
As I will carefully evaluate all the details of the final implementation, but
from this first look I'm currently leaning to "patch out" or de-configure by
default this feature in Fedora when/if it lands in upstream GC, to preserve the
privacy of the users.
JC
PS: This is just my personal Fedora's GC maintainer take on this issue.
>
> On Mon, Mar 4, 2019, at 17:32, Russ Cox wrote:
> > Hi all,
> >
> > I wanted to let people here know about the proposal design we just
> > published: golang.org/design/25530-notary, for golang.org/issue/25530.
> > (We also mentioned this general idea in our blog post from back in
> > December, https://blog.golang.org/modules2019.)
> >
> > As usual, comments are welcome on the issue or, if you prefer not to
> > use the issue tracker, here in this thread.
> >
> > Thanks. Russ
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "golang-dev" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to golang-
> > dev+unsubscr...@googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
>
> --
> Sam Whited
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
_______________________________________________
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
