Getting InsecureSecretKey error on release build

[InstinctBas]

This is very likely user error but trying out my project on a test server with the release build, I'm getting an InsecureSecretKey error when starting up.

I've generated my secret key as instructed on the help pages with openssl rand -base64 32

My Rocket.toml file contains:

[release]
...
secret_key = "<base64 string pasted in>"

This worked on v4 (but with [production] as the entry.

Any ideas what I'm doing wrong?

Thanks, Bas

[InstinctBas]

One thing I was wondering about is that a / character is present in my base64 string, could it be that this needs to be escaped?

[SergioBenitez]

If you're using the default config provider, then that suffices. You just need to make sure that the Rocket.toml file is in the CWD or a parent of where you are building running.

[InstinctBas]

also yes, log => log_level

[InstinctBas]

@SergioBenitez looking at the source code, the secret key is checked before we print any information about the configuration. That makes sense as at this point the configuration is still being amended (i.e. we may create a secret key if we're not in production).

This does mean that if we exit at an error at this place (i.e. https://github.com/SergioBenitez/Rocket/blob/master/core/lib/src/rocket.rs#L551), we haven't output any useful information.

Seeing the code here:

        #[cfg(feature = "secrets")]
        if !config.secret_key.is_provided() {
            if config.profile != Config::DEBUG_PROFILE {
                return Err(Error::new(ErrorKind::InsecureSecretKey(config.profile.clone())));
            }

It is clear that the error is caused because no configuration is loaded, and seeing this is only happening in docker I'm guessing at this point I have an rights issue...

The error is misleading btw, no secret key is provided...

edit ah, I'm wondering if dockers file replacement is to blame here... that explains why before the error was about incorrect characters...
I assume that if the secret key is incorrect it will be cleared, hence is_provided() returning false not just when no secret key is present, but also if an incorrect secret key is present?

[SergioBenitez]

@SergioBenitez looking at the source code, the secret key is checked before we print any information about the configuration. That makes sense as at this point the configuration is still being amended (i.e. we may create a secret key if we're not in production).

This does mean that if we exit at an error at this place (i.e. https://github.com/SergioBenitez/Rocket/blob/master/core/lib/src/rocket.rs#L551), we haven't output any useful information.

Seeing the code here:

        #[cfg(feature = "secrets")]

        if !config.secret_key.is_provided() {

            if config.profile != Config::DEBUG_PROFILE {

                return Err(Error::new(ErrorKind::InsecureSecretKey(config.profile.clone())));

            }

It is clear that the error is caused because no configuration is loaded, and seeing this is only happening in docker I'm guessing at this point I have an rights issue...

The error is misleading btw, no secret key is provided...

Please let me know what the root cause is once you determine it. If we can provide helpful information during launch to avoid whatever kind of issue it is you're encountering, I'd love to add that in.

[InstinctBas]

Ok I figured it out, kind off, and the problem isn't Rocket but it is docker. And it turns out it has been broken for years, it is just that v4 was happy to generate a secret key if none was provided in production (not a complaint, I agree v5 this loophole has been closed).

So we deploy our solution to our servers through docker, the docker image has default configuration files that shouldn't work in production. On the servers we have the proper configuration file for that server and when deploying the image we mount those files.

It was mounting our config file, but it wasn't mounting the rocket one. It just silently failed.

I think the cause is because mounting files isn't really supported well in docker, it's kind of a loop hole thing. Its meant for mounting folders, so I'm guessing because both config files are in the same folder it is just skipping over it.

I've got it to work now by taking a different approach to this.

My only suggestion for Rocket atm is that it should log a bit more state when there is a failure. It's a bit of a catch-22 I guess seeing we're so early on in the setup and Rocket hasn't had time to evaluate a whole lot of state.

I think for this particular case it would be nice if it actually logged the key value with the error. I guess that is a potential security risk if it logs an actually valid key, but it would also have told us more of what is going on.

[SergioBenitez]

With 615e70f, Rocket, with debug logs enabled, will now print the source location (provenance) of every configuration variable it reads. This would have immediately told you that it was not reading your Rocket.toml file. Hopefully this helps folks in the future.