I can't remember the name of the projects but a "bad guy" befriended the guy who looked after a small bit of code that happened to be a down stream dependency of a crypto wallet.
After helpfully contributing code and back and forth friendly chat, the maintainer gave the bad guy commit access.
In this case there isn’t a lot you can do. If a bad actor is going to spend a lot of time gaining your trust and doing good before they do bad how do you vet that? You either have to maintain full control forever or you have accept this possibility. The OP does mention that this might be a bad idea if your project has any level of security.
One of the maxims of security is that a sufficiently determined and resourceful attacker will always win. The defender's job is to disincentivize the attacker.
However, I think for a sufficiently high-impact project no-one should have commit access, every commit should be reviewed by quorum. Even so, you still run into "Underhanded C"-style stuff (and disinterested reviewers), and you still need to vet the quorum.
Most project dependencies management process is flawed.
We shouldn't blindly upgrade modules/deps minor or patch versions to latest with a single command. SemVer encourages this, but we should be more careful.
The software supply chain for a lot of OSS is flawed as well. We need software signatures, and less central artifact registries that can be compromised easily.
I don't have a perfect solution for all these problems. Rewriting code instead of relying on external deps, vendoring, automated vulnerability scans, higher scrutiny for all external code, and tighter processes for code management.
I somewhat agree on principle, but at the same time, it is hard enough keeping ur software patched and up to date already, adding more friction to that process may cause more damage than it prevents.
You might prevent malicious new code at the cost of running old vulnerable code longer.
> The Pull Request Hack probably isn't suitable if you're running big projects. And it is almost certainly a stupid idea if you write code which is actively used by multiple downstream projects. And if your stuff has even the slightest chance of compromising security then you're better off sticking to trusted members.
The code (event-stream, a popular NPM package which was targeted because it's used by a crypto wallet) fails all 3 criteria.
Only one... It is really tiny and has nothing to do with security. (As in, not directly... Actually everything can impact security if it's used wrong so that point is moot).
It does have multiple downstream users. But I will bet 99% of projects where contributors submit good PRs, and maintainers have not enough time so they give commit access, have multiple downstream users.
Have never understood the desire to hoard commit rights, half the point of RCS is rollback, and as the article says, once intent is established through effort ("proof of work") there is little risk in assuming good faith until demonstrated otherwise.
Commit rights are an asymmetrical reward for someone showing interest in a piece of code - cheap to offer and incredibly valuable to receive. They also immediately reduce the long term burden and "ownership" of the code, and for the trusted committer, massively reduce friction and any sense of gatekeeping in contributing to the project. I've done this on at least 4 projects, 3 of them were eventually transferred to the new long term maintainer and 1 became an org of its own, with two maintainers having full admin
I'd probably "hoard" rights. Which is to say, any FOSS project that i am invested in, i am going to fight hard to ensure someone does not have the ability to make my life more difficult. I'd love to give out commit rights, but if it's some random good quality PR there's a very large chance that i now have to maintain that code - as well as any future code they merge if given rights.
I hand out code rights freely to those who seem similarly invested. As they can then share the burden for each new issue popping up, etc. However writing the code (the PR) is usually not the hard part in a FOSS project. The fortitude to maintain it is. As the weeks, months and years go by - who will be around?
"Commit rights" here seem pretty off-topic to me, honestly. This is FOSS. Assuming a permissive license, you can fork it and publish your own freely. It's not an insult to me for you to do that.
But yea, if i'm looking for an out - i'll hand them out to anyone interested. If however i'm needing to maintain it for my own purpose, then my time and will are the resources i'm most concerned about. A single PR is not a the only variable in the equation there, imo.
Exactly 0 people are maintainers of projects they don't have commit access to.
Even if they dip after 6 month it's far better to have the option to remove any of the 6 months worth of commits in the current codebase than to hypothesis about the state of a future codebase/environment 6 months ago. This becomes even easier with good commit messages.
If somebody is a user and decides to write a pull request, they are already invested anything more is virtue signaling, no amount of which will guarantee that they will be there in years, which is an unreasonable stipulation for a project that could be obsolete yesterday.
Instead, the observation is that granting others access to projects has a time dimension: you need to not only find them trustworthy now, but also reasonably believe that they will remain trustworthy. That last part is much harder, and includes things that are partially outside of the other person’s control (like account takeovers, being targeted by foreign and domestic law enforcement, etc.).
I generally think projects should accept more maintainers; however, your point about asymmetry goes both ways.
Really depends on the dynamics of the project, and its life cycle. If you're in a well-established project with norms, conventions, long-time users, existing long-time developers, stable features and cadence, and have a lot of code to maintain -- I think being conservative with who you give commit rights to is fairly important. The project is going to have expectations around conventions, maintenance, what quality bar to meet, etc and breaking from those isn't always a good thing.
I do think being more liberal with commit bits helps a lot more when you have a project you want to grow, that is new, and you have a lot of code that needs to be written by a lot of people, and ideas to explore, and things that even need rewriting. You need the code written, people to use the software, so you know where to further drive improvements. You need people willing to dogfood and rewrite things and fix the thing they just broke.
I wouldn't give commit rights to anybody in that case but, like. If you have a solid history of +5 patches, you have some clear FOSS experience of your own, clearly have skill, and it's early on in the life of the project? I just need the help? Yeah, you could make worse decisions.
I have been on both very established projects of 20+ years where commit rights came months after writing patches, and newer projects where they came days after writing patches because the project was (is) still growing. Ultimately, I think it comes down to having an idea of where you want things to go, and picking out the people who seem to share that idea.
In my experience commit rights also decrease the quality of the code. Nearly everyone sucks. I've had to rewrite FOSS to get rid of the ugly. Ideally I could have kept a better eye on the commits but time doesn't always allow.
> there is little risk in assuming good faith until demonstrated otherwise.
The risk is that a malicious user fakes good commits, earns commit rights, and then pushes malware that is then installed by unsuspecting downstream users before the code is found and reverted.
This can be partially mitigated by making sure they don’t have permission to create a release, but it would still be possible to compromise developers working off the main branch.
Game theory around this is fairly robust for me. If someone is willing to spend their time to put together anything with good intentions, then I feel like an initial offering of trust is an excellent response.
> The Pull Request Hack probably isn't suitable if you're running big projects. And it is almost certainly a stupid idea if you write code which is actively used by multiple downstream projects. And if your stuff has even the slightest chance of compromising security then you're better off sticking to trusted members.
Just about any code project in any real programming language targeting any not super locked-down platform has a chance of compromising security, so that’s not a great criterion. The project given as an example (collection of super small SVG icons) is an outlier, and even there it’s possible to smuggle a short embedded script into a <1KB SVG, e.g. you can read/manipulate DOM (if the <svg> is directly in DOM as opposed to in a separate document) and use fetch() without problem in an embedded script tag.
I’ve assigned strangers as maintainers on moderately popular projects (>1k GitHub stars) and the results have been satisfactory so far. Of course there’s a possibility that one day I’ll end up on HN front page having to explain why my project is shipping malware, but that chance seems really slim.
> Several years ago, I came across Felix Geisendörfer's Pull Request Hack. The premise is simple - if people are making decent Pull Requests to your project then you should give them commit access.
This is not a "hack", this is precisely how free and open source software projects have operated since before GitHub existed. It is sad how much of that culture has been lost and is reinventing the wheel.
The more radical version is that you automatically merge every PR that passes the tests and give the committer commit access. But it seems strange to see the default social practice of giving commit access to those who make decent PRs described as a "hack."
Um, how exactly do you mean that? The pre-GitHub equivalent would be giving people commit access to the CVS/Subversion repository. This generally did not happen lightly either in most projects.
> The pre-GitHub equivalent would be giving people commit access to the CVS/Subversion repository.
Correct.
> This generally did not happen lightly either in most projects.
Maybe not for the super big or central projects. But for most in that long tail, that's been my experience, at least in Debian. For a long time, there have been tons of orphaned projects or projects actively looking for new maintainers.
I can't agree from my own memory of the time. From how jealously most projects guarded commit access to CVS, you'd think the commit bit was a key to their personal homes and an invitation to sleep with their wives. Many (most?) "open source" projects in the early days had a private CVS that outsiders couldn't even read; the original model everyone followed was just source code dumps on FTP alongside binary releases. Maybe we're talking about different time periods.
I think the “hack” language is correct because it’s a rethinking of GitHub at some level.
More importantly though I think you’re missing something very big about open source projects — the transition from “small project with single maintainer” to “group ownership” has always been a difficult one; that’s not unique to GitHub.
It's a bit surprising to me that this is seen as a "hack". My projects have always had limited enough reach that I probably would've readily given commit access to anyone who cared enough to submit a PR.
An even more radical version of this idea was popularized by the late Pieter Hintjens —an amazing guy— in his post (and later book) “Confessions of a Necromancer”: http://hintjens.com/blog:125
One of the most inspiring engineering biographies I’ve ever read.
Readit News
Edit here it is: https://www.theserverside.com/feature/Recent-open-source-fla...
One of the maxims of security is that a sufficiently determined and resourceful attacker will always win. The defender's job is to disincentivize the attacker.
However, I think for a sufficiently high-impact project no-one should have commit access, every commit should be reviewed by quorum. Even so, you still run into "Underhanded C"-style stuff (and disinterested reviewers), and you still need to vet the quorum.
We shouldn't blindly upgrade modules/deps minor or patch versions to latest with a single command. SemVer encourages this, but we should be more careful.
The software supply chain for a lot of OSS is flawed as well. We need software signatures, and less central artifact registries that can be compromised easily.
I don't have a perfect solution for all these problems. Rewriting code instead of relying on external deps, vendoring, automated vulnerability scans, higher scrutiny for all external code, and tighter processes for code management.
You might prevent malicious new code at the cost of running old vulnerable code longer.
The code (event-stream, a popular NPM package which was targeted because it's used by a crypto wallet) fails all 3 criteria.
It does have multiple downstream users. But I will bet 99% of projects where contributors submit good PRs, and maintainers have not enough time so they give commit access, have multiple downstream users.
Dead Comment
Commit rights are an asymmetrical reward for someone showing interest in a piece of code - cheap to offer and incredibly valuable to receive. They also immediately reduce the long term burden and "ownership" of the code, and for the trusted committer, massively reduce friction and any sense of gatekeeping in contributing to the project. I've done this on at least 4 projects, 3 of them were eventually transferred to the new long term maintainer and 1 became an org of its own, with two maintainers having full admin
I hand out code rights freely to those who seem similarly invested. As they can then share the burden for each new issue popping up, etc. However writing the code (the PR) is usually not the hard part in a FOSS project. The fortitude to maintain it is. As the weeks, months and years go by - who will be around?
"Commit rights" here seem pretty off-topic to me, honestly. This is FOSS. Assuming a permissive license, you can fork it and publish your own freely. It's not an insult to me for you to do that.
But yea, if i'm looking for an out - i'll hand them out to anyone interested. If however i'm needing to maintain it for my own purpose, then my time and will are the resources i'm most concerned about. A single PR is not a the only variable in the equation there, imo.
Instead, the observation is that granting others access to projects has a time dimension: you need to not only find them trustworthy now, but also reasonably believe that they will remain trustworthy. That last part is much harder, and includes things that are partially outside of the other person’s control (like account takeovers, being targeted by foreign and domestic law enforcement, etc.).
I generally think projects should accept more maintainers; however, your point about asymmetry goes both ways.
I do think being more liberal with commit bits helps a lot more when you have a project you want to grow, that is new, and you have a lot of code that needs to be written by a lot of people, and ideas to explore, and things that even need rewriting. You need the code written, people to use the software, so you know where to further drive improvements. You need people willing to dogfood and rewrite things and fix the thing they just broke.
I wouldn't give commit rights to anybody in that case but, like. If you have a solid history of +5 patches, you have some clear FOSS experience of your own, clearly have skill, and it's early on in the life of the project? I just need the help? Yeah, you could make worse decisions.
I have been on both very established projects of 20+ years where commit rights came months after writing patches, and newer projects where they came days after writing patches because the project was (is) still growing. Ultimately, I think it comes down to having an idea of where you want things to go, and picking out the people who seem to share that idea.
The risk is that a malicious user fakes good commits, earns commit rights, and then pushes malware that is then installed by unsuspecting downstream users before the code is found and reverted.
This can be partially mitigated by making sure they don’t have permission to create a release, but it would still be possible to compromise developers working off the main branch.
Just about any code project in any real programming language targeting any not super locked-down platform has a chance of compromising security, so that’s not a great criterion. The project given as an example (collection of super small SVG icons) is an outlier, and even there it’s possible to smuggle a short embedded script into a <1KB SVG, e.g. you can read/manipulate DOM (if the <svg> is directly in DOM as opposed to in a separate document) and use fetch() without problem in an embedded script tag.
I’ve assigned strangers as maintainers on moderately popular projects (>1k GitHub stars) and the results have been satisfactory so far. Of course there’s a possibility that one day I’ll end up on HN front page having to explain why my project is shipping malware, but that chance seems really slim.
This is not a "hack", this is precisely how free and open source software projects have operated since before GitHub existed. It is sad how much of that culture has been lost and is reinventing the wheel.
The more radical version is that you automatically merge every PR that passes the tests and give the committer commit access. But it seems strange to see the default social practice of giving commit access to those who make decent PRs described as a "hack."
Correct.
> This generally did not happen lightly either in most projects.
Maybe not for the super big or central projects. But for most in that long tail, that's been my experience, at least in Debian. For a long time, there have been tons of orphaned projects or projects actively looking for new maintainers.
Perhaps, or different ecosystems. Most of my experience is in Debian.
More importantly though I think you’re missing something very big about open source projects — the transition from “small project with single maintainer” to “group ownership” has always been a difficult one; that’s not unique to GitHub.
Very nicely she gave me a commit bit for Perl6. Sorry Audrey, I never used it!
One of the most inspiring engineering biographies I’ve ever read.