2019-04-12 01:02:17 +02:00
|
|
|
|
|
|
|
|
Some notes about security.
|
|
|
|
|
|
|
|
|
|
honk is not currently hardened against SSRF, server side request forgery. Be
|
|
|
|
|
mindful of what else may be reachable on localhost or the local network if
|
|
|
|
|
it's not generally accessible.
|
|
|
|
|
|
2019-04-14 20:17:50 +02:00
|
|
|
Key and signature verification is best effort, but some forgeries may sneak
|
|
|
|
|
past. In particular, tying together key name, key owner, actor, object, etc.
|
|
|
|
|
is incomplete.
|
|
|
|
|
|
2019-04-12 01:02:17 +02:00
|
|
|
How are user keys supposed to be rotated? Expired? Revoked?
|
|
|
|
|
|
|
|
|
|
The current answer is never, never, never.
|
|
|
|
|
|
|
|
|
|
If the key is only used for signing http requests, it can be be changed
|
|
|
|
|
basically at will. Change the key in the actor, give it a new name (to avoid
|
|
|
|
|
conflict with any cached keys), carry on.
|
|
|
|
|
|
|
|
|
|
Using keys to sign json is more complicated. The current practice is to name
|
|
|
|
|
keys with URL fragments. example.com/user#key. If the keyname is changed to
|
|
|
|
|
#newkey, how does one fetch the old key to verify existing data?
|
