Pretty much what the image shows. I don't have my credentials stored on my PC, I type them in each time. The machine and credentials are identical between all commits, and I'm the only person allowed to work on that project anyways ...
Set the user name and email in your PC as below, you will not have to type them in each time
git config --global user.email "you#example.com"
git config --global user.name "Your Name"
Didn't think that I needed to save user.email and user.name if git asked each time for the email / pass anyways. Saving them made the issue go away
Related
I just installed Libsecret and pointed it to be where my git credentials get saved:
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret
But I really don't understand how to use it at all.. like at ALL.
It's been a pretty bleak experience to work with this, and actually seems like the only good solution on Linux at this point (its only been 2 years since the last update, rather than like 3+ for other options).
Is there a way to revoke a username/password stored on Libsecret? Like I have 0 clue how to wipe it other than to do --unset credential.helper, which just wipes everything. Can I not narrow it down by the repo/link the password being stored is related to? The Credential Manager on Windows makes this rediculously straightforward via the UI
Sorry to complain and talk about Windows' equivalent, but can anyone shine a light on that?
By all means, not set on using Libsecret if there are better alternatives to what I'm trying to do here. Please, any advance would be so greatly appreciated
It is not clear at all how to do this and the libsecret documentation -- https://developer.gnome.org/libsecret/0.18/ -- is just API/library documentation. Which is great, if you are programming an interface into libsecret. But is not great if you are an end user and want to update or remove an entry.
Also, I found that unsetting the git global config entry credential.helper just reverts git to using un-cached credentials. But when I pointed that setting back to git-credential-libsecret, my old password was still saved.
So, the answer to removing or updating a single entry turns out to be relatively simple. But NOT OBVIOUS.
Install Seahorse (https://wiki.gnome.org/Apps/Seahorse) if it isn't already installed. It will show up in your app menu as "Passwords and Keys"
Run Seahorse
Login (keychain) -> https://#github.com | Network Password
Double click or Right-click on it and edit, copy, or delete
As the other answer mentions, Seahorse is a GUI frontend to the same keyring, but there is also a CLI frontend called secret-tool that can access the same things.
No need to fiddle with what is behind a git credential helper.
Any git credential helper supports an "erase" method, as shown, for instance, in the sources of contrib/credential/libsecret/git-credential-libsecret.c:
/*
* Table with helper operation callbacks, used by generic
* credential helper main function.
*/
static struct credential_operation const credential_helper_ops[] = {
{ "get", keyring_get },
{ "store", keyring_store },
{ "erase", keyring_erase },
CREDENTIAL_OP_END
};
So, to erase a credential entry, you would need to type:
printf "protocol=https\nhost=github.com\nusername=<me>" | \
git-credential-libsecret erase
Replace "github.com" and <me> with the actual remote site and remote account username.
If your credential helper is not libsecret but "manager-core" (using the Microsoft GCM which is cross-platform) , that would be:
printf "protocol=https\nhost=github.com\nusername=<me>" | \
git-credential-manager-core erase
If your credential helper is not libsecret but "xxx" (any other helper, "store", "cache", ...):
printf "protocol=https\nhost=github.com\nusername=<me>" | \
git-credential-xxx erase
Simply type your credential helper command: it will display its commands.
In my case:
git-credential-manager-core
Required command was not provided.
Usage:
git-credential-manager-core [options] [command]
Options:
--version Show version information
-?, -h, --help Show help and usage information
Commands:
get [Git] Return a stored credential
store [Git] Store a credential
erase [Git] Erase a stored credential
configure Configure Git Credential Manager as the Git credential helper
unconfigure Unconfigure Git Credential Manager as the Git credential helper
azure-repos Commands for interacting with the Azure Repos host provider
Just make sure it is in your $PATH (it should be in /usr/bin, if not: /usr/lib/git-core)
Older helpers do not display all "action" commands, and use older synonyms for erase (remove or delete)
To check the erase/remove/delete has worked, display your stored password first ("get"), then "erase", then try and display it again, using again the "get" action:
printf "protocol=https\nhost=github.com\nusername=<me>" | \
git-credential-xxx get
If it prompts for you to enter your username/password, that means you have succeeded in deleting your cached entry.
I have also ran into this issue, and did a little bit of research. From what I can understand, under the hood, libsecret saves credentials to the local user keyring (like gnome-keyring). As the other answer mentions, Seahorse is a GUI frontend to the same keyring, but there is also a CLI frontend called secret-tool that can access the same things.
See https://ece.engr.uvic.ca/~frodo/courses/cpp/documents/github_authentication.pdf and http://manpages.ubuntu.com/manpages/bionic/man1/secret-tool.1.html for more details.
I have the following setup on a linux box in user home directory:
./svn.simple/hash#1
./svn.simple/hash#2
==
hash#1 points to an old server: oldserver.com
hash#2 points to current server. currserver.com
I need to alter the default server location for specific user to a new server. Apologies if terminology is off. How do I go about this? I investigate --relocate, but that seems for a specific working copy. All commands are run at the command line.
A simple checkout from the new repository prompts if config is desired to be saved. If the response is 'yes' a new entry is added to ./svn.simple, saving all required config parameters.
It seems that the code checkout using Jenkinsfile is using http for the remote origin and we do want to use ssh instead.
#!groovy
stage 'build'
node {
checkout scm
sh "cat .git/config"
}
This will output a https origin instead of a ssh one. The job is configured using github-organization-pipeline plugin, so there is no way to control the source from the job configuration in jenkins.
Here is my current approach, which is ugly, I am not going to defend that.
tokens = "${env.JOB_NAME}".tokenize('/')
org = tokens[0]
repo = tokens[1]
branch = tokens[2]
sh "git remote set-url origin git#github.com:${org}/${repo}.git"
This works because github-organization-plugin generate jobs names that look like org/repo/branch.
The organization folder’s configuration screen has an option to use specific checkout credentials, typically an SSH private key. By default it uses the API scan credentials, typically an access token which can be used for HTTPS checkouts (GitHub’s own recommendation).
I am moving from cvsserv1 to cvsserv2. I am running cvs1.11 on current server on RHEL. I am moving to cvsserv2 which is running ubuntu 12. This is my procedure to port cvs:
zip entire repository on cvsserv1
move zip to cvsserv2
extract zip to /home/users on cvsserv2.
setup cvs service on cvsserve2 in pserver mode.
initialize repository on /home/users/cvsroot by using "cvs -d /home/users/cvsroot init"
connect to cvsserv2 from eclipse using anonymous access to do a test checkout.
I am failing on step6 with the error message "no such repository". What am I doing wrong?
UPDATE
I tried to change the above method, by adopting this http://mazanatti.info/archives/67/ and I was partially successful.
At step 3 (as in that link), after initializing repo on cvsserv2, I copied my repository to /var/lib/cvsd/project1, overwriting CVSROOT folder. Now, after finishing all steps, I was able to connect successfully. However, when I try to check out, I don't see any branches. When I tried to Refresh Tags, I receive the following error:
What is going wrong?
Ok. I figured this one out. For those who might encounter this issue again, here's how I managed to identify and fix it:
Eclipse's cvs client sucks - it doesn't give you much information. (I could be wrong, may be it writes some debug info to eclipse log file - still, I think that error message should have been more descriptive). Anyway, I obtained TortoiseCVS and attempted a checkout and it failed with an error message on the lines of -"failed to obtain dir lock in repository `/home/cvsroot/foo'. This is not the exact message, but it was something like that.
So, all I had to do, was go into my cvs dump from cvsserv1, look for references to that directory (which is a valid path on cvsserv1 but not cvsserv2). I found a reference to it in config file under CVSROOT folder. It was assigned to a property called LockDir. This property was referring to a /home/cvsroot/foo on the older server as a lock directory. All I had to do was comment out this property and restart cvsd. Everything started working just fine after this!
I'm using git and Codebase for a project.
I just did a test and I'm able to commit to the git repository with a different email address and name set which causes it to tag the commit as being by a different user. I pushed this to the repository and it showed up as that user having committed even though it was me.
Is there a way to prevent users from committing or pushing with someone else's user details (effectively so they can't "forge" commits as being from a different user)?
Edit:
I assume this authentication would need to happen at the stage of pushing commits to the server since in the local working copy it's simply a repository which the user has full access to, to do whatever they want with. Is this therefore something I should ask Codebase about maybe?
Edit 2:
Git config as requested:
(repo/.git/config)
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git#codebasehq.com:<redacted company name>/<redacted project name>/test.git
[branch "master"]
remote = origin
merge = refs/heads/master
Ooops: While this is a valid technique, it assumes you have effectively full control over the server. If you're using a hosted solution all bets are off.
You can validate the author name and email in the repository's update hook. You can get both values like this:
#!/bin/sh
set -- refname sha1_old sha1_new
author_name=$(git log --pretty=format:%an $sha1_new)
author_email=$(git log --pretty=format:%ae $sha1_new)
The trick, of course, is figuring out whether or not these are valid. Here's one trick:
You can use the command="" option in your ssh configuration to make a wrapper around git-receive-pack that maps ssh keys to author information. For example, something like this:
#!/bin/sh
GV_AUTHOR_NAME="$1"
GV_AUTHOR_EMAIL="$2"
export GV_AUTHOR_EMAIL GV_AUTHOR_NAME
eval exec $SSH_ORIGINAL_COMMAND
And you would use an authorized_keys line something like this:
command="~/bin/gitvalidator 'Lars Kellogg-Stedman' 'lars#seas.harvard.edu'" ssh-rsa ...
The result of all this is that your update script would have the environment variables GV_AUTHOR_NAME and GV_AUTHOR_EMAIL available, and could check these against the commit and exit with an error if they didn't match.
Sorry my post got deleted before I submitted my latest update:
You can commit as someone else when you have their credentials.
Just to clarify, the scenario you are asking about is as follows:
Users Foo and Bar can commit to the repo. You want to prevent user Foo from committing to the repo as user Bar.
In this case, user Bar would have to protect their private SSH key, just like they would protect a password. As that is used to authenticate your commit.