This commit adds basic sentry reporting. If enabled by setting the
appropriate configuration value, it will report panics and errors.
Certain functions in the core package (Delegate, Encrypt, Decrypt,
Restore, and ResetPersisted) have additional Sentry reporting as
these are the most common errors.
+ If a valid hipchat configuration is provided, send a message when
Red October has restarted.
+ If persistence is inactive, alert the channel that this is the case.
+ Add a lock to the keycache.
+ Ensure that all instantiations of keycaches use New, rather
than the old keycache.Cache{make()} construct. This no longer
works with the lock in place.
+ Update travis to run the race detector on a few specific packages
that should help identify this type of problem in the future.
When delegating to a group of users, Red October will return the
error "User not found" if the user can't be found. This makes it
difficult to figure out the user that couldn't be found. This change
goes through the list of users and includes all usernames that
couldn't be found in the error message.
This change addresses several points:
1. The integration tests didn't verify that delegations could be used
for decryption following a restore. The integration tests now
verify this.
2. There was no functionality for clearing persisted delegations if
needed. The vault admin can now do this via the command line tool.
3. Restoring active delegations wasn't storing the key with the
delegation. Keys are now serialised properly.
4. [Minor] The MSP package now reports the name of the offending user
when it can't find a user name in the database.
+ Add a new restore UI box. When a user delegates successfully for a
restoration, the current restoration state is returned.
+ Add the persistence state to the summary output.
+ Rename "ordernum" to "slot": this is a longstanding complaint about
the UI, and I fixed it while I was mucking about with this PR.
This is a rather large change. It consists of the following changes:
+ Direct access to the keycache has been removed from the core
package. This forces all interaction with the cache to go
through the Cryptor, which is required for persistence. The
Cryptor needs to know when the cache has changed, and the only
way to do this effectively is to make the Cryptor responsible
for managing the keycache.
+ A new persist package has been added. This provides a Store
interface, for which two implementations are provided. The
first is a null persister: this is used when no persistence
is configured. The second is a file-backed persistence store.
+ The Cryptor now persists the cache every time it changes.
Additionally, a number of missing returns in a function in the core
package have been added.
This pull request adds a status endpoint to the Red October server; as
of this pull request, the status endpoint only returns the current
delegation persistence state. The HTTP UI has not been updated, as
this is scoped out for a future request; however, the CLI utility now
features a status command to fetch this information.
Don't assume that the creator of the order wants the delegations.
Instead it's much nicer with our current scheme to take in a big
slice of people who want delegations, so that each person who ne
eds a delegation doesn't need to make an order.
Supports MSP and requires several arguments to add hipchat integration to
red october. RedOctober will then alert on creation of an order, any new
delegation, or several other states.
The "minimum" parameter was ignored, so when a single user
was provided as an owner, the encrypted data had no KeySet value
and could not be decrypted.
This change fixes the API and cryptor to pay attention to the Minimum
parameter and handle the case where Minimum is 1
The idea is to create a new type (to avoid ugly string parsing) and
then, instead of iterating through delegations with the username, iterate
through the delegations and look for your username and matching slot. Also
in cases we don't have the slot (everything but delegation), find the slot
when we match a user.
're-encrypt' allows us to re-encrypt an RO encryption to a different set
of owners and labels. Currently two delegations are sufficient to carry
out this operation.
This patch adds the /owners API endpoint that returns the list of users
that "own" the given secret. These are the users that can delegate their
passwords for decrypting the secret.
It also adds the "Get Owners" form in the web UI that uses the new API.
Fixes#62
- Generalize core.status to core.responseData
- Export core request types so the client can marshal/unmarshal
requests/responses
- Tested with a test script against a local redoctober server
LeftOwners and RightOwners can now be used as either disjoint
or overlapping sets of users for encrypting a message. Default
behavior is to set them to Owners given a non-empty Owners set.
One member from each group are required to decrypt the message.
