yahooarchive / coname Goto Github PK
View Code? Open in Web Editor NEWAn experimental cooperative keyserver based on ideas from dename.
License: Apache License 2.0
An experimental cooperative keyserver based on ideas from dename.
License: Apache License 2.0
This affects raftlog, verifier, and keyserver. We need tests that make sure that the in-memory state is correctly loaded from disk on startup.
@andres-erbsen or @daniel-ziegler , can you please help with that? Thanks :)
This issue is for tracking planned renames of packages and interfaces.
server
-> keyserver
, because server
is really not descriptive.server.VerifierBroadcast
, server.WaitingRoom
-> separate packages in server/internal/
(internal folder spec)coname
-> e2eks
when it is known what the final name will be AND that the coname design will be used to implement that.This is just a note that cnclient
is not production-quality code or even close to that. We will probably want a real command-line client at some point, probably based on dename/dnmgr
instead of cnclient
. If you are looking for coname
-specific example code, the server tests have functions for performing updates and lookups.
--- FAIL: TestKeyserverRoundtripWithoutQuorumRequirement (0.04s)
server_test.go:234: profile didn't roundtrip: != 0a146e6f6e63656e6f6e63656e6f6e63654e4f4e4345120a0a036162631203010203120f0a0378797a12085445535420343536
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
--- FAIL: TestKeyserverUpdateWithoutQuorumRequirement (0.05s)
server_test.go:234: profile didn't roundtrip: != 0a146e6f6e63656e6f6e63656e6f6e63654e4f4e4345120a0a036162631203010203120f0a0378797a12085445535420343536
2015/08/13 12:03:54 transport: http2Client.notifyError got notified that the client transport was broken EOF.
FAIL
example directories in /tmp: keyserver961875949 verifier958246201
We are probably affected by etcd-io/etcd#3699.
As the GitHub reminder says: "Help people interested in this repository understand your project by adding a README!"
keyserver.step overwrites redundant updates during the same epoch. As they are still exposed to verifiers, it would be nice to also keep the for showing to clients.
https://github.com/yahoo/coname/blob/master/cnclient/client.go#L107 should provide a DKIMProof on initial registration. This would be an email sent from the address being registered to the address being registered with the subject line containing the prefix specified in server conf and then the hash of the entry. Lack of this proof will likely cause an io.EOF on the server side prior to 5fe00a3.
LookupProof
should generalize to proofs of absence, right? Does the message structure need to be different to handle absence proofs?
In the reconfiguration mess doc, it mentioned a few things that are not exactly true.
etcd/raft requires that a new replica being added must know the exact state of the cluster at the moment it is added. Similarly, replicas who are not yet aware of a recent reconfigurations are not able to receive commands from the new nodes: this means that a new node serving as a leader cannot help those replicas to catch up. Nodes not in the cluster cannot catch up with the cluster before being added -- and adding them would reduce availability.
etcd/raft does not have this requirement. You can just add node and starts that node with no configuration at all. Also replicas can receives commands from leader even if it does not know the recent configuration.
The truth is that in etcd we add additional stricter checking which are necessary in our use case. You do not have to do any checking if you do not willing to.
Not sure if this project is still in active development. If so, you might want to change your VRF implementation.
For details see:
coniks-sys/coniks-go#175
or
google/keytransparency#567
The JSON marshalers and unmarshalers our generate script produces using the latest gogoproto do not pass the autogenerated tests (they fail by trying to unmarshal an enum as if it had been encoded as an int, but it is actually encoded as a string). I don't know what causes this.
OTOH, the only part where andres-erbsen/protobuf differs from gogo/protobuf is the jsonpb package. In particular, I believe this means that we do not need to use my fork for code generation, only for json marshaling (by sed-patching the jsonpb in the generated files). This will hopefully let us catch the next issue of this kind right when gogoproto introduces it. Even better, if we play it well, then we might be able to upstream the jsonification patch ("prefer specialized Marshal/Unmarshal implementations to the generic" can sound pretty well, even though we use this in a hacky way in our project).
How urgent is updating gogoproto compared to working on cluster membership changes?
Currently there is a ed25519 subdirectory, but there are also imports of github.com/agl/ed25519 (ex. https://github.com/agl/ed25519/blob/master/ed25519.go#L17 , https://github.com/yahoo/coname/blob/master/keyserver/server.go#L36, https://github.com/yahoo/coname/blob/master/keyserver/deploy/make_config.go#L38). The reason for both "vendored" (embedded) directory and imported does not seem obvious (possibly historic or related to the codebase evolution?). Since Adam put his ed25519 code into golang.org/x/crypto/ed25519 - see golang/crypto@c9aef11 - should we standardize all references and imports to that "official" version? If there are no objections in general, I can send a PR for the differences in API etc.
c91ef26 contains some VRF code, but things need to be figured out before I am at all comfortable using it.
In the order of priority:
Are all (name, vrf) pairs that pass Verfiy a bijections (meaning no collisions in either direction) under cryptographic assumptions?
Is the double Icart function a valid way to instantiate H1?
Is SHA2 a valid instantiation for the main random oracle (w.r.t length extension, for example)?
Is the implementation doing what we want it to be doing?
Is there anything faster than P384 that we could use? needs p%3==2 for Icart. The current performance is meh: 50 proofs/sec on i7-5600U with go1.5:
BenchmarkCompute-4 200 7152502 ns/op
BenchmarkProve-4 100 20612791 ns/op
BenchmarkVerify-4 50 26990501 ns/op
ok github.com/yahoo/coname/common/vrf 13.036s
go test -bench=. 16.70s user 0.70s system 128% cpu 13.510 total
in https://github.com/yahoo/coname/blob/master/proto/client.proto#L111, version
is confusing; for instance, it could also be used to refer to API version. I think counter
is what you mean.
All verifiers should be authenticated on connection level and they should not be allowed to submit signatures under any other id than their own. We would like to implement this using client certificates (with CommonName=verifier id), but it is blocking on grpc/grpc-go#111.
I suggest to rename the subdirectory "main" in keyserver/main to something more descriptive and appropriate for the name of generated library - so that you could use the 'regular' go install -v github.com/yahoo/coname/keyserver/somethingdescriptive" command and not end up with executable "main" (or have to fall back on
go build` command).
Also, now after running go get -v github.com/yahoo/coname
, you do get an executable "main" in your GOPATH/bin (or GOBIN):
$ GOPATH=/tmp/yago go get -v -u -t -x github.com/yahoo/coname/...
$ ls -l /tmp/yago/bin
total 97376
-rwxr-xr-x 1 dmitris users 11555548 Jan 11 21:53 cnclient
-rwxr-xr-x 1 dmitri users 11218892 Jan 11 21:53 deploy
-rwxr-xr-x 1 dmitris users 16354428 Jan 11 21:53 main
-rwxr-xr-x 1 dmitris users 10723040 Jan 11 21:53 protoc-gen-coname
https://github.com/yahoo/coname/blob/master/AUTHORS#L2 says:
# This file is distinct from the CONTRIBUTORS files.
# See the latter for an explanation.
but I could not find a CONTRIBUTORS file(s) and the related explanation... Also the first line says: This is the official list of Dename authors for copyright purposes.
- maybe the AUTHORS file should be renamed to something like AUTHORS.dename for clarity?
It broke somewhere between the version I checked in when I tried to do dependency vendoring (hah, maybe should have continued) and 056e49a669ad72a638fd7d079c5b587be5b5a47f. I think a git bisect might give some insight to why. This issue is blocking as of the next time we want to change a proto file.
shouldn't LookupProof
be signed by the keyserver so that it can be used by the client to prove that a keyserver is misbehaving? Ex: if a keyserver returns a malicious tree proof and the client detects this, it can be used as evidence of compromise.
Several hours of developer time were just spent debugging a livelocked test. Oh well. We really should remove all time-dependence from the testing -- is https://godoc.org/github.com/facebookgo/clock the way go, or does anybody have positive experience with some other library?
vrf proofs do not need to be recomputed for each query. They could be stored next to the profile during updates and just read from there. This would trade storage io for less cpu load. We do not necessarily want to do it, but it is totally possible and safe.
--- FAIL: TestKeyserverUpdate-2 (1.54s)
server_test.go:399: rpc error: code = 2 desc = "timed out while waiting for ratification"
Also happens in ThreeVerifiers test on travis. I have not managed to reproduce this locally.
In client.proto, verifier
and ratifier
seem to be used interchangeably. If they actually are the same thing, let's use one or the other.
We have basic logging needs - support for log levels and log rotation. Should we write our own based on standard "log" package or use one the popular ones like glog, etc? Any preference?
I would guess this is a shutdown race, either in replication, replication test, or grpc-go.
panic: assignment to entry in nil map
goroutine 1085 [running]:
google.golang.org/grpc/transport.(*http2Client).NewStream(0xc820dce620, 0x31c0efc03a8, 0xc82000e6e0, 0xc8247f7c60, 0x0, 0x0, 0x0)
/home/uhu/go/src/google.golang.org/grpc/transport/http2_client.go:270 +0x8c7
google.golang.org/grpc.sendRequest(0x31c0efc03a8, 0xc82000e6e0, 0x31c15039f08, 0xd57028, 0xc8247f7c60, 0x31c0df3d298, 0xc820dce620, 0x9f3dc0, 0xc820f22900, 0xc821020350, ...)
/home/uhu/go/src/google.golang.org/grpc/call.go:73 +0x9c
google.golang.org/grpc.Invoke(0x31c0efc03a8, 0xc82000e6e0, 0xaa3450, 0x10, 0x9f3dc0, 0xc820f22900, 0x9f4ae0, 0xd57028, 0xc820e28840, 0x0, ...)
/home/uhu/go/src/google.golang.org/grpc/call.go:169 +0x86f
github.com/yahoo/coname/server/replication/raftlog/proto.(*raftClient).Step(0xc82002e138, 0x31c0efc03a8, 0xc82000e6e0, 0xc820f22900, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/uhu/go/src/github.com/yahoo/coname/server/replication/raftlog/proto/raftrpc.pb.go:53 +0xec
Hey folks! Interested in your work. Could summarize some of the changes being considered, compared to dename and CONIKS? (I'd also like to hear what quorum algorithms you're considering, now.)
Thanks!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.