2

Mark Murphy makes a good case on his blog what kind of information should be kept out of public repositories. Key material, e.g. OAuth keys or API keys to various services, are a prime example for this.

The application in question would be a mobile android app, so someone decompiling it to get at the secret keys is not in scope of this question.

How would a build job on a public CI instance, for example cloudbees, be configured so the secret is not leaked in the build log or the compile directory? My main intent is demonstrating the architecture and build process of an app with OAuth-based authentication without disseminating my private keys all over the internet. Therefore, the need for a public code repository and a publicly visible build server.

Currently, I am using maven filtering and placeholders in my java code to create static constant classes but those classes are always visible in the target directory. A post-build cleanup of target still leaves a short time slot in which the resulting java file is visible to the world.

Hakan
  • 537
  • 4
  • 13

2 Answers2

0

From your description it sounds like you are talking about a key which should not be in the SCM repository, yet needs to be included in the final application. Presumably the application binary is not freely downloadable as such, or else anyway could open it up and get your key, but this is fine if the build result is simply being deployed to some server.

In such a case there is not necessarily any problem in having the key present in the target directory (i.e. Jenkins workspace), or indeed in build artifacts (e.g. lastSuccessfulBuild/artifact/target/myapp.war), so long as these things are not publicly readable. In the case of a CloudBees DEV@cloud Jenkins instance, you can use role-based access control to allow the public to see the changelog for your project, and perhaps the build logs (after vetting them to make sure secrets are not printed), but deny access to the workspace and artifacts.

(As far as artifact read permission is concerned, it seems that this is granted to anyone with overall read permission unless Jenkins is run with -Dhudson.security.ArtifactsPermission=true which is not an option for hosted Jenkins. Probably a plugin needs to be created which enables this permission, and probably also “workspace wipe-out” permission, akin to the existing Extended Read Permission plugin. Workspace browse permission is a standard part of Jenkins at least, which would suffice if you are not archiving artifacts but deploying directly at the end of a successful build.)

Jesse Glick
  • 24,539
  • 10
  • 90
  • 112
  • Obtaining the keys by decompiling is orthogonal to this question. Even so, the hint of the Extended Read Permission Plugin led me to the [Mask Passwords Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Mask+Passwords+Plugin) which might be used in hiding the injection of keys. – Hakan Jan 29 '13 at 17:12
0

This is a problem even if you'r not using public build servers.

Think of it: If the key is in the final package, everyone can see it. No matter at what step of the build it got there, it's public. Anyone can download the package (JAR, APK, etc), explode it, decompile the .class and see the key. It's easy to do it all.

In CloudBees you can put this kind of information in an enviroment variable. See this link: http://developer.cloudbees.com/bin/view/RUN/Configuration+Parameters . I don't know much about CloudBees, but I think all public servers have this kind of option, putting sensitive information somewhere that is not public.

Alex Oliveira
  • 893
  • 1
  • 9
  • 27
  • 1
    Right, if you want the application binary to omit the key but have it be accessible at runtime, using an external configuration parameter is the best choice. – Jesse Glick Jan 29 '13 at 15:40