What is a signature in entropic?
- chris wants a binary format
- we have to hash it
- order matters
- let's get fussy
All objects start with type, expressed as a string.
signature | version | blob
<space>
ASCII-encoded number that is the unpacked size
nul
content of the object
for a signature, the content is:
- signing primitive (ed25519)
- nul
- sodium-oxide's representation of the signature
- the data
- signed changelog, as described in Chris's gist
- verification-- triggered by depending on a new version of a package
- look at signer of that version
- walk chain backwards to last-known signature object, verify events that change authority to see if the signer is trustworthy
- typical case: only check is the initial server transfer
- other common case: addition of new maintainer
last-known signature: cache a little data about what you've already checked
when checks fail:
- yell!
- refuse to accept the first bad signature object
- chain STOPS
public/private keypairs
- local users provide a public key at signup OR we generate a keypair for the user
- we are using libsodium; ed25519 or STFU
- the user MUST MUST MUST MUST protect their private key themselves; this is a messaging problem for us
- keys can be revoked (this is a signed action)
Artifact generated: Transparent verifiable log of a user known to an entropic instance acting on their keypairs.
org namespaces: aka things with more than one user
- only this namespace can publish/modify packages
- membership of the namespace changes over time
- implication: namespace has a human name as do users
- if you want your data to be private, entropic will not do this for you. Hide your instance somehow (firewall, http pass, whatever).
- signed action is "add write perms for this namespace" (or revoke)
- implication: we sign all data mutation actions in the entropic sphere, including actions like namespace membership changes
- want to sign when a user revokes or replaces their public key
things that need signature chains:
- namespaces
- users are namespaces
- packages
aka every data primitive entropic is tracking
ds add lodash
- ds goes to other service, asks for all changes to namespace change since TIMESTAMP (last time I talked to you)
- server must be able to respond to this request
- analog in git is
git refs - we must always clone all the namespaces (ds will always ask for all of them)
- implication: all clients & entropic servers eventually have full trust chains for all namespaces they use
- the server signs everything & never removes itself-- this is the company running an entropic case (transfers of maintainership are not like the public package case) (namespaces are not needed here)
- when you say "the url is the namespace": this is the babel project use case, with many maintainers; we need to think this through
A package might have a forked head. "merge commits" --> the act of mirroring is a fork; this is an action that needs to be signed
When you update from a mirrored server, you play forward all the changes from the originating server. "This server verifies that it receives this mirror." Can get history of the snapshots it mirrored. (If you trust the server, you can stop verifying here, because the server did the work for you already.)
Are namespaces (named groups of users) worth the complexity? The babel project usecase is something we need to think through.
Terminology for having "multiple heads" for a mirrored package: we need some. What does this buy us? why do we nee this?
sodiumoxide is a good library to use. It's backed by libsodium. This is good.
Signature changelogs are good. CJ approves.
Signature changelogs allow you to publish packages from one entropic to another one. Aka, you get to publish your dependencies when you publish your package. We don't have a readthrough any more! (We add directly from the other entropic.) This also supports the ds add npm:lodash case. There's going to be a lot of lodashes out there, one per import from VCPM.
We think that users will have to provide a public key, or we will generate one for them. Documentation/suggestions for managing & protecting their private keys will be important. Fortunately, our early audience will be super-technical. Open question: do we need to maintain a signed changelog of user => public key? Probably the answer is yes, we need to replicate what Keybase has done here.
Do we need a distributed ledger? Not really. We want to be able to verify old public keys. We have a system for making ledgers publicly accessible.
Distribution argument: We have a malicious entropic. It claims to have a package from a registry that doesn't exist. How do we detect this? We need to be able to figure out the difference between "this never existed" and "this existed and went away". One entropic needs to be able to tell another about all the entropics it has ever seen & decided to trust.
WEB OF TRUST PROBLEM