Feature Request for GitHub - commit *as* an organisation
github · 12 comments · 450 words · read ~354 times.
There was a "situation" at work. We were publishing a high-profile project (take a wild guess) on GitHub. We had received abuse and were worried that someone might target the programmers who worked on the project. Obviously, we take cyber-security seriously, but how do we deal with personal-security?
Here are the options we considered:
- Get everyone to sign up for a secondary GitHub account to use for this project.
- Redact the history so no-one could see personal information.
- Use the same GitHub credentials for everyone.
There are problems with all the above approaches. Additional accounts are a huge administrative and cognitive burden. Scrubbing the history on publication doesn't facilitate transparency. And sharing login details? Yeuch!
So what could we do?
GitHub has a nifty feature - it allows you to commit on-behalf-of an organisation.
With a simple change to your commit message, you can show that you're working on behalf of an organisation. Handy if you want to separate your commits into personal and professional. Or if you're a member of multiple organisations.
Here's what we wanted - publish as an organisation!
I'd like to sketch out how this might work - then I'd like some criticism from you on why it's bad idea.
User Story
- As an @Organisation on GitHub
- With a team of authorised members
- I want all the public commits from the team to show as coming from the @Organisation
- So that I can preserve the privacy of the authorised members
(This could also work by committing as the team.)
Practicalities
- Add a team to GitHub
- Populate it with members
- Flick on this option:
Any member of the team can see that this commit came from Alice and that commit came from Bob. But people outside the team would just see both of those commits coming directly from the organisation.
This enables the team to see who made which changes, but keeps it private for everyone else.
Downsides
Does this lull developers into a false sense of security? If the commit message still says "Asked to add this by @alice. Yours sincerely, @bob" then privacy is compromised.
Is this even possible with the git protocol? Teams are a part of GitHub - but I don't think they're part of the specification. Would this screw up the cryptographic signing of commits?
Part of open source is transparency. Do we want to lose that?
GitHub would be able to de-anonymise you. But you're already trusting them with parts of your infrastructure anyway.
Your thoughts?
Is this useful - or am I barking up the wrong tree?
Interesting.
We come across a challenge when someone works on a project, is released by an org, they then move roles/leave. Years later they get contacted/expected to offer support as an individual, rather than it being the orgs responsibility.
Thoughts @martinwoodward?
what about something like gitmask.com? You add a remote gitmask repo, when you push a commit to it it replicates your commits but now they seem to come from the gitmask user, then it makes a PR to the main actual repo with your commit minus your deets
Your request has been noted, citizen!
Currently, I guess you could create a user account with a generic name, and everyone uses the email address of that account as author email.
The tough part is attributing web operations... 🤔
I personally really like the concept. But for anyone using git they'd have to be aware there was a level of indirection every time they pushed, which is bound to cause trouble and potentially problems with GitHub maintaining.
What if your team operated on a private repo - but you could highlight branches which were "published" to a public repo? Your commits would be taken - message attached - and reproduced against the public version of your code by an organisation account. That way your team get to operate with freedom, but their work is still open to inspection.
I know other orgs do this by their own infrastructure - but having it available in GitHub would be a very clear and straight forward way of promoting transparency in organisations
Seems to be like it'd be simpler to create a
@organisation-anonuser account, and have that account do the commits. That way the user account can have a profile describing why those commits need to be anonymous.I think it’s also worth preserving coding-in-the-open wherever possible.
yup!
basically you can either have
a) a 'special' org account used only occasionally
b) everyone attributed as themselves
c) full-fat local feed, mirrored+filtered to Github, never use Github web UI for anything
d) a security nightmare
Andrew Coulton says:
It would only work in the web viewer though. Anyone could still clone the repo and see the original commit messages with their author name and email etc. These can't be redacted/hidden in the git history as they are part of the hash that forms the commit SHA.
The better option would be for the team working on this project to just change their local git config for that repository to use a pseudonym/fake email address so that all their commits in git itself show up as being from that author/committer.
They can still use their actual github account to push etc as GitHub doesn't care whether the commit says it's by the person pushing or not. If there's no GitHub user account for the email on the commit GitHub just shows the commit author name without linking it to a user profile.
Obviously this would only solve the issues for commits - pull requests, issues, review comments etc would still show up as being from the logged-in GitHub user.
I think this would be two repos. Your internal repo with all the commits and users, and a second repo that has the institutional code drops. Every so often you check out the internal repo into the external one and do an institutional commit of all the changes - perhaps with a big comment automatically generated from the internal repo comments since the last code drop. This only really works for one-way code drops but you could apply external contributions against the internal repo. It isn't real open development, but that is what you don't want.
Wow, such a shame you have to worry about this in the first place 🙁 As the comment on the post says, though, I would think a simple git config change would solve the problem. Set name & email to generic org name/address, no?
This is an excellent suggestion
--author?
Personally I'd implement this as PRs and a bot that merges when the approval requirement us met.
(The approval being the "organisation" part)