Skip to content
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

Add Gitea secrets storage and management #14483

Closed
wants to merge 61 commits into from

Conversation

lafriks
Copy link
Member

@lafriks lafriks commented Jan 27, 2021

Also needed for #13539

some screenshots:
repository level secrets
image

org level secrets
image

@kdumontnu
Copy link
Contributor

kdumontnu commented Mar 22, 2021

Does this close #12065?

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 22, 2021
@lafriks
Copy link
Member Author

lafriks commented Mar 23, 2021

Yes, this could be used to resolve that

@lafriks lafriks mentioned this pull request Jul 14, 2021
@ansemjo ansemjo mentioned this pull request Aug 7, 2021
5 tasks
@lafriks lafriks mentioned this pull request Jan 21, 2022
@InCogNiTo124
Copy link

InCogNiTo124 commented Mar 30, 2022

Any update on this?

1 similar comment
@yctn
Copy link

yctn commented Apr 26, 2022

Any update on this?

@lunny
Copy link
Member

lunny commented Sep 25, 2022

@lafriks Could I pick up this PR?

@lunny lunny added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Sep 26, 2022
@lunny lunny added this to the 1.18.0 milestone Sep 26, 2022
wolfogre and others added 5 commits December 13, 2022 17:09
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
})
}

func InsertOrgSecret(ctx context.Context, userID int64, key, data string) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a name mismatch here: InsertOrgSecret and FindUserSecrets. I would rename both to Owner. Maybe change the structs member too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about the struct fields.
But we should find a name to stick with as OwnerSecret sounds abolutely wrong to me and doesn't clarify the difference to RepoSecrets enough.
What about UserSecrets instead, even if they can also be for an organization?

@JakobDev
Copy link
Contributor

This PR has currently secrets on Repo and Organisation level. Could you also add Secrets to the User level, that would apply to all personal Projects?

@delvh
Copy link
Member

delvh commented Dec 13, 2022

I have thought about that as well, but what would the benefit be?
When do you really need user global secrets?

@KN4CK3R
Copy link
Member

KN4CK3R commented Dec 13, 2022

The same as org secrets? Available for every repo.

The package registry may need secrets at the owner (user/org) level too. The Debian registry for example uses a gpg key to sign data which could be stored in the secrets.

@delvh
Copy link
Member

delvh commented Dec 13, 2022

Okay, yes that's makes sense.
Then let's remove the differentiation between users and organizations, and add it for all owners.

@JakobDev
Copy link
Contributor

When do you really need user global secrets?

I need them. On GitLab I have a lot of personal projects. Mostly little tools. Almost all have a CI (mostly just publish to e.g.g PyPI on a new Release). a lot of them share the same secrets (e.g. PyPI credentials). As GitLab does not allow secrets on User level, I need to add everything for each Repo new and when something changed, that means a lot of work for me, to change it for every single Repo. I'm currently moving to Codebreg, which uses Gitea. If you add add secrets management, it would be great to allow this on User level to save me a lot of Work. Of course, I could create a Org just for my personal projects, but that feels a little bit unnecessary.

})
}

func InsertOrgSecret(ctx context.Context, userID int64, key, data string) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about the struct fields.
But we should find a name to stick with as OwnerSecret sounds abolutely wrong to me and doesn't clarify the difference to RepoSecrets enough.
What about UserSecrets instead, even if they can also be for an organization?

@@ -1,6 +1,5 @@
// Copyright 2021 The Gitea Authors. All rights reserved.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we copyright the year the code was written, or the year it is merged?
I would have thought it is the year it is merged…

Comment on lines 36 to 38
UserID int64 `xorm:"index NOTNULL"`
RepoID int64 `xorm:"index NOTNULL"`
Name string `xorm:"NOTNULL"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it be that the suggestions in this file were missed?

}

func InsertRepoSecret(ctx context.Context, repoID int64, key, data string) error {
v, err := EncryptString(data)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've also mentioned it above, but here it is again:
I think it would be a good idea to strip leading and trailing whitespace from secrets.
There is only a marginal benefit in not doing it (who has a secret that starts or ends with whitespace?).
However, there is a huge benefit for usability, since many copying programs add for example whitespace at the end, meaning you would get an invalid secret that you first have to debug why it isn't working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved in the new PR.

settings.pull_request_read_hint = Allow pull request read the secret
settings.add_secret = Add Secret
settings.add_secret_success = The secret '%s' has been added.
settings.secret_value_content_placeholder = Input any content
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming my suggestion above is implemented:

Suggested change
settings.secret_value_content_placeholder = Input any content
settings.secret_value_content_placeholder = Input any content. Whitespace at the start and end will be omitted.

Then suddenly this placeholder isn't redundant anymore.

@wolfogre
Copy link
Member

Hi guys, I wonder if I can start a new PR with all commits kept?

I tried to fix problems ASAP to stop blocking #21937, and @lafriks kindly gave me access to push to his branch, but I still can't mark comments resolved or update the PR content to explain what I'm trying to do, because I'm not the poster. I think it's OK yet, but if we want to add more to this PR like "secrets for users" or "trimming whitespace", I think I can handle it faster with a new PR.

I know it will cause some inconvenience to reviewers, so I think it's also a good idea to merge this PR with some todos left, and start a new PR to finish them.

What do you think?

@lunny
Copy link
Member

lunny commented Dec 14, 2022

Hi guys, I wonder if I can start a new PR with all commits kept?

I tried to fix problems ASAP to stop blocking #21937, and @lafriks kindly gave me access to push to his branch, but I still can't mark comments resolved or update the PR content to explain what I'm trying to do, because I'm not the poster. I think it's OK yet, but if we want to add more to this PR like "secrets for users" or "trimming whitespace", I think I can handle it faster with a new PR.

I know it will cause some inconvenience to reviewers, so I think it's also a good idea to merge this PR with some todos left, and start a new PR to finish them.

What do you think?

I personally prefer to leave some todo like supporting user level secrets in next PRs and we can merge this one ASAP.

@wolfogre
Copy link
Member

wolfogre commented Dec 14, 2022

In the process of helping to fix problems, I took a close look at the code. Finally, to be honest, I am against this PR.

The point is that I think we don't need a new MasterKey, we should use SecretKey. These are my reasons:

  • SecretKey can do what MasterKey can do, and they have similar designs:
    • SECRET_KEY vs MASTER_KEY
    • SECRET_KEY_URI vs MASTER_KEY_PROVIDER
    • EncryptString/DecryptString vs EncryptSecret/DecryptSecret
  • MasterKey will use SECRET_KEY when MASTER_KEY is empty:
    • That means it's possible to treat SecretKey as MasterKey.
  • Response to "SECRET_KEY could be stored encrypted by MASTER_KEY in the future when we add server-wide secret storage we could than use 'internal' secrets that would be protected by master key"
    • It doesn't make sense to move a key from the config file into encrypted storage and add a new one into the config file.
    • SecretKey can also protect "internal" secrets, and it's already done something like that.
  • MasterKey isn't a better name:
    • Come on guys, have you forgotten why we changed the default branch name to "main"?
    • I know this is not where it came from, but SecretKey can be understood as a key to protect other secrets.

If we agree to give up MasterKey, some commits and comments will be out of topic.

So I will start a new PR as an alternative with necessary commits kept, and if I'm wrong, we can continue with this one.


See:

@@ -51,6 +52,10 @@ func DeleteRepository(ctx context.Context, doer *user_model.User, repo *repo_mod
return err
}

if err := secret_service.DeleteSecretsByRepoID(ctx, repo.ID); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you would simply use models.DeleteRepository#130-152 for it…

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved in the new PR.

@@ -39,6 +40,10 @@ func DeleteOrganization(org *organization.Organization) error {
return models.ErrUserOwnPackages{UID: org.ID}
}

if err := secret_service.DeleteSecretsByOwnerID(ctx, org.ID); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you would simply use models/DeleteUser#72-91.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved in the new PR.

Comment on lines +39 to +40
OwnerID int64 `xorm:"UNIQUE(owner_repo_name) NOTNULL"`
RepoID int64 `xorm:"UNIQUE(owner_repo_name) NOTNULL"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not remove the indexes. They can still be valuable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved in the new PR.

@lunny
Copy link
Member

lunny commented Dec 15, 2022

I think we can close this and switch to #22142

lunny added a commit that referenced this pull request Dec 20, 2022
Fork of #14483, but [gave up
MasterKey](#14483 (comment)),
and fixed some problems.

Close #12065.
Needed by #13539.

Featrues:
- Secrets for repo and org, not user yet.
- Use SecretKey to encrypte/encrypt secrets.
- Trim spaces of secret value.
- Add a new locale ini block, to make it easy to support secrets for
user.

Snapshots:

Repo level secrets:

![image](https://user-images.githubusercontent.com/9418365/207823319-b8a4903f-38ca-4af7-9d05-336a5af906f3.png)

Rrg level secrets

![image](https://user-images.githubusercontent.com/9418365/207823371-8bd02e93-1928-40d1-8c76-f48b255ace36.png)

Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
@lunny
Copy link
Member

lunny commented Dec 20, 2022

replaced by #22142

@lunny lunny closed this Dec 20, 2022
@lunny lunny removed this from the 1.19.0 milestone Dec 20, 2022
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 1 This PR needs approval from one additional maintainer to be merged. type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Development

Successfully merging this pull request may close these issues.