I'd like to use travis-ci for one of my projects.
The project is an API wrapper, so many of the tests rely on the use of secret API keys. To test locally, I just store them as environment variables. What's a safe way to use those keys on Travis?
Travis has a feature to encrypt environment variables ("Encrypting environment variables"). This can be used to protect your secret API keys. I've successfully used this for my Heroku API key.
All you have to do is install the travis gem, encrypt the string you want and add the encrypted string in your .travis.yml. The encryption is only valid for one repository. The travis command gets your public key for your repo and can then decrypt the string during the build.
gem install --user travis
travis encrypt MY_SECRET_ENV=super_secret -r my_username/my_repo
This gives you the following output:
Please add the following to your .travis.yml file:
secure: "OrEeqU0z6GJdC6Sx/XI7AMiQ8NM9GwPpZkVDq6cBHcD6OlSppkSwm6JvopTR\newLDTdtbk/dxKurUzwTeRbplIEe9DiyVDCzEiJGfgfq7woh+GRo+q6+UIWLE\n3nowpI9AzXt7iBhoKhV9lJ1MROrnn4DnlKxAEUlHTDi4Wk8Ei/g="
according to this in travis ci documentation it's said that :
If you have both the Heroku and Travis CI command line clients installed, you can get your key, encrypt it and add it to your .travis.yml by running the following command from your project directory:
travis encrypt $(heroku auth:token) --add deploy.api_key
refer to the following tutorial to install heroku client according to your OS
You can also define secret variables in repository settings:
Variables defined in repository settings are the same for all builds, and when you restart an old build, it uses the latest values. These variables are not automatically available to forks.
Define variables in the Repository Settings that:
differ per repository.
contain sensitive data, such as third-party credentials.
To define variables in Repository Settings, make sure you’re logged in, navigate to the repository in question, choose “Settings” from the cog menu, and click on “Add new variable” in the “Environment Variables” section.
Use a different set of API keys and do it the same way. Your travis box gets setup for your build run and then completely torn down again after your build has finished. You have root access to your box during the build, so you can do whatever you want with it.
Related
The Fontawesome Pro instructions describe placing a secret key in a .npmrc file but it is unclear how this file should be managed. Specifically, should this file be ignored by Git?
The Fontawesome Pro instructions are correct as an example of the general approach to managing sensitive information in a .nmprc file :
all sensitive values there should be replaced by environment variables, and
those variables should then be defined as managed secrets in whatever environment the repo will be pushed to.
My answer would say it's best to ignore it and not push to repo. as if you have multiple Engineers contributing changes to a generated package for push to the registry each developer will have to have their own .npmrc file and it' unlikely that you'd ever want that pushed to the repo as each attempt would overwrite/conflict.
I could imagine a scenario where you'd like to automate by using a single credential for all devs and thus one global .npmrc file but that is an obvious security faux pas in my view.
I want to some changes in jitsi and install from my own repository.
Actually after some changes, i want to install it in many servers with each servers have unique domain.
You can change the front-end with two options :
Option 1 (recommended)
Follow the manual installation documentation and replace «jitsi-meet» component which is in /srv/jitsi-meet
This directory must contain your version of jitsi-meet (you must build the project, follow this step but clone your repository instead official repository)
Option 2 (not recommended)
Follow the quick installation then replace the /usr/share/jitsi-meet
This is the same step but in another directory
Be careful, this option is faster but each update on jisti-meet package (apt) can break your installation and override the /usr/share/jitsi-meet directory
I have a project where we use font awesome 5 library. I followed the instructions that are written here and added an .npmrc file with my auth token.
Is this a safe behaviour to put this in a repo? I want the devs to have access to it, but if the repo goes public we might be exposing the token.
What is the best practice in situation like this?
UPDATE 2021-05-02
This answer remains questionable - see the comments below. I no longer have access to a private ($paid) npm account anymore, so I can no longer test to answer questions.
Perhaps try #konyak's answer.
It is definitely NOT a safe behavior to put the token in any git checked file, including .npmrc.
Below are the steps your team can take to safely leverage your npm token.
There are two different environments to consider:
each developer's local dev machine
the app's deployment platform
local dev
Following the Global Set Up instructions you linked to in your question, is not the solution.
Create the .npmrc file similar to the "Per project" instructions, but substitute your real token with a variable name, prefixed by $. ie:
#fontawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=$TOKEN
npm will detect an environment variables file named .env. So, in a .gitignored .env file, add your secret key value pair, ie:
TOKEN=ABC123
You can also prefix the variable name with "NPM_CONFIG_", according to the npm-config docs, ie:
NPM_CONFIG_TOKEN=ABC123
Now, when the dev runs npm i, font-awesome dependencies will load from the private repo.
NOTE: Don't follow the current npm-config docs about the environment variables syntax! See this stack overflow answer, ie:
👎 BAD npm-config ENVIRONMENT VAR SYNTAX 👎
${TOKEN}
👍 GOOD npm-config ENVIRONMENT VAR SYNTAX 👍
$TOKEN
app deployment platform
Do all the steps from the local dev section above, PLUS:
create an environment variable on the platform with the same name as in the .npmrc file.
If your app host is Netlify, see their Build Environment Variables docs.
https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow
Export your secret token into your session, e.g., export NPM_TOKEN="00000000-0000-0000-0000-000000000000"
Inside your ~/.npmrc, add //registry.npmjs.org/:_authToken=${NPM_TOKEN}
I put the relevant config line, with the token in plaintext, in a .npmrc file in my home directory. You can then use filesystem / OS permissions to protect it, avoid accidentally checking it in to source control, and NPM will read it automatically with no further action on your part.
In the project directory, we have .npmrc with a scoped registry declaration only (#fontawesome:registry=https://npm.fontawesome.com/), and a separate ci.npmrc which has that plus the variable-substitution authToken assignment:
#fontawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=$FONTAWESOME_NPM_TOKEN
The CI build job just has to replace .npmrc with ci.npmrc before doing anything with npm, and set a secret environment variable with an auth token assigned to the appropriate service account.
I have a CI pipeline that is likely doing something semi-perverted. Let's not debate that part.
As part of the CI, I will generate an artifact (README.md) which I would like to commit and push back to the same repository. Simply using git push origin ... doesn't work due to authentication error.
Am I constrained to using something like a secret variable and a token, and adding another remote so that it can push?
There are ways to add a ssh token to your build runtime which is able to commit or even do a push to origin.
I think even recently GitLab added a new functionality that for each build a unique token is generated which can be used for same sake.
However in general I dont think you can commit anything on the same git base that build is running on, as the check out is in a detached head mode. This means you will not be able to add to history, specially in a remote.
Next problem to consider is what this means if you were able to commit back for the build system, which can potentially trigger another build and a cycle will be triggered.
So probably either use the artifact system for it or do add the ssh token and clone/checkout/commit/push in a separate directory during the build. Anyway this doc explains how to add the token: https://docs.gitlab.com/ee/ci/ssh_keys/README.html
Gitlab seems to change .git folder after fetching project for CI job. I'm not sure it changes only remote section. So I found only solution is to add gitlab-runner user with sshkeys to gitlab. And in my job make git clone in separate folder, make changes, then commit and push it.
http://maven.apache.org/settings.html As per documentation the user specific settings can be either copied to the .m2 folder or under the maven installation. If a developer changes a machine or gets a new user id, such properties have to be copied manually to these newer machines.
Would it be possible to store user specific setting information in the repository itself (say SVN) and somehow have the mvn scripts load it on startup.
If the content of the settings.xml is not that user specific (e.g. for mirrors), you could store the whole Maven install in SVN with a customized conf/settings.xml and have the developers grab it from SVN to "install" it on a new machine as described in this previous answer.
If the content of the settings.xml is really user specific (e.g. it contains secret things like passwords), then it must be located in ~/.m2 and you will have to somehow make it available at the new location. If a developer logs on another machine, you could use "Roaming user profile". If a developer gets another id, then you'll really have to duplicate it. The technical solution may depend on the level of confidentiality required.
And if you have several developers sharing a userid but still need different settings.xml, then you'll have to pass it to Maven using the -s option. One could imagine storing these custom settings.xml in the project in that case (assuming it doesn't contain sensitive information). For example:
mvn -s settings-user1.xml <goal>
Nope, the whole point of having user settings is to store them outside the maven projects. There's nothing stopping you from creating your own svn repository and storing your configuration files there, though. You could write some shell scripts to bootstrap a new workstation from that repository, but it really depends how often you do this to make it worthwhile.
I would suggest that you setup your own repository such as Archiva, Nexus or Artifactory. Which will get your dependencies/plugins , then you can use mirror to specify explicitly just one repository to be used(the one you setup on your network). So whenever developer changes machine or dependencies are needed for multiple developers the internal mirror can be used as repo, your dependencies/plugins will download in no time to your local repository/ies