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

[ntimo]

• 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)

[clarfonthey]

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.

[ntimo]

@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.

[techknowlogick]

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

[0x5c]

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.

[silverwind]

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.

[0x5c]

@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.

[TankTheFrank]

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.