While this works great if you are using your personal computer to do work. But if you use your employer issued computer to do personal hobby project, then please be very careful. In 90%+ of the cases your contract with your employer have the claus saying (please review your contract to clarify) that they own copyright of all your work while you are under the contract even if it's outside of working hours or on the weekend, with a few exceptions, and using employer equipment (employer issued computer) nullify one of the biggest exceptions.
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.
Advice I’ve gotten: not on company property, or with company resources (equipment, networking, technology).
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.
My personal take on open source contribution: If this is related to your work, you are getting paid for working on the contribution by your employer, then your employer should get the credit, thus you should use your work email/id. Otherwise, treat it as your personal hobby project and don't use employer resource to work on it.
I think that depends on whether you intend to walk away from those changes once you take a new job.
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.
If all your ifs are met, then you are not getting paid for it, which is a criteria from my comment :) Also this whole discussion is about suggest against people from using employer equipment to do personal projects :)
Exactly, have a similar setup, I would recommend against using the approach suggested in the post if you want to be 100% sure of always using the right account.
This setup does ensure this. These are the two relevant commands:
git config --global --unset user.email (etc.)
git config --global user.useConfigOnly true
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 me@myworkemail.com
(or the my personal email as appropriate). Then I have per repo config that persists unless I blow the repo away completely.
Well, the e-mail part is pretty straightforward, since many people will have a personal e-mail and a separate e-mail managed by their workplace IT.
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.
> Similarly, if someone actually wants to contact my e-mail for a hobby-project
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).
This also applies to e.g CI systems, that are able to send build success/fails emails to the emails in the commits instead of the default GitHub/GitLab email.
I have to do this too because I work for different client and every client have their own gitlab which they only give access to account with their corporate email.
So i have to commit under myname@client1.com for client 1, my.name@client2.fr for client 2 and so on.
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.
I used to have the client per directory setup too. But then took it one step further.
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.
In many workplaces, you're required to use the company provided email address with git. And the name some people use at work isn't the same as what they use in their personal projects. (For ex, I use my full name at work but a shorter one for personal stuff)
Can be a lot of reasons. Some people (like me) like to keep their personal identity and work identity separated. Also some company policies forces you to use a different SSH key/GPG key for work-related stuff.
Another (possibly simpler) approach is to set project specific settings in the `.git/config` file, right in the project directory. As for the OP's example, in:
Thanks for the great post!
However, I discourage the usage of RSA with 4096 bit as it does not offer any substantial security over RSA with 2048 bit. The mean idea behind the "No-4096-bit" is nicely explained by GnuPG people themselves, https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40....
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.
I would have agreed then, in 2014, maybe, one or two years later, completely with GnuPG's statement on ECC support.
I cannot state whether any of the other open-source and free projects on encryption have advanced to ECC, however, I would expect most of them have so far.
Independent of the ECC support in other programs than GnuPG, I think to advance to the newest, but stable and well-tested, security measures (ECC), would be a good idea and will pay of in the future?
I expect, of course, to advance to the newest stable versions will, at some point, introduce regressions with older versions (or platforms).
But I think that is a price we should be willing to pay.
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.
I do what the GP describes as well. It’s not that bad.
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.
Everything I do is open source, so all my code is readable by all users. If you don't, see cvwright's answer.
> 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)
I used to do this, but I never found a good solution to scratch all the itches that come up when you go down that road. For instance you want to keep a variety of config in sync between all accounts -- except for the bits you don't. You want to be able to share some files between the accounts, but not others due to security concerns. You want to be able to access things like your password manager or mailbox, which again you may not want to share between accounts for security reasons.
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'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.
You can extend this trick further by specifying the User in your SSH config to make for even shorter URLs.
Host gh-me
Hostname github.com
User git
IdentityFile ~/.ssh/id_rsa
Host gh-work
Hostname github.com
User git
IdentityFile ~/.ssh/id_rsa_work
Then all you need is a `git clone gh-me:org/repo` or `git clone gh-work:work/repo`. I've been using this for sometime and it's not too hard to remember. Although when I don't it's easy enough to fix the origin url by editing `.git/config`.
Yeah I also sometimes forget to use the proper URL, I wish it were a little easier to setup and use the concept of separating work/personal or public/private repositories.
Depending on the employer and the side-project, using the same account for both could _in theory_ bolster a (ridiculous, absurd) ownership claim over your work, for example. Stranger things have happened.
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.
Here is something I did. Ignore the other details in the article, and focus on the "SSH Split Personality Disorder" part. This article was written for a 200-ish member team of a Startup and so most of won't be relevant to anyone outside the Company.
What I use to switch git identities is direnv (https://direnv.net/) which automatically loads specific config based on the dir that you are in. You can use it to switch AWS profiles, proxy settings, npm settings, maven settings, git configuration and so on.
Why are they generating new GPG keypairs for every identity? This is an honest question. I've been curious if there are any benefits to having multiple keypairs over just one keypair and multiple uids.
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.
To get around this problem I just use a simple command-line utility that I wrote called gitswitch that I call whenever I jump to a new project. My name never changes but my email does, so that's all the utility changes. I suppose it would be neat to build in profiles, but I jump between 2-3 PCs regularly and would probably forget to update my profiles.
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.
All this wouldn't be necessary if git supported traversing through parent directories for a configuration lookup to have "per directory structure" configurations.
Any idea, why this relatively simple and inexpensive approach isn't implemented? Simply because no one bothered to do it so far?
> All this wouldn't be necessary if git supported traversing through parent directories for a configuration lookup to have "per directory structure" configurations.
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?
The Japanese say you have three faces. The first face, you show to the world. The second face, you show to your close friends, and your family. The third face, you never show anyone. It is the truest reflection of who you are.
My work laptop is owned by my company. All company work goes on there. (And since it's a company-owned resource anything made using it is something they could claim rights to.)
My personal computer is owned by me. Nothing company owned touches it.
Even with keys tied to machines and not just people, it’s convenient to have distinct meta data (name or email) associated with projects or directories.
It’s an easy way to prevent accidentally your FOSS contributions or projects with your $WORK email address.
The keys have a User ID packet with a userId field that contains a name and email address, which is an identity. I prefer to keep my identities separate from one another. For me it's not necessarily about security, it's more so about compartmentalization.
Not sure why GPG got in the picture.
As other connectors have pointed out, changing Git identities is a trivial operation that can be done in so many different ways.
Generate a new key and update the global git config with the new public key hash. Then add the new public key to Github/Gitlab to support verification of signed commits with new key.
in .gitconfig, you say:
Then in ~/.gitconfig_work: I like this way better, because I don't need to remember to specify per-project config, as long I put them in the right directory :-)