----- Original Message -----
From: "Sam Whited" <sam(a)samwhited.com>
To: "rprichard via golang-dev" <golang-dev(a)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+unsubscribe(a)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+unsubscribe(a)googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.
>