I used a personal access token (PAT) to clone a private github repo to a shared hosting service and the pull was successful.
But looking through the setup, I saw the PAT in plan text as part of the clone url stored to the settings.
Is there any risk to doing this?
Related
I'm building an OAuth app to work with Github. I need to know, via token scopes, whether an authenticated user has access to a repo (public or private) so that I can restrict access accordingly in my app.
I explicitly do not want access to repo code from my app because a) I want users and companies to have confidence to use it with private repos and b) the app doesn't need to know, so I'd like to keep it least-privilege.
I'm struggling to find an OAuth scope that will allow the app to query whether a user has access to a specific repo without also needing to ask my users to grant the app permission to access their code.
The nearest I've found is repo:status. However that requires me to guess a branch name, which is usually main or master, but there's no guarantee.
Is there a better way?
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)
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 use TFS for source control and when I use git command line from new machine, I need to save credentials manager manually. Otherwise, I receive "Authentication Failed"
Is there alternative than pre-defining credentials in credential manager?
Current case from CentOS 7:
The Git Credential Manager which is just used to provide security Git credential storage. It's ok to pre-defining credentials in credential manager.
However for macOS and Linux, instead of using credential manager，
We recommend using SSH keys to authenticate to Azure DevOps,
not a credential manager.
SSH public key authentication works with a pair of generated encryption keys. The public key is shared and used to encrypt messages. The private key is kept safe and secure on your system and is used to read messages encrypted with the public key.
More details please take a look at our official tutorial--Use SSH key authentication
Update
Besides, you could also use PAT token to access git repositories.
To authenticate with the PAT while using Git, you can use it as the password. The username can be anything, since your identity is identified with the PAT. For example:
Username: anything
Password:
Or:
git clone https://anything:<PAT>#dev.azure.com/yourOrgName/yourProjectName/_git/yourRepoName
More details please take a look at this link.
As for how to use PAT, you could refer this -- Authenticate access with personal access tokens
Note: This is only available with TFS2017 version and above. Besides, recommend you keep IIS Basic Authentication turned off when using Azure DevOps Server. When IIS Basic Authentication is enabled on your windows machine, it prevents you from using personal access tokens (PATs) as an authentication mechanism.
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.