in .gitconfig, you say:
name = Me Myself
email = email@example.com
signingkey = D34DB44F
path = ~/.gitconfig_work
name = Me Myself
email = firstname.lastname@example.org
signingkey = D34DC0D4
sshCommand = ssh -i ~/.ssh/work_ed25519
IANAL but I would strongly suggest everyone to only use their employer issued computer to do work related work and move all their personal, hobby projects into their own personal computer, unless you don't care your employer owning the copyright of your personal hobby projects.
You want to work on your personal project before going home, bring your laptop to work with you, go to a coffee shop (off-property) and work there.
That said, when I’m doing PRs for open source, it gets a bit awkward to use my work ID. If I have permission to contribute to dependencies on work time (which has definitely not always been the case), then something like this could be useful.
Contributing to OSS isn’t just about fixing a problem for my company. I could do that internally. It’s about fixing a problem for everybody, including future me.
This means that there is no default email set, and that git will error if you try and commit, because there is no email set.
I do a lighter weight version of this article by just doing the above. Then when I do the first commit in a repo, I get that error and I do the following command:
git config --local user.email email@example.com
(or the my personal email as appropriate). Then I have per repo config that persists unless I blow the repo away completely.
- requiring a user to be set
- not having one filled in the global settings
The upside is that even if the folder is moved, the user config still applies. The downside is that you have to set it per repository (but only once).
There are pros and cons, but I don't see one being any better or worse than the other in absolute terms.
If some current (or future) coworker has a question about the code, I don't want them to necessarily e-mail me on my home account. I might not be checking it during work hours, or I might not even be with the company anymore.
Similarly, if someone actually wants to contact my e-mail for a hobby-project, I don't want them to send it to my work-account, which over time I might no longer have access to anyway.
Also, some people prefer to not disclose their employer on GitHub hobby projects (or at all on the web). Simiarly, your employer doesn't necessarily need to know about every hobby project you start (as long as you're not violating work-contract clauses).
The notifications don't go to the email in the git commit.
Since I usually have to work on several repositories, I usually do what OP presented. I have one directory per client with each their own configuration and their repositories.
Now for every client i set up a separate VMWare Workstation virtual machine with all the relevant git config files, ssh keys, software and build dependencies etc.
That way every client is compartmentalized and there is limited chance of data or code leaking between clients. And i can always mid-session put the VM on pause, switch to another client and then resume right where i left, with all the editor windows open and services running.
I call it the container approach to workspaces.
without modifying the root `~/.gitconfig` file.
Therefore, wouldn't it be more efficient to use elliptic curve cryptography, i.e. ED25519, if you want that extra bit of security?
It's included in GnuPG since version 2.1.0 released in November 2014 - at least in an experimental state.
What other PGP implementations are relevant to interoperate with in 2020? Who still uses PGP, but doesn't use GPG? And why?
I just tried again and it did not work
It's already on AUR:
$ git identity -h
usage: git identity [-d | --define] <identity> <name> <email> [<ssh-file>] [<gpgkeyid>]
or: git identity [-p | --print] [<identity>]
or: git identity [-s | --get-settings]
or: git identity [-r | --remove] <identity>
or: git identity [-l | --list]
or: git identity [-R | --list-raw]
or: git identity [--define-gpg] <gpgkeyid>
or: git identity [--define-ssh] <ssh-file> [<ssh-verbosity>]
or: git identity [-u | --update]
or: git identity [-c | --get-shell-command] [<identity>] [<command>]
or: git identity <identity>
So you can define identities such as `work`, `personal`, and then after cloning/init, run `git identity personal` to setup GPG or SSH keys, name and email.
I've been using variations on this technique for a few years now. It's kind of a pain to remember which URL to use to clone a repo, but is great for keeping that veneer of separation between work and personal projects.
What sorts of separation are beneficial for you? I'm wondering if I should switch, but I don't fully understand.
More pragmatically, I've been burned in the past by using personal accounts (not GitHub specifically) for work things. For example, I used a personal commuter card for a former job's benefits program. When I left, they deactivated my card. Awkward! Not the same kind of risk with GH, to be sure, but after that I do prefer to keep my digital selves as compartmentalized as possible.
* Git identities (I just need to clone from the right user)
* access restriction (building one compromised project won't compromise everything else)
* no need to manage virtualenvs (or the equivalent for non-python environments), just install everything in ~/.local/
I always switch between projects to get some files (Like a CI config I already wrote for another project) or look how I have done something in another code base. Also all my editor configs, bookmarks, browser logins for Github are all there. If I'd have to switch between users for each project that sounds really cumbersome.
> Also all my editor configs
My editor and shell configs are in /etc. Again, it may not work for everyone, as you may have to share the computer.
> bookmarks, browser logins for Github are all there. If I'd have to switch between users for each project that sounds really cumbersome.
Sorry, I was unclear. I don't logout/login every time I change project. I have a main user, and use sudo to run commands as other users (it even works with graphical apps, provided you whitelist them)
When you want to enable some limited sharing, it helps to create a new group for all your user accounts.
For files and directories that you want to share, just set the group to your new user group, and use the OS group permissions to manage read/write/execute.
These are pretty creative approaches using the built-in access control Unix has. I like it.
Sure, there are solutions to each of those problems, but in the end I found it required more discipline and effort than I was willing to put in, for what basically amounts to a small amount of additional security.
I'd be happy to hear how you deal with those issues, however!
I split the Git Identities based on which directory I'm working on.
Also IMO the proper way to use GPG is to generate the keys on an offline machine and then move the private key to a physical token.
Until I got to 'define an alias ...' I thought it was about a user-switching feature of git that I was unaware of.
"This is a procedure for leveraging git aliases to set an identity at the project level..."
Clang-format has this “delightful” feature, which isn’t actually all that horrible except I cannot find a way to pass it a configuration file via the command line. If I’m editing files in /tmp (or using an editor that relies on this directory) I have to do a nasty hack of copying ~/.clang-format to the current directory to make it work: https://github.com/saagarjha/dotfiles/blob/master/_nano-clan.... Basically, this is a long-winded way of saying that this kind of setting can often work but it’s really not great in certain situations.
All SSH/GPG private keys will be in the same storage anyway, and it doesn't provide any security advantage in case a key is compromised. They are already computationally impossible to brute Force too.
Isn't the point of GPG keys is to have an established trust? How does using multiple keys help with it?
My personal computer is owned by me. Nothing company owned touches it.
This makes domain separation easier.
It’s an easy way to prevent accidentally your FOSS contributions or projects with your $WORK email address.