(trying to reference the current commit)
99c99a8

It looks like prometheus has changed its dependency tree, and when I download the repo from this commit and run 'make' it fails with the above error.

updating prometheus:

- import "github.com/prometheus/client_golang/prometheus"
+  import "github.com/prometheus/client_golang/prometheus/promhttp"

and changing line 27

- Handler: prometheus.Handler()
+ Handler: promhttp.Hanlder()

fixes the error, but then introduces new dependency issues.
The build then fails on go version 1.7 due to the missing math/bits standard library.
Updating to go 1.9 fixes the math/bits dependency but is missing bits.Add64 and bits.Mul64
Updating to go 1.12 fixes the dependency issues without breaking dep

Conclusion: updating to go 1.12 and the above patches allows the container to build and run
Should I submit a pull request with the above changes?

For left/right owners:

• If there is a name in both the left and right groups, don't decrypt the data with only their delegation.

It is sometimes useful to have characters like '-' or '_' in labels, but Red October fails silently when you do this. It should allow at least a limited set of these characters or explicitly error out when they are used.

Right now to create an account, you have to "delegate" with 0/0. The webpage should be updated to have an account creation option.

The ability to use web hooks to notify for order requests and order cancelations would be pretty awesome.

Has the functionality been built yet to allow data to be stored on database like mongo, mysql etc instead of a local JSON store?

The docs currently describe how to create a self-signed cert from OpenSSL, this should be updated to a more modern practice.

The UI placeholder text has been a source of confusion for many users. It should either have a useful value as the actual text or contain verbiage indicating that it needs to be filled in.

Accounts are created with delegate, they should have a dedicated API that allows for a choice of key type.

When calling decrypt on an object that does not have enough delegations, check to see if the missing delegation is from the account asking to decrypt. If it is, issue an implicit delegation for that user's password that is valid for only that user, for 1 decryption, and validity only until the decryption is complete.

c.f. e2669c7

It might make more sense to have merging take a mask configuration as well.

On the UI, the label for the order number is "slot", but the parameter is "ordernum." This is inconsistent, and we should consider either renaming the parameter or changing the label.

At the moment the vendored copy of go-systemd is:

Which corresponds to commit:

coreos/go-systemd@fa8411d

This is July 2016, a bit outdated.

To include redoctober in Debian, we need to build it against a latest version of go-systemd, namely version v17. Building redoctober against it fails with:

# github.com/cloudflare/redoctober/server
src/github.com/cloudflare/redoctober/server/server.go:155:41: too many arguments in call to activation.Listeners
	have (bool)
	want ()

Thanks

Non-admin users should be able to decrypt if they were listed in the set of delegated decryptors.

Currently, the UI will not specify a minimum although it shows what appears to be a default. This leads to situations where users create ciphertexts which can't be decrypted (because they require a minimum of 0 owners and don't get any actual encryptions). This should be handled better from a UX perspective:

• The UI & backend should only allow valid values of "Minimum" and should require a predicate when Minimum == 0.
• The UI should offer a dropdown that clearly explains how to use this, to steer people towards not falling into this trap.
  I've seen this happen several (at least 3) separate times, and it's an easy fix.

The docs should be updated to reflect the "user" and "label" features.

Red October account names are currently case sensitive which is a bad practice.

Hello,

I have followed the install steps in the README and I am running it with this command:

/root/go/bin/redoctober -addr=localhost:8080
-vaultpath=/root/diskrecord.json
-cert=/root/go/cert/server.crt
-key=/root/go/cert/server.pem

I have created the cert with the provided "unsecure" steps to create a self-signed certificate.

Now when I am running it I get no message, no error, and when I try to connect to it with "lynx" it won't connect.
[root@ns4007886 ~]# lynx https://localhost:8080

Looking up localhost:8080
Making HTTPS connection to localhost:8080
Alert!: Unable to connect to remote host.

lynx: Can't access startfile https://localhost:8080/

I get no error message from redoctober, how can I know what I've done wrong and how to configure and run it correctly?

PS: I'm installing it on a dedicated server with CentOS.

Thanks,
Alex.

right now all flags are specified before subcommand, it is very counter-intuitive. Make it proper subcommand. And make each subcommand only accept flags that are meaningful to itself.

If you re-encrypt to a predicate, Red October ignores the predicate and returns "Invalid access structure".

requires GODEBUG=x509ignoreCN=0 to work, and therefore can't work on go 1.17+
https://github.com/cloudflare/redoctober/blob/master/scripts/docker-entrypoint.sh#L17

If any user name being delegated to doesn't exist, the API (and UI) should return an error.

curl --cacert cert/server.crt https://localhost:8080/password
-d '{"Name":"Alice","Password":"Lewis","ToModify":"Bob","Command":"admin}'

Missing the last " on the command

Is there a way to add a delegate to a vault so that they are there permanently?

It causes such encryption to have problems when decrypting.

Currently, if you delegate and specify users who can decrypt, Red October will only allow those users to make successful decryptions for secrets in the bailiwick of the delegation. However, if you specify an empty users string, Red October abdicates any checking of the user calling decrypt. This nonlinear behavior is not expected, and should be fixed. The ability for anyone to decrypt should be preserved as its own option and should be controlled by metadata on delegation state instead of by overloading the users list.

A possible scenario: Three key owners: Alice, Bob and Charlie.
Alice delegates for 1 uses and both Bob and Charlie delegates for 2 uses. If there are two decryption requests coming in at the same time, Alice's delegation will be double-booked and result in one of the decryption requests being denied. Some async locking might be necessary.

The ro client will continue to try to connect and does not respond to ^C but instead has to be forcibly quit.

I started a redoctober instance and it was up and running fine, until I stopped it.
Every time I stop and try to start redoctober again I get the following error:

Along the same lines as httptest, it would be useful to have a test / stub server that can be used with the the client package in testing. This enables programs that use Red October integration to be tested.

This is crucial for securing accounts on services which offer two-factor authentication but do not implement the two-person-rule natively.

A protocol for such services to directly communicate the private key to Red October would be a big plus.

If the appropriate number of people are delegated, it should be possible to take an encrypted message and encrypt it to a new set of users.

we may refactor the test setup as well.

Currently, Red October considers that delegations "apply" to a decryption usage if any label in the delegation matches a label in the ciphertext: From https://github.com/cloudflare/redoctober/blob/master/keycache/keycache.go#L64-L71:

    for _, validLabel := range usage.Labels {
        for _, label := range labels {
            if label == validLabel {
                return true
            }
        }
    }
    return false

As a refinement of this, it could match all labels instead. I'm not sure I see a reason not to do this, and it allows for stricter access control when secrets have multiple labels. For example, if there are three secrets with labels like so 1:(A, B); 2:(A, C); and 3:(B, C), I would be able to delegate for someone to decrypt 1 but not 2 or 2 but not 3. Presently, this is not possible.

This is a low-priority enhancement - I don't see any near-term need to have multiple labels, I just noticed this while trying to match the label-handling behavior somewhere else, was surprised, and wanted to document it.

If someone attempts to decrypt a file for which does not have the appropriate delegations, it currently returns with an error. This workflow can be improved with an alerting infrastructure.

On first decryption attempt: create a decryption request, which contains references to each of the users in the owner set of the file to be decrypted. If there are not enough keys delegated, select the users who can enable the decryption and send them a notification containing the following:

• which user is requesting decryption
• which labels are tied to the file
• a link to the delegation page with default values filled in (requesting user, labels, number of decryptions: 1)

Once enough owners have delegated the key for the file, the original requestor is given a notification that the file can be decrypted. Alternatively, the original request can be made to block until the file can be decrypted.

Admins should be able to purge all delegations.

Having version information available would be useful.

A Red October server should be able to list the required delegations for an encrypted secret. This should also be included in the Web UI.

Red October should expose standard metrics via Prometheus.

go tosses errors when attempting to build redoctober.

shell$ go get github.com/cloudflare/redoctober/

github.com/cloudflare/redoctober/passvault

/usr/lib/go/src/pkg/github.com/cloudflare/redoctober/passvault/passvault.go:328: function ends without a return statement
/usr/lib/go/src/pkg/github.com/cloudflare/redoctober/passvault/passvault.go:341: function ends without a return statement

A user should be able to create multiple non-overlapping delegations. For example, it should be valid to delegate 1 decryption for label foo for 1 minute at the same time as 10 decryptions for label bar for 10 hours, and have these expire independently.

This can be achieved in a backwards-compatible way by creating the concept of a labeled delegation "slot". The current delegations will be given the "default" slot. When creating a delegation, an additional slot parameter should be permitted. Every new delegation should replace the current delegation for a given slot.

For Red October, a person delegating decryption parameters should be allowed to choose a set of users who are allowed to do the decryption. This can include people who were not on the list of owners for a given asset.

When encrypting an asset, you should be able to assign a set of labels identifying the asset. When delegating, you should be able to choose a list of labels for which the delegation is valid.

In one usage, user A is getting 3 delegations while user B is only using 1. They should be using the same number of delegations.

Go-fuzz found that "(),)" crashes StringToMSP. I might try to debug this later today, but I'll add an issue in case I don't get the chance.

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x458130]

goroutine 1 [running]:
github.com/cloudflare/redoctober/msp.StringToFormatted(0xc82000a663, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/go-fuzz-build967867540/src/github.com/cloudflare/redoctober/msp/formatted.go:72 +0x1150
github.com/cloudflare/redoctober/msp.StringToMSP(0xc82000a660, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/go-fuzz-build967867540/src/github.com/cloudflare/redoctober/msp/msp.go:108 +0x314
github.com/cloudflare/redoctober/msp.Fuzz(0x7fb3a13cf000, 0x4, 0x200000, 0x3)
    /tmp/go-fuzz-build967867540/src/github.com/cloudflare/redoctober/msp/msp_fuzz.go:4 +0x8f
github.com/dvyukov/go-fuzz/go-fuzz-dep.Main(0x5f77c0)
    /home/andrew/go/src/github.com/dvyukov/go-fuzz/go-fuzz-dep/main.go:47 +0x14c
main.main()
    /tmp/go-fuzz-build967867540/src/go-fuzz-main/main.go:10 +0x23
exit status 2

If not, when do you plan to make a release?