Implement VAPID key support for Web Push.

This is intended to be a low-operator-involvement, self-managing approach:

* The server generates its own VAPID key. The operator does not need to run complex `openssl` commands.
* The server rotates its VAPID key regularly. The operator does not need to maintain a calendar or run administrative tools.
* The included CLI changes allow for immediate key rotation if needed.

## Correctness

This change is speculative, to a degree, and is based on some guesses and loose understandings of the various Web Push and VAPID specs and docs. We use RustCrypto's p256 crate to generate keys rather than a dedicated VAPID crate (one does exist) as I trust their code review and security standards further, but that means that I've had to guess what kind of P256 key is actually appropriate for this use case, and what encoding clients need. If those elements are incorrect they're not hard to change, but they need further verification before we commit to them on `main`.

Changing the encoding can be done in the `src/vapid/event.rs` file. Changing the key type is more involved, but is still contained to `src/vapid/`. I already did that once, switching from `p256::SecretKey` to `p256::ecdsa::SingingKey`, and it's not too bad - takes maybe 20 minutes on a good day. The real risk is that we can't tell from the database what kind of key we have, so we need to settle this before making any permanent, durable changes to other peoples' data.

## Safety

This change stores the private key, entirely in the clear, in the Pilcrow database. Anyone who gets the database or who gets access to `vapid_signing_key` can impersonate the server in Web Push messages.

Operators are theoretically responsible for managing that risk. We are responsible for setting them up for success, and for making the right thing to do the easiest thing to do. This change tries to accomplish those goals in two ways:

* It relies on previous changes to the process' umask to ensure that the database is not readable by other OS users. OS permissions are pretty thin protection these days, as they only apply to operations carried out through the OS, but it's better than nothing at preventing casual snooping on the private key.
* Key rotation. The maximum period for which an exposed key can stay valid is 30 days, plus as long as it takes for clients to wake up, notice the key has changed, and invalidate their existing subscriptions.

The impact of a key leak is also moderate at best. We don't intend to send clients confidential information, or instruct clients to take compromising action, via push message. We intend to use them to notify clients of events that users may be interested in, like messages. Abusing the push system will, at worst, distract users or prompt them to disable notifications, or potentially deliver notifications for messages that never existed, which users can identify by reading the chat for themselves.

## Operator tooling

This change introduces the `pilcrow rotate-vapid-key` command, to immediately rotate the VAPID key. This is designed to be an online _or_ offline command: all it does is destroy the current key, so that the server will generate a new one. I've included some sketchy but complete documentation; it's probably inadequate, but then, so is that whole file.

I would resist the use of operator CLI tools as contrary to our low-admin-involvement aesthetic, but in this situation it's hard to avoid. The alternatives on the one hand are documenting the schema and telling operators how to use `sqlite3` to rotate keys, or splitting the keys into a separate database that the operator can delete outright to trigger key rotation, or on the other hand stopping to implement privileges and operator interfaces inside of Pilcrow. I think a CLI is an acceptable compromise between inadequate operator support from the one set of alternatives, and massive complexity and a large delay on the other. We will likely, however, have to revise this later.

Merges vapid-keys into push-notify.

2 files changed, 38 insertions, 0 deletions

diff --git a/src/test/fixtures/event/mod.rs b/src/test/fixtures/event/mod.rs
index 08b17e7..f8651ba 100644
--- a/src/test/fixtures/event/mod.rs
+++ b/src/test/fixtures/event/mod.rs
@@ -23,6 +23,13 @@ pub fn user(event: Event) -> Option<crate::user::Event> {
     }
 }
 
+pub fn vapid(event: Event) -> Option<crate::vapid::Event> {
+    match event {
+        Event::Vapid(event) => Some(event),
+        _ => None,
+    }
+}
+
 pub mod conversation {
     use crate::conversation::{Event, event};
 
@@ -72,3 +79,17 @@ pub mod user {
         }
     }
 }
+
+pub mod vapid {
+    use crate::vapid::{Event, event};
+
+    // This could be defined as `-> event::Changed`. However, I want the interface to be consistent
+    // with the event stream transformers for other types, and we'd have to refactor the return type
+    // to `-> Option<event::Changed>` the instant VAPID keys sprout a second event.
+    #[allow(clippy::unnecessary_wraps)]
+    pub fn changed(event: Event) -> Option<event::Changed> {
+        match event {
+            Event::Changed(changed) => Some(changed),
+        }
+    }
+}
diff --git a/src/test/fixtures/event/stream.rs b/src/test/fixtures/event/stream.rs
index 5b3621d..bb83d0d 100644
--- a/src/test/fixtures/event/stream.rs
+++ b/src/test/fixtures/event/stream.rs
@@ -14,6 +14,10 @@ pub fn user(event: Event) -> Ready<Option<crate::user::Event>> {
     future::ready(event::user(event))
 }
 
+pub fn vapid(event: Event) -> Ready<Option<crate::vapid::Event>> {
+    future::ready(event::vapid(event))
+}
+
 pub mod conversation {
     use std::future::{self, Ready};
 
@@ -60,3 +64,16 @@ pub mod user {
         future::ready(user::created(event))
     }
 }
+
+pub mod vapid {
+    use std::future::{self, Ready};
+
+    use crate::{
+        test::fixtures::event::vapid,
+        vapid::{Event, event},
+    };
+
+    pub fn changed(event: Event) -> Ready<Option<event::Changed>> {
+        future::ready(vapid::changed(event))
+    }
+}