2016-02-14 18:10:21 +09:00
|
|
|
-- This file is part of Vervis.
|
|
|
|
|
--
|
2019-01-26 21:56:15 +09:00
|
|
|
-- Written in 2016, 2018, 2019 by fr33domlover <fr33domlover@riseup.net>.
|
2016-02-14 18:10:21 +09:00
|
|
|
--
|
|
|
|
|
-- ♡ Copying is an act of love. Please copy, reuse and share.
|
|
|
|
|
--
|
|
|
|
|
-- The author(s) have dedicated all copyright and related and neighboring
|
|
|
|
|
-- rights to this software to the public domain worldwide. This software is
|
|
|
|
|
-- distributed without any warranty.
|
|
|
|
|
--
|
|
|
|
|
-- You should have received a copy of the CC0 Public Domain Dedication along
|
|
|
|
|
-- with this software. If not, see
|
|
|
|
|
-- <http://creativecommons.org/publicdomain/zero/1.0/>.
|
|
|
|
|
|
2016-05-24 17:28:57 +09:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
-- People
|
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
|
2016-02-16 20:41:13 +09:00
|
|
|
Sharer
|
2016-05-24 17:34:40 +09:00
|
|
|
ident ShrIdent
|
|
|
|
|
name Text Maybe
|
2016-08-21 02:32:27 +09:00
|
|
|
created UTCTime
|
2016-02-16 20:41:13 +09:00
|
|
|
|
2016-05-24 05:46:54 +09:00
|
|
|
UniqueSharer ident
|
2016-02-16 20:41:13 +09:00
|
|
|
|
|
|
|
|
Person
|
2018-04-01 12:02:35 +09:00
|
|
|
ident SharerId
|
|
|
|
|
login Text
|
|
|
|
|
passphraseHash ByteString
|
|
|
|
|
email EmailAddress
|
|
|
|
|
verified Bool
|
|
|
|
|
verifiedKey Text
|
|
|
|
|
verifiedKeyCreated UTCTime
|
|
|
|
|
resetPassKey Text
|
|
|
|
|
resetPassKeyCreated UTCTime
|
2019-01-27 08:39:13 +09:00
|
|
|
about Text
|
2016-02-16 20:41:13 +09:00
|
|
|
|
|
|
|
|
UniquePersonIdent ident
|
|
|
|
|
UniquePersonLogin login
|
2018-04-11 20:09:42 +09:00
|
|
|
UniquePersonEmail email
|
2016-02-16 20:41:13 +09:00
|
|
|
|
2019-02-03 22:58:14 +09:00
|
|
|
VerifKey
|
2019-02-22 08:59:53 +09:00
|
|
|
ident LocalURI
|
2019-02-06 11:48:23 +09:00
|
|
|
instance InstanceId
|
|
|
|
|
expires UTCTime Maybe
|
2019-03-11 08:15:42 +09:00
|
|
|
public PublicVerifKey
|
2019-02-06 11:48:23 +09:00
|
|
|
sharer RemoteSharerId Maybe
|
2019-02-03 22:58:14 +09:00
|
|
|
|
2019-02-22 08:59:53 +09:00
|
|
|
UniqueVerifKey instance ident
|
2019-02-03 22:58:14 +09:00
|
|
|
|
Record usage of instance keys in the DB
When we verify an HTTP signature,
* If we know the key, check in the DB whether we know the actor lists it. If it
doesn't, and there's room left for keys, HTTP GET the actor and update the DB
accordingly.
* If we know the key but had to update it, do the same, check usage in DB and
update DB if needed
* If we don't know the key, record usage in DB
However,
* If we're GETing a key and discovering it's a shared key, we GET the actor to
verify it lists the key. When we don't know the key at all yet, that's fine
(can be further optimized but it's marginal), but if it's a key we do know,
it means we already know the actor and for now it's enough for us to rely
only on the DB to test usage.
2019-02-19 19:54:55 +09:00
|
|
|
VerifKeySharedUsage
|
|
|
|
|
key VerifKeyId
|
|
|
|
|
user RemoteSharerId
|
|
|
|
|
|
|
|
|
|
UniqueVerifKeySharedUsage key user
|
|
|
|
|
|
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-05 04:38:50 +09:00
|
|
|
RemoteSharer
|
2019-02-22 08:59:53 +09:00
|
|
|
ident LocalURI
|
2019-02-06 11:48:23 +09:00
|
|
|
instance InstanceId
|
2019-02-22 08:59:53 +09:00
|
|
|
inbox LocalURI
|
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-05 04:38:50 +09:00
|
|
|
|
2019-02-22 08:59:53 +09:00
|
|
|
UniqueRemoteSharer instance 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-05 04:38:50 +09:00
|
|
|
|
2019-02-06 11:48:23 +09:00
|
|
|
Instance
|
|
|
|
|
host Text
|
|
|
|
|
|
|
|
|
|
UniqueInstance host
|
|
|
|
|
|
2016-03-06 20:58:48 +09:00
|
|
|
SshKey
|
2016-05-24 05:46:54 +09:00
|
|
|
ident KyIdent
|
2016-03-06 20:58:48 +09:00
|
|
|
person PersonId
|
|
|
|
|
algo ByteString
|
|
|
|
|
content ByteString
|
|
|
|
|
|
2016-05-24 05:46:54 +09:00
|
|
|
UniqueSshKey person ident
|
2016-03-06 20:58:48 +09:00
|
|
|
|
2016-02-16 20:41:13 +09:00
|
|
|
Group
|
|
|
|
|
ident SharerId
|
|
|
|
|
|
2016-05-24 17:28:57 +09:00
|
|
|
UniqueGroup ident
|
|
|
|
|
|
|
|
|
|
GroupMember
|
|
|
|
|
person PersonId
|
|
|
|
|
group GroupId
|
2016-05-26 00:52:15 +09:00
|
|
|
role GroupRole
|
2016-05-27 01:25:23 +09:00
|
|
|
joined UTCTime
|
2016-05-24 17:28:57 +09:00
|
|
|
|
|
|
|
|
UniqueGroupMember person group
|
|
|
|
|
|
2016-06-01 17:52:14 +09:00
|
|
|
ProjectRole
|
|
|
|
|
ident RlIdent
|
2016-06-07 02:29:54 +09:00
|
|
|
sharer SharerId
|
2016-06-01 17:52:14 +09:00
|
|
|
desc Text
|
|
|
|
|
|
2016-06-07 02:29:54 +09:00
|
|
|
UniqueProjectRole sharer ident
|
2016-06-01 17:52:14 +09:00
|
|
|
|
2016-06-21 16:35:19 +09:00
|
|
|
ProjectRoleInherit
|
|
|
|
|
parent ProjectRoleId
|
|
|
|
|
child ProjectRoleId
|
|
|
|
|
|
|
|
|
|
UniqueProjectRoleInherit parent child
|
|
|
|
|
|
2016-06-01 17:52:14 +09:00
|
|
|
ProjectAccess
|
|
|
|
|
role ProjectRoleId
|
|
|
|
|
op ProjectOperation
|
|
|
|
|
|
|
|
|
|
UniqueProjectAccess role op
|
|
|
|
|
|
2016-05-24 17:28:57 +09:00
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
|
-- Projects
|
|
|
|
|
-------------------------------------------------------------------------------
|
2016-02-16 20:41:13 +09:00
|
|
|
|
|
|
|
|
Project
|
2016-05-24 05:46:54 +09:00
|
|
|
ident PrjIdent
|
2016-05-01 05:40:33 +09:00
|
|
|
sharer SharerId
|
2019-01-30 07:24:32 +09:00
|
|
|
name Text Maybe
|
|
|
|
|
desc Text Maybe
|
2016-08-09 04:05:22 +09:00
|
|
|
workflow WorkflowId
|
2016-08-09 03:35:01 +09:00
|
|
|
nextTicket Int
|
2019-01-30 07:24:32 +09:00
|
|
|
wiki RepoId Maybe
|
|
|
|
|
collabUser ProjectRoleId Maybe
|
|
|
|
|
collabAnon ProjectRoleId Maybe
|
2016-02-16 20:41:13 +09:00
|
|
|
|
|
|
|
|
UniqueProject ident sharer
|
|
|
|
|
|
|
|
|
|
Repo
|
2016-05-24 05:46:54 +09:00
|
|
|
ident RpIdent
|
2016-04-13 02:37:31 +09:00
|
|
|
sharer SharerId
|
2016-08-09 03:35:01 +09:00
|
|
|
vcs VersionControlSystem
|
2016-05-03 08:51:53 +09:00
|
|
|
project ProjectId Maybe
|
|
|
|
|
desc Text Maybe
|
2016-08-09 03:35:01 +09:00
|
|
|
mainBranch Text
|
2019-01-30 07:24:32 +09:00
|
|
|
collabUser ProjectRoleId Maybe
|
|
|
|
|
collabAnon ProjectRoleId Maybe
|
2016-02-16 20:41:13 +09:00
|
|
|
|
2016-04-13 02:37:31 +09:00
|
|
|
UniqueRepo ident sharer
|
2016-02-16 20:41:13 +09:00
|
|
|
|
2016-08-08 20:05:19 +09:00
|
|
|
Workflow
|
|
|
|
|
sharer SharerId
|
|
|
|
|
ident WflIdent
|
|
|
|
|
name Text Maybe
|
|
|
|
|
desc Text Maybe
|
2016-09-02 02:40:02 +09:00
|
|
|
scope WorkflowScope
|
2016-08-08 20:05:19 +09:00
|
|
|
|
|
|
|
|
UniqueWorkflow sharer ident
|
|
|
|
|
|
2016-08-08 23:01:06 +09:00
|
|
|
WorkflowField
|
2016-08-11 18:27:30 +09:00
|
|
|
workflow WorkflowId
|
|
|
|
|
ident FldIdent
|
|
|
|
|
name Text
|
|
|
|
|
desc Text Maybe
|
|
|
|
|
type WorkflowFieldType
|
|
|
|
|
enm WorkflowFieldEnumId Maybe
|
|
|
|
|
required Bool
|
|
|
|
|
constant Bool
|
|
|
|
|
filterNew Bool
|
|
|
|
|
filterTodo Bool
|
|
|
|
|
filterClosed Bool
|
2016-08-08 23:01:06 +09:00
|
|
|
|
|
|
|
|
UniqueWorkflowField workflow ident
|
|
|
|
|
|
2016-08-08 23:48:38 +09:00
|
|
|
WorkflowFieldEnum
|
|
|
|
|
workflow WorkflowId
|
|
|
|
|
ident EnmIdent
|
|
|
|
|
name Text
|
|
|
|
|
desc Text Maybe
|
|
|
|
|
|
|
|
|
|
UniqueWorkflowFieldEnum workflow ident
|
|
|
|
|
|
2016-08-09 02:05:09 +09:00
|
|
|
WorkflowFieldEnumCtor
|
|
|
|
|
enum WorkflowFieldEnumId
|
|
|
|
|
name Text
|
|
|
|
|
desc Text Maybe
|
|
|
|
|
|
|
|
|
|
UniqueWorkflowFieldEnumCtor enum name
|
|
|
|
|
|
2016-08-09 05:51:58 +09:00
|
|
|
TicketParamText
|
|
|
|
|
ticket TicketId
|
|
|
|
|
field WorkflowFieldId
|
|
|
|
|
value Text
|
|
|
|
|
|
|
|
|
|
UniqueTicketParamText ticket field
|
|
|
|
|
|
2016-08-09 20:36:14 +09:00
|
|
|
TicketParamEnum
|
|
|
|
|
ticket TicketId
|
|
|
|
|
field WorkflowFieldId
|
|
|
|
|
value WorkflowFieldEnumCtorId
|
|
|
|
|
|
|
|
|
|
UniqueTicketParamEnum ticket field value
|
|
|
|
|
|
2016-05-01 05:40:33 +09:00
|
|
|
Ticket
|
2016-06-02 01:20:19 +09:00
|
|
|
project ProjectId
|
|
|
|
|
number Int
|
|
|
|
|
created UTCTime
|
|
|
|
|
creator PersonId
|
|
|
|
|
title Text
|
|
|
|
|
desc Text -- Assume this is Pandoc Markdown
|
|
|
|
|
assignee PersonId Maybe
|
2016-08-11 09:44:11 +09:00
|
|
|
status TicketStatus
|
2016-06-02 01:20:19 +09:00
|
|
|
closed UTCTime
|
|
|
|
|
closer PersonId
|
|
|
|
|
discuss DiscussionId
|
2016-05-01 05:40:33 +09:00
|
|
|
|
|
|
|
|
UniqueTicket project number
|
2016-05-18 05:34:22 +09:00
|
|
|
|
2016-06-08 05:16:15 +09:00
|
|
|
TicketDependency
|
|
|
|
|
parent TicketId
|
|
|
|
|
child TicketId
|
|
|
|
|
|
|
|
|
|
UniqueTicketDependency parent child
|
|
|
|
|
|
2016-06-07 19:01:57 +09:00
|
|
|
TicketClaimRequest
|
|
|
|
|
person PersonId
|
|
|
|
|
ticket TicketId
|
2016-06-08 01:31:55 +09:00
|
|
|
message Text -- Assume this is Pandoc Markdown
|
2016-06-07 19:01:57 +09:00
|
|
|
created UTCTime
|
|
|
|
|
|
|
|
|
|
UniqueTicketClaimRequest person ticket
|
|
|
|
|
|
2016-05-18 05:34:22 +09:00
|
|
|
Discussion
|
2016-05-20 01:58:23 +09:00
|
|
|
nextMessage Int
|
2016-05-18 05:34:22 +09:00
|
|
|
|
|
|
|
|
Message
|
|
|
|
|
author PersonId
|
|
|
|
|
created UTCTime
|
|
|
|
|
content Text -- Assume this is Pandoc Markdown
|
|
|
|
|
parent MessageId Maybe
|
|
|
|
|
root DiscussionId
|
2016-05-20 01:58:23 +09:00
|
|
|
number Int
|
|
|
|
|
|
|
|
|
|
UniqueMessage root number
|
2019-02-12 20:46:12 +09:00
|
|
|
|
|
|
|
|
RepoCollab
|
|
|
|
|
repo RepoId
|
|
|
|
|
person PersonId
|
|
|
|
|
role ProjectRoleId Maybe
|
|
|
|
|
|
|
|
|
|
UniqueRepoCollab repo person
|
|
|
|
|
|
|
|
|
|
ProjectCollab
|
|
|
|
|
project ProjectId
|
|
|
|
|
person PersonId
|
|
|
|
|
role ProjectRoleId Maybe
|
|
|
|
|
|
|
|
|
|
UniqueProjectCollab project person
|
