Audit trail for more owner actions

[carols10cents]

Further steps beyond #1478. These changes wouldn't be exposed in the UI but would be in the database for us to use in determining who took what actions when.

• [x] Add a column to the api_tokens table named revoked that's a BOOLEAN NOT NULL DEFAULT 'f'. Then instead of deleting tokens, mark them as revoked.

• [x] Create a migration (using diesel migration generate, as explained in this guide) that adds a new table named version_owner_actions with the following columns:

  • id SERIAL PRIMARY KEY
  • version_id FOREIGN KEY REFERENCES versions (id)
  • owner_id FOREIGN KEY REFERENCES users (id)
  • owner_token_id FOREIGN KEY REFERENCES api_tokens (id)
  • action INTEGER NOT NULL (that would map to a Rust enum with variants publish, yank, unyank)
  • time TIMESTAMP NOT NULL DEFAULT now()

• [x] Keep the headers[0] authorization header value accessible by holding onto it in the AuthenticationSource::ApiToken variant

• [x] Within the crate publish transaction, after the new version record is created, create a new version owner action record with action = "publish", version_id = version.id, owner_id = user.id, owner_token = req.authentication_source() (and then extract the token value)

• [x] Make similar changes to add records to the activity table in yank and unyank

• [ ] Add a field to EncodableVersion that's a Vec of all the actions, owner ids, and times that this version has had an action taken on it so that this info, minus the api token value, is returned in the API response

• [ ] Add a table crate_owners_actions that records who adds and removes other owners from a crate

• [ ] Add tests that this information is being recorded and returned as expected

[hinchley2018]

@carols10cents This sounds like a fun issue to sink my teeth into. Would you mind if I pick this up? Is there a deadline for completing this? (might take me a few weeks)

[carols10cents]

I don't mind at all, and no, there's no deadline!

[carols10cents]

There's some discussion that happened in https://github.com/rust-lang/crates.io/pull/2025 that's relevant to implementation:

I was imagining information like "user x added user y as an owner at datetime" being available publicly so that anyone could audit the risk of activities being malicious or not.

I feel like knowing when an invitation is sent and when an invitation is rejected are not useful pieces of information; it's only when an invitation is accepted and a crate has a new owner that it's interesting. What do you think?

we do need to think about cases when a person might want to remove all association they have with a crate, past and present. So user_a, who was owner of crate_b at some point, now wants nothing to do with crate_b and doesn't want crates.io to show that they were ever owner of crate_b.

[carols10cents]

Just had a thought-- because we sometimes use emails sent from the same address as the verified email address in crates.io, it might be useful to know if an account's verified email address has been changed recently.

Sometimes we say "hey can you send us an email from the verified address" and for whatever reason the person needs to change the verified address to something else and that's totally legitimate. But if it's been set to firstname.lastname@gmail.com for years, then it gets set to something1234@disposable-email.com and then we get a request to do something with a crate, that might be a sign that something suspicious is going on.

Right now, I think we just overwrite the old verified email address if it's changed; it would be nice to keep those historical records around marked as old/invalid/superseded but viewable in the database and/or admin web UI someday.