security: prevent secrets / private keys / passwords from being committed #2716

New Issue

GiteaMirror · 2025-11-02T04:45:23-06:00

GiteaMirror commented

2025-11-02 04:45:23 -06:00

Originally created by @ntimo on GitHub (Jan 6, 2019).

Gitea version (or commit ref):
Git version: 1.7 rc2
Operating system:
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL) https://try.gitea.io/ntimo/test-ssh-key/src/branch/master
- No
- Not relevant
Log gist:

Description

It is currently possible to commit secrets like a ssh private key, this should not be possible and should be forbidden by default. I think I don't have to say why having a private SSH-Key in git is not a good idea.

Maybe an option for the administrator of the Gitea instance would be good to enable/disable the committing of secrets (with the default set to disable)

Originally created by @ntimo on GitHub (Jan 6, 2019). - Gitea version (or commit ref): - Git version: 1.7 rc2 - Operating system: - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) https://try.gitea.io/ntimo/test-ssh-key/src/branch/master - [ ] No - [ ] Not relevant - Log gist: ## Description It is currently possible to commit secrets like a ssh private key, this should not be possible and should be forbidden by default. I think I don't have to say why having a private SSH-Key in git is not a good idea. Maybe an option for the administrator of the Gitea instance would be good to enable/disable the committing of secrets (with the default set to disable)

GiteaMirror added the type/proposal label 2025-11-02 04:45:23 -06:00

GiteaMirror commented

2025-11-02 04:45:24 -06:00

@clarfonthey commented on GitHub (Jan 7, 2019):

Perhaps this could be enabled by default and the way of opting out for a repo is to create some file in the repo that indicates that you're opting out? e.g. a file named THIS_REPO_CONTAINS_SECRETS

OpenSSL has very standardised formats for private keys so I think it should be pretty easy to detect. We obviously can't detect all kinds of secrets but I would say that this is good to include by default.

@clarfonthey commented on GitHub (Jan 7, 2019): Perhaps this could be enabled by default and the way of opting out for a repo is to create some file in the repo that indicates that you're opting out? e.g. a file named `THIS_REPO_CONTAINS_SECRETS` OpenSSL has very standardised formats for private keys so I think it should be pretty easy to detect. We obviously can't detect all kinds of secrets but I would say that this is good to include by default.

GiteaMirror commented

2025-11-02 04:45:24 -06:00

@ntimo commented on GitHub (Jan 7, 2019):

@clarcharr I think it would be better to have a settings button inside the Gitea repo settings to change this behavior. Having to commit a file to turn it off feels wrong to me. And indeed since the OpenSSL Keys have a pretty standardized format detection should be possible.

@ntimo commented on GitHub (Jan 7, 2019): @clarcharr I think it would be better to have a settings button inside the Gitea repo settings to change this behavior. Having to commit a file to turn it off feels wrong to me. And indeed since the OpenSSL Keys have a pretty standardized format detection should be possible.

GiteaMirror commented

2025-11-02 04:45:24 -06:00

@techknowlogick commented on GitHub (Jan 7, 2019):

In the interim, you could use githooks in Gitea, and https://github.com/awslabs/git-secrets to block secrets from being committed.

@techknowlogick commented on GitHub (Jan 7, 2019): In the interim, you could use githooks in Gitea, and https://github.com/awslabs/git-secrets to block secrets from being committed.

GiteaMirror commented

2025-11-02 04:45:24 -06:00

@0x5c commented on GitHub (Jan 7, 2019):

To complement @ntimo's comment, it seems to me like opt-out-by-file would make it possible for anyone with merge/commit abilities to sneak-in the file, which would be a major security issue, and would require adding checks for the addition of the file, which would require......
Repository settings are perfect that things like this opt-out.

I could be a good thing to be able to change the key-detection filter for a repo, in-case is creates false positives on clean files.

@0x5c commented on GitHub (Jan 7, 2019): To complement @ntimo's comment, it seems to me like opt-out-by-file would make it possible for anyone with merge/commit abilities to sneak-in the file, which would be a major security issue, and would require adding checks for the addition of the file, *which would require......* Repository settings are perfect that things like this opt-out. ------ I could be a good thing to be able to change the key-detection filter for a repo, in-case is creates false positives on clean files.

GiteaMirror commented

2025-11-02 04:45:25 -06:00

@silverwind commented on GitHub (Jan 7, 2019):

I'm strongly against gitea rejecting any content in the default configuration. There are valid use cases of commiting private keys like test fixtures or self-signed cert/key pairs.

git-secrets sounds like a good tool to use, if it can be applied in a server-side hook.

@silverwind commented on GitHub (Jan 7, 2019): I'm strongly against gitea rejecting *any* content in the default configuration. There are valid use cases of commiting private keys like test fixtures or self-signed cert/key pairs. `git-secrets` sounds like a good tool to use, if it can be applied in a server-side hook.

GiteaMirror commented

2025-11-02 04:45:25 -06:00

@0x5c commented on GitHub (Jan 7, 2019):

@silverwind
Although, that's an edge-case, and a switch in the settings of a repo is a minor hassle, at worse. Especially if the default is a security measure.

@0x5c commented on GitHub (Jan 7, 2019): `@`silverwind Although, that's an edge-case, and a switch in the settings of a repo is a minor hassle, at worse. Especially if the default is a security measure.

GiteaMirror commented

2025-11-02 04:45:25 -06:00

@TankTheFrank commented on GitHub (Jan 9, 2019):

Unexpected behaviour from "opinionated" tools is the highlight of my day.

The default should be the expected behaviour and when deciding what expected implies keep in mind that gitea is a self-hosted tool not a public SaaS service.

@TankTheFrank commented on GitHub (Jan 9, 2019): Unexpected behaviour from "opinionated" tools is the highlight of my day. The default should be the **expected behaviour** and when deciding what _expected_ implies keep in mind that gitea is a self-hosted tool not a public SaaS service.

GiteaMirror commented

2025-11-02 04:45:25 -06:00

@Amejonah1200 commented on GitHub (Jan 29, 2025):

Shouldn't the default , MVP, be: all secrets defined in [Settings > Actions > Secrets]? There is no point in having Secrets defined if you end up pushing them in.

Why not settle on this as a minimum?

@Amejonah1200 commented on GitHub (Jan 29, 2025): Shouldn't the default , MVP, be: all secrets defined in [Settings > Actions > Secrets]? There is no point in having Secrets defined if you end up pushing them in. Why not settle on this as a minimum?

GiteaMirror referenced this issue

2025-11-02 12:13:19 -06:00

[PR #2716] [MERGED] Changelog for v1.2.1 #16554

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2716