I have an npm package that depends on a repo in a private github server in its package.json:
"my-package": "git+https://private.github.example.com/my-org/my-package.git"
The github server is secured with personal access tokens (which are used as passwords during authentication). In local builds, users can store their .gitcredentials for https://private.github.example.com and git will automatically use them to access the github repository during the npm build.
I also have a technical user in a Jenkins which in general has access to the github server via a personal access token. However Jenkins uses those credentials only to check out from the github server and the credentials for that appear only to be bound to the github api url, not to git checkouts from any repo on that server that occur during the Jenkins Job.
I have seen https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs, which describes how to define credentials and inject them into build scripts as environment vars.
However, I do not think it is a good idea to introduce environment variables in a package.json, if that is possible at all.
How can I make credentials defined by the credentials plugin accessible for git during npm builds?
Use the credentials from the secret store to write a .gitcredentials file on the agent which you clean up again in a post step.
Related
The project's local development environment makes it mandatory to have a .npmrc file with the following content:
registry=https://registry.npmjs.org/
#my-organization:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=your-GitHub-token-should-be-here-and-I-will-not-share-my-for-security-reasons
Hence, any client properly authenticated into the GitHub Packages
Registry can install our private NPM packages hosted for free on GitHub Registry by running:
npm ci #my-organization/our-package
Ok, it works on my local development environment.
Now, I am building a Continuous Integration process with GitHub Actions which is a different but similar challenge. I have this on my .yaml file:
- name: Create .npmrc for token authentication
uses: healthplace/npmrc-registry-login-action#v1.0
with:
scope: '#my-organization'
registry: 'https://npm.pkg.github.com'
# Every user has a GitHub Personal Access Token (PAT) to
# access NPM private repos. The build of GitHub Actions is
# symmetrical to what every developer on the project has to
# face to build the application on their local development
# environment. Hence, GitHub Actions also needs a Token! But,
# it is NOT SAFE to insert the text of a real token on this
# yml file. Thus, the institutional workaround is to insert
# the `{{secret}}` below which is aligned/set in the project
# settings on GitHub!
auth-token: ${{secrets.my_repo_secret_key_which_is_not_being_shared}}
On GitHub settings->secrets->actions->"add secret":
On the secret value, I added my Personal Access Token. The same I have on my .npmrc file. It works for npm i.
Nobody can see the secret value on GitHub. Not even me, the person who added it and the admin. The value can only be updated or removed.
This feels "good enough" for security, but still, it does not feel like best practice. I believe it would be better to have a "new working" token detached from any personal token being used by a developer who is working on the project.
Is it possible to generate and insert a value of GitHub Personal Access Token which is unrelated to the Personal Access Token of people working on the project?
If yes, how to do it?
you should use GITHUB_TOKEN insted of PAT(personal access token)
We are have Nodejs API written in Typescript. We are using NPM Packages from Gitlab private registries. We have the Registry URL and Token. We need to store that in the Project in .npmrc file.
But the question is how do we store the auth token securely so that the token does not get pushed to the git repo. We know that we can set the npmrc at the user level. But if we need to use the npmrc at the project level, what are the various options available to store the auth token
So far we have always checked out our Git repositories locally via SSH and on the webserver via HTTPS.
Since the GitLab update from August 3, 2021 to version "14.1.2-ee", we noticed that GIT no longer asks for the username and password of the GitLab user during "git push". The only way to push over HTTPS at this moment is to create and add a private token.
Is this a bug in the current version of GitLab or a feature? Is there a setting somewhere to define authentication via HTTPS like before the update?
PAT (Personal Access Token) are recommended with Git to authenticate over HTTP, and mandatory if 2FA has been activated.
That being said, It depends on
what was your previous version of GitLab before this upgrade
which authentication backend your on premise 14.1.2 GitLab server is using.
If it is LDAP, then this issue seems to be similar to gitlab-org/gitlab issue 337875:
LDAP integration generates masstiv amount of invalid logins
I have updated to Version 14.1.2 yesterday since then the are huge amounts of invalid logins via LDAP on the configured AD Controller.
This locks affected ad accounts.
We have registered over 5000 failed log in events in the last 12h.
So check the server logs, and see if the affected accounts (that no longer manage to authenticate) are locked. (you can unlock one from command line, for testing).
The OP eckonator clarifies in the comments:
The error was not due to the update, but was activated CAPTCHA at the same time.
After disabling the CAPTCHA function, everything does again as usual.
I am working on a commercial desktop app built using Electron, and our codebase is on a GitHub private repo. We are trying to enable devs to publish the binaries to GitHub releases, and using electron-updater to auto update.
From googling around and experimenting, I got this to work but I needed to expose a GH token that has read:packages, repo, write:packages permissions. Due to the way electron-builder and electron-updater works, this token is exposed in plaintext in a .yml file once installed.
My question is what are the security repercussions for exposing this token? The worst I can think of is having a malicious user push false updates which doesn't seem that bad as they can only push draft releases from what I understand.
A token with repo scope has full read and write access to your repository and can be used to fetch from and push to your repository with the full privileges of the user for whom it's issued. So if you give that token to others, they can operate on the repository as you. Such a token also grants numerous other API permissions as well.
It would be better in general to build your releases in a CI system and create and upload the releases via a token that's stored safely in your CI system's secret store. You definitely do not want to allow anyone other than you or a trusted system to access your GitHub tokens.
I'm trying to push to a GitLab repository. I'm already logged in/authenticated and I'm able to fetch all my GitLab projects.
The repository was imported to GitLab from GitHub.
I was also able to push normally with a different repository, but with this one I get a "HTTPS Credentials" dialog asking for a username and password. Supplying my GitLab username and a personal access token does not work.
I'm running GitAhead 2.5.11 on Windows 7.
The remote was still set to the GitHub URL instead of the GitLab URL, so I was actually trying to push to GitHub with my GitLab credentials.
Setting the remote to the correct GitLab URL did the trick.