0

I am working on an Android project. I have a few files under version control that git-crypt encrypt them for me. The content of some of them is important to be decrypted before running the build process.

I have no problem at all with building the project on my laptop. The problem is on the the CI side. When I push the code to the Origin, the pipeline (I am using Azure) triggers a pipeline and after a few seconds, the build fails. That's because the build system is looking for the information I have in keys.properties file and it's encrypted.

Based on my understanding, git-crypt uses public/private keys in order to encrypt/decrypt files. The public key is already under the version control, root/.git-crypt/keys/default/0/7F64F6C566153F29E4D9D44070C2A1QW029CE338.gpg. Therefore, I think I need to move the private key somewhere. Am I right? If I am right then my question is where to put it? Is it still under the root of the computer (macOS Image/VM on CI) or I can put it under the root of the project?

Note: Azure lets me upload secure files under its Libraries and then I am able to reference it from the azure-piplines.yaml file.

Hesam
  • 52,260
  • 74
  • 224
  • 365

1 Answers1

0

where to put it?

Based on my understanding on git-crypt and azure devops, compare with storing the private key in root of PC, I'd suggest you put it under the root of project.

Because if you store it at root of PC, it would has no trouble while you run the pipeline with Private agent. BUT, what the issue is if someone using Hosted agent but the private key is in local. As you know, Hosted agent is the one which located at cloud, and it is loaded very dynamically. So, it's hard to get the private key from local computer.

In one word, keeping it in the repository remove the hassle of storing it somewhere else and using it between developers.

However, above is just the suggest choice between store at root of PC and store at root of project.

Although, it would much convenient if put the private key into the root of project.

But on personal suggestion and info security, I strongly stand by the method that you mentioned at last: Store the private key in Library, and reference it during the build/release. Azure DevOps library store the secrets in a safe way and use them as and when needed without making it visible to anyone.

Mengdi Liang
  • 17,577
  • 2
  • 28
  • 35
  • Thank you @Merlin for your answer. I will come back to this issue soon and approve your answer. – Hesam Feb 03 '20 at 16:56