In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method (like listing your key ID on a TLS-enabled website).
Yeah, it's interesting that even platforms such as Keybase that allow changing or removing data timestamp them in irremovable ways sometimes (e.g. following someone snapshots their profile in the follower's sigchain).
> In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method.
Actually having a key on a keyserver was never relevant as web-of-trust runs parallel to the key origin (that is if you're connected to WoT you'd know which key is the real one). But it's not practical in general.
> like listing your key ID on a TLS-enabled website
Web Key Directory is something like that and it's trivial to set up: https://spacekookie.de/blog/usable-gpg-with-wkd/
---
You could try splitting this big function into smaller functions to reduce the length of the code largest callbacks.
It also makes commits harder to read. eg. for https://github.com/tdjsnelling/dat-keyserver/commit/12fa3e83... a reader can't see easily what changed in the function, as every line's indentation was changed. (And the commit message does not explain what the bug was)
Also, generally people do not put all their logic in the same file , in express apps. Just breaking out the business logic from the express app setup would also help to make it more readable/understandable.
Please edit swipes like this out of your HN comments, particularly in Show HN threads: https://news.ycombinator.com/showhn.html.
(Ultimately a minor issue at this stage of what's otherwise a really neat project!)
git log -p --color-words
git show --color-words <commut-ref>
openpgp.cleartext
.readArmored(req.body.message)
.then(message => {
openpgp.key
.readArmored(nodes[0].value.key)
.then(key => {
...
})
})
openpgp.cleartext
.readArmored(req.body.message)
.then(message =>
openpgp.key.readArmored(nodes[0].value.key)
)
.then(key => {
...
})My understanding of this is that anyone with a copy of anything you've ever signed can revoke your key. I hope I'm misunderstanding.
> If a user can prove that a key belongs to them (by signing a message with their private key) then they are able to remove their public key with no interaction needed from the server operator. Once a key is removed, it is removed from all servers in the pool.
This is a pretty fucking awesome idea.
Alice sends an email to Bob and clearsigns the message. Bob, or anyone else who intercepts the email is now able to paste that message into the form and remove Alice's key from the keyserver.
This could be mitigated by requiring it to be a specific message.
Still, an interesting alternative for people who consider https://keys.openpgp.org too radical.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...