A security.txt

@@ -0,0 +1,18 @@
+
+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.
+
+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?

M spec.txt → spec.txt

@@ -1,3 +1,10 @@
+honk spec
+
+-- references
+
+See security.txt for some notes on security.
+
+-- schema
 
 Some notes on the database schema. Mostly for development, but maybe useful
 for administration as well.