4 ms·

I like the simple plain text signing format for the API calls. For example: https://sum.golang.org/lookup/go.etcd.io/etcd@v0.4.0 https://sum.golang.org/lookup/

I like the simple plain text signing format for the API calls. For example: https://sum.golang.org/lookup/go.etcd.io/etcd@v0.4.0 https://sum.golang.org/lookup/go.etcd.io/etcd@v0.4.0 Is signed with: — sum.golang.org Az3grobHchAJWrV4M34o1kLnZV4vrGSfFA+2Q9VClbmWqBjsnN4GzK1xB1RaYGSo0jIjWH9GDcR3Tja5sadw2ESoKwg= The format is documented here: https://godoc.org/golang.org/x/mod/sumdb/note https://godoc.org/golang.org/x/mod/sumdb/note Also, as an aside, I am building a transparency tool for arbitrary binary downloads with the rget project: https://github.com/merklecounty/rget https://github.com/merklecounty/rget

benhoyt 7y ago
The format feels ad-hoc to me. These are intended almost exclusively for machine-reading, so why not JSON? One of the proxy endpoints (version metadata) returns JSON, so why not this one? If I were writing the client, I'd much prefer to parse a structured JSON object than that text file. So I'm curious why this choice -- I'm probably missing something.
- rsc 7y ago
  In a security-critical context, I would much rather use a format where every byte is specified than delegate to something with as much flexibility as JSON. I mean, I guess we could have used a JSON object like {"Msg": "text", "Sig": "signature"} but there's so much opportunity for surprises there and so little benefit to JSON.
rsc 7y ago
I really like rget, btw. I posted a trivial little command-line demo of a client and server for some others who were thinking about a transparency tool. It implements the cacheable GET API we designed for the checksum database but obviously it applies to arbitrary key-value pairs. It might be a better foundation than stuffing things into CT logs (or not, you do get some interesting infrastructure that way). https://rsc.io/tlogdb https://rsc.io/tlogdb
- philips 7y ago
  Thanks! I am almost certain I am going to need to move off of the CT log thing but I hope to onboard a few projects first[1]. But, tlogdb looks like a great starting (sent you a PR if you have a moment). I am trying to understand how all of the parts fit together at the moment particularly if I need to use Trillian or how far a direct SQL store to Spanner/CockroachDB like tlogdb implements is sufficient for awhile. The big advantage of implementing something like tlogdb is that it becomes a URL map which means that developers don't need to publish additional metadata (at the expense of the service needing to download entire files to calculate the digests). All of that to say thanks for all of the work on sumdb. Great starting point. [1] https://github.com/merklecounty/rget/issues/10 https://github.com/merklecounty/rget/issues/10

benhoyt 7y ago

The format feels ad-hoc to me. These are intended almost exclusively for machine-reading, so why not JSON? One of the proxy endpoints (version metadata) returns JSON, so why not this one? If I were writing the client, I'd much prefer to parse a structured JSON object than that text file. So I'm curious why this choice -- I'm probably missing something.

rsc 7y ago
In a security-critical context, I would much rather use a format where every byte is specified than delegate to something with as much flexibility as JSON. I mean, I guess we could have used a JSON object like {"Msg": "text", "Sig": "signature"} but there's so much opportunity for surprises there and so little benefit to JSON.

rsc 7y ago

I really like rget, btw. I posted a trivial little command-line demo of a client and server for some others who were thinking about a transparency tool. It implements the cacheable GET API we designed for the checksum database but obviously it applies to arbitrary key-value pairs. It might be a better foundation than stuffing things into CT logs (or not, you do get some interesting infrastructure that way). https://rsc.io/tlogdb https://rsc.io/tlogdb

philips 7y ago
Thanks! I am almost certain I am going to need to move off of the CT log thing but I hope to onboard a few projects first[1]. But, tlogdb looks like a great starting (sent you a PR if you have a moment). I am trying to understand how all of the parts fit together at the moment particularly if I need to use Trillian or how far a direct SQL store to Spanner/CockroachDB like tlogdb implements is sufficient for awhile. The big advantage of implementing something like tlogdb is that it becomes a URL map which means that developers don't need to publish additional metadata (at the expense of the service needing to download entire files to calculate the digests). All of that to say thanks for all of the work on sumdb. Great starting point. [1] https://github.com/merklecounty/rget/issues/10 https://github.com/merklecounty/rget/issues/10