forge/Vervis
1
0
Fork 0
Code Pull requests Activity
Vervis/migrations/2019_02_03_verifkey.model

12 lines
162 B
Text
Raw Normal View History

Store remote actor keys in the DB, reuse them instead of GETing every time
2019-02-03 14:58:14 +01:00
VerifKey
ident String
public ByteString
Support remote actors specifying 2 keys, and DB storage of these keys It's now possible for activities we be attributed to actors that have more than one key. We allow up to 2 keys. We also store in the DB. Scaling to support any number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and because 2 is the actual number we need. By having 2 keys, and replacing only one of them in each rotation, we avoid race conditions. With 1 key, the following can happen: 1. We send an activity to another server 2. We rotate our key 3. The server reaches the activity in its processing queue, tries to verify our request signature, but fails because it can't fetch the key. It's the old key and we discarded it already, replaced it with the new one When we use 2 keys, the previous key remains available and other servers have time to finish processing our requests signed with that key. We can safely rotate, without worrying about whether the user sent anything right before the rotation time. Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe because it's optional, but it's just Vervis right now. Once Vervis itself starts using 2 keys, it will be able to rotate freely without race condition risk, but probably Mastodon etc. won't accept its signatures because of the use of 2 keys and because they're server-scope keys. Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
sharer RemoteSharerId
Store remote actor keys in the DB, reuse them instead of GETing every time
2019-02-03 14:58:14 +01:00
UniqueVerifKey ident
Support remote actors specifying 2 keys, and DB storage of these keys It's now possible for activities we be attributed to actors that have more than one key. We allow up to 2 keys. We also store in the DB. Scaling to support any number of keys is trivial, but I'm limiting to 2 to avoid potential trouble and because 2 is the actual number we need. By having 2 keys, and replacing only one of them in each rotation, we avoid race conditions. With 1 key, the following can happen: 1. We send an activity to another server 2. We rotate our key 3. The server reaches the activity in its processing queue, tries to verify our request signature, but fails because it can't fetch the key. It's the old key and we discarded it already, replaced it with the new one When we use 2 keys, the previous key remains available and other servers have time to finish processing our requests signed with that key. We can safely rotate, without worrying about whether the user sent anything right before the rotation time. Caveat: With this feature, we allow OTHER servers to rotate freely. It's safe because it's optional, but it's just Vervis right now. Once Vervis itself starts using 2 keys, it will be able to rotate freely without race condition risk, but probably Mastodon etc. won't accept its signatures because of the use of 2 keys and because they're server-scope keys. Maybe I can get these features adopted by the fediverse?
2019-02-04 20:38:50 +01:00
RemoteSharer
ident String
UniqueRemoteSharer ident
Copy permalink