-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secret rotation / secret loss recovery #16832
Comments
For any people unfortunate enough to be frantically Googling this at 11 PM like I was: I was moving my infrastructure to Nix, and the NixOS module for Gitea automatically generated a secret key for me, and so I couldn't log in because it wasn't using the default. In case anyone needs it, the default secret key is here. |
Help some users like #16832 #1851 There are many users reporting similar problem: if the SECRET_KEY mismatches, some operations (like 2FA login) only reports unclear 500 error and unclear "base64 decode error" log (some maintainers ever spent a lot of time on debugging such problem) The SECRET_KEY was not well-designed and it is also a kind of technical debt. Since it couldn't be fixed easily, it's good to add clearer error messages, then at least users could know what the real problem is. --------- Co-authored-by: delvh <[email protected]>
Backport #24573 Help some users like #16832 #1851 There are many users reporting similar problem: if the SECRET_KEY mismatches, some operations (like 2FA login) only reports unclear 500 error and unclear "base64 decode error" log (some maintainers ever spent a lot of time on debugging such problem) The SECRET_KEY was not well-designed and it is also a kind of technical debt. Since it couldn't be fixed easily, it's good to add clearer error messages, then at least users could know what the real problem is.
id also like to be able to change this from the default |
An approach we could take is what minio does where they will take old and new key as config option to rotate |
Note that this is included in the original description, albeit probably not clearly enough. I'll take another pass through it and see what I can do to make that clearer. EDIT: I've updated the original post to use bulleted lists wherever possible, so that it's hopefully clearer to skim and see the potential tasks people could work on. IMHO we should probably create separate issues for the individual pieces. |
I have a similar issue after upgrading an installation from the gitea helm chart. In the installation the
Setting the |
For me I was getting this issue on every runner following a restored PostgreSQL dump for Gitea:
I removed the secrets for the org/repo (simply updating them did not work), re-added them, and then the error went away and CI jobs ran as expected. |
And what needs to be set? Copied my old gitea data where there is no SECRET_KEY inside the app.ini. I tried setting the SECRET_KEY to the default value but it still doesn't work, still getting this AesDecrypt error. Can't login anymore, this is very frustrating and undocumented... EDIT: "Fixed" it by deleting the relevant entries from the two_factor database table and regenerating the 2FA token... |
Just went through this as well. The gitea service module let you write the configuration normally found in the
Now, because it is already defined i the module, on build Nix will not be happy stating that you have conflicting values, yours and the one from the package. So you can use something like
Better yet, in order to not have the key in the Nix store you can use a secret manager like Agenix or Nix-sops and rely on the gitea/modules/setting/security.go Line 104 in fb32b4c
SECRET_KEY so that SECRET_KEY_URI can be taken into account:
Please do note that I am no NixOS expert so maybe it's not the best way to deal with this. If so please do let me know. |
I've run into issues like #1851 in the past and didn't realise it was due to the
SECRET_KEY
changing when recreating a config. It would be nice if we could somehow add some mitigations to this.Recovery from secret loss
If the secret is changed without access to the previous secret, and things like 2FA secrets can't be decrypted, then there should be some easy way to mitigate this. Right now, the only solution is to delete the corrupted rows in the DB manually.
A few potential options:
gitea doctor
command to delete 2FA data, potentially notifying users who had 2FA enabledProactive secret rotation
If the user wishes to proactively change the secret, there should be an option to include (at least) two secrets in the config: the new secret for future operations, and the old secret for past operations.
A few options here:
gitea doctor
command to re-encrypt things encrypted with a backup secret.The actual action upon rotation of the secret depends on the reason for the rotation. If there's some kind of breach of security, things that were protected by the secret like 2FA keys should be regenerated. So, a few options here:
The text was updated successfully, but these errors were encountered: