That is to say, in what cases does it make sense to commit an unencrypted keypair to internal source control like SVN or Git?

Related question that discusses an encrypted private key: Is it bad practice to add an encrypted private key to source control?


5 Answers 5


In general mixing code and secret configuration (passwords, keys etc) in the same respository is a bad idea because generally a lot more people need (or at least would benefit from) access to the code than need access to any given secret. Also the common workflow with VCS systems is to create lots of copies.

That doesn't mean you can't put secret configuration in a VCS but it should be a seperate repository from your code and access to it should be very tightly controlled.

  • 4
    // , I like that this answer's first sentence gives me a mental tool to determine when and when not to do this, in, "generally a lot more people need (or at least would benefit from) access to the code than need access to any given secret". This means I can base my decision on how many need access to the code vs. how many need access to the secret. Thank you, Peter. Nov 18, 2015 at 19:32
  • 2
    +1. If the code needs a key to function then it may be worth including sample keys so a new viewer can grab the code and try it with fewer steps (not needing to generate any keys just for the initial demo) and/or can inspect the format to aid understanding, but I would never put a "real" private key in the same repo, even a private repo. Real private keys live in your credential control system (which may be/involve a VCS repo of course). Also for public projects make sure the code makes a noise when a sample key is used, otherwise people might neglect to generate a new one later for real use. Nov 19, 2015 at 11:55
  • 1
    @DavidSpillett I like the noise generation idea
    – rpax
    Nov 19, 2015 at 20:17

When the private key is nothing more than a test fixture used to test some process requiring a private key and where the private key is not actually used to secure any system.

In some cases it can be appropriate to commit an encrypted key. For example if the repository is public/open source but a Continuous Integration system requires access to that file - Travis CI supports this.

Otherwise you shouldn't commit private keys.

  • 4
    CI is a bit of a hard acronym to google; presumably it doesn't mean Confidential Informant? Could you clarify it for the benefit of the laymen who ended up here through the HNQ sidebar?
    – E.P.
    Nov 18, 2015 at 9:58
  • 14
    CI here is Continuous Integration. It's a server designed to build/test every code change made in a software repository. More info on en.wikipedia.org/wiki/Continuous_integration
    – Vitor
    Nov 18, 2015 at 10:05
  • It would make more sense to generate a random key at CI job start and distribute that key where it is required to be distributed to. This would hinder the same single key to spread to a production system when it is already used in other places. Nov 20, 2015 at 7:56
  • 1
    @SpaceTrucker that isn't practical when the key in the repository is used for API or deployment authentication. In the case of Travis CI everything must be in the public repository, including deployment keys.
    – thexacre
    Nov 23, 2015 at 1:45

I think what you need to ask yourself is:

If the key gets compromised, can I detect it?


How does the revoking process affect other people?

For example: what if the internal source control repo is taken outside of the company perimeter, e.g. via a developers' laptop? What if this laptop is stolen? What if it's a disgruntled employee that makes a copy and keeps it on their personal laptop?

In other words, can the key be used to access a public resource and if so what is the damage?

If your development practices require the sharing of a private key, then it is not a private key by definition. You might want to think about why this is happening and whether you should consider per-user access token (e.g. oAuth, an API key) or other solutions.


Since this answer hasn't been given yet, seems I need to:

Never ever. Really never.

As already pointed out, by definition a private key should be kept secret. But source control is made for sharing and making information available (maybe for a limited audience, but anyway).

The reason why you might want to do that is just because you haven't to the processes you need to have in place. Even though you might intend to use that key for some test system which will be erased after every test run, you probably do not enforce your intentions. Intentions will decay over time and at some point in time the key will be used in production.

  • // , I like the idea here that a "decay" of intentions is something to guard against, or consider in a security model. +1 Oct 2, 2018 at 20:45

When doing cryptography analyses for things like Man in the Middle attacks, it is typical to define the parties by their knowledge. So techniques to allow Alice to talk to Bob and allow Bob to trust that the message came from Alice define Alice to be "someone who knows everything important that Alice knows."

By putting the private key in the repo, you must now do all of your security analyses where the private key is now a private key to "everyone who could download the repository or otherwise get a copy."

If that level of security is sufficient for your private key, then you can put it in the repository. Otherwise, putting it in the repository will invalidate any of your security proofs that depended on the private key's dissemination being narrower than that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .