6 ms·

The pull request hack is fucking magic

169 points by edent 3y ago

zeeed 3y ago
Incorporates one of the more astounding insights I’ve had over the years: complexity can often be reduced through trust.
eye-robot 3y ago
'scuse me?? Are you allowed to talk that way on the internet??
bob1029 3y ago
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.
- diarrhea 3y ago
  Sadly, as with all things nice, if the practice became widespread enough, it would cease to work for abundance of malicious actors.
ChatGTP 3y ago
Off-topic, but does anyone else love the design of that blog?
- bjord 3y ago
  I think it's a pleasant departure from the norm, but I'm not sure I'd use it myself.
- Ilasky 3y ago
  It has got some neobrutalism vibes
- edent 3y ago
  Thank you :-) I designed it myself on top of a bare-bones WordPress theme. The source code is at https://gitlab.com/edent/blog-theme/ https://gitlab.com/edent/blog-theme/ Pull Requests - and commit rights - welcome!
  - ChatGTP 3y ago
    It was so refreshing, cheers :)
bjord 3y ago
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.
api 3y ago
Attackers would use it to gain access to inject malware if the project was at all popular. The Internet is a dark forest. This only works as a skill filter. It doesn’t work in an environment with malicious actors.
- capableweb 3y ago
  If only the author had something to say about this problem... > 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.
  - api 3y ago
    He did, but the problem is that any package anyone uses for anything could compromise security. So what could you use this with? This sort of openness is an elegant weapon from a more civilized age. These days the net is like a zombie movie where if you leave a crack in the boards covering the windows the arms will reach in.
    - imtringued 3y ago
      >So what could you use this with? Dead projects and projects that are so young they are more likely to be abandoned than finished. It doesn't work for projects that already have enough vetted members.
    - capableweb 3y ago
      Ok, lets consider the authors example of SuperTinyIcons (https://github.com/edent/SuperTinyIcons https://github.com/edent/SuperTinyIcons). What are some possible ways you could send a PR, gain commit rights and then use it for compromising security?
      - flaviut 3y ago
        Javascript in the SVGs?
pipes 3y ago
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. Edit here it is: https://www.theserverside.com/feature/Recent-open-source-flaw-highlights-danger-of-social-engineering-hacks https://www.theserverside.com/feature/Recent-open-source-fla...
- aaron695 3y ago
  [dead]
- duncan-donuts 3y ago
  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.
  - Cpoll 3y ago
    > how do you vet that 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.
- alexandre_m 3y ago
  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.
politelemon 3y ago
It only works for certain kinds of projects. It makes sense for the icons repo, the contributions are minimal in variance. In the case of large complex codebase though, the change is something that you will have to maintain going forward. The committer will have attained their goal of introducing a change they wanted and may not be around to deal with issues arising from that new feature. That's been my observation so far across many repos. Having a maintainer that chooses to accept or deny something is vital imo.
seba_dos1 3y ago
> It sounds mad, I know. No, it sounds like it usually works, even if not necessarily right after the first contribution. I've got commit access to many repositories just by contributing things to them (and sometimes it happened already after I was done with stuff I wanted to do there and never actually used that access). It doesn't make sense if you have enough responsive maintainers, but many projects don't.
stavros 3y ago
I created https://www.codeshelter.co/ https://www.codeshelter.co/ years ago based on basically this premise (put your project in the community, any vetted member of the community can be automatically approved to become a contributor). Unfortunately, there was much more demand than supply, so it never took off, but I still think it's a good model.
- danpalmer 3y ago
  The Python/Django ecosystem has a similar concept with Jazzband – https://jazzband.co/ https://jazzband.co/ I've always found their projects to be high quality, well maintained, with a great community, and I quickly got to the point where I wouldn't think twice about adding a Jazzband dependency. The model can work, and when it does it's great for the wider community.
TrianguloY 3y ago
I applied this on my latest open source app, and I added two contributors, and so far it has worked fine! However I only added them after the second or third pr, just to know if they are interested enough, and I always monitor the repository so if for some reason someone adds malicious code I will notice (and revert back).
emmelaich 3y ago
I attended a talk on Perl6 by https://en.wikipedia.org/wiki/Audrey_Tang https://en.wikipedia.org/wiki/Audrey_Tang once. Very nicely she gave me a commit bit for Perl6. Sorry Audrey, I never used it!
jimmytucson 3y ago
This is a post about another post: https://felixge.de/2013/03/11/the-pull-request-hack/ https://felixge.de/2013/03/11/the-pull-request-hack/ The tl;dr is up top: Whenever somebody sends you a pull request, give them commit access to your project.
- em-bee 3y ago
  which was also discussed on hacker news: https://news.ycombinator.com/item?id=5357417 https://news.ycombinator.com/item?id=5357417
dmw_ng 3y ago
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
- aseipp 3y ago
  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.
- woodruffw 3y ago
  I don’t think “hoarding” is a useful framing. 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.
franzb 3y ago
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 http://hintjens.com/blog:125 One of the most inspiring engineering biographies I’ve ever read.
jjgreen 3y ago
Oh, the language. You wouldn't hear it from a docker! Fecking this, fecking that... Ah, you would. They use very bad language. Effin' this and effin' that... Oh, it was much worse than that, Ted, she was saying fu... Now, Dougal!
oefrha 3y ago
> 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.
tolstoshev 3y ago
Developers discover community management - news at 11.
humanistbot 3y ago
> 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."
- CyberShadow 3y ago
  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.
  - humanistbot 3y ago
    > 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.
- jtc331 3y ago
  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.
- electroly 3y ago
  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.
arp242 3y ago
A project that I took over did this (before I took over), it's something the previous maintained did out of desperation as he didn't really want to maintain it any more, but also had trouble finding a new maintainer. I have since revoked most people's access because: - Most people were inactive and never contributed anything beyond the initial PR in terms of code or triaging issues. - One person made a horrible PR that ended up having to be reverted (happened before I become active). - One person, a Red Hat employee with no involvement for over a year, pretty much told someone to fuck off after asking a question on the issue tracker and closed the issue. The question was fine and this is very much NOT how I want to run projects (I have since removed his access). In short, I'm not a fan, especially due that last issue: people being inactive is fine, a bad PR could be caught before release, but someone making "official" rude comments and closing issues: can't really do much about that

169 points by edent 3y ago

Incorporates one of the more astounding insights I’ve had over the years: complexity can often be reduced through trust.

eye-robot 3y ago

'scuse me?? Are you allowed to talk that way on the internet??

bob1029 3y ago

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.

diarrhea 3y ago
Sadly, as with all things nice, if the practice became widespread enough, it would cease to work for abundance of malicious actors.

ChatGTP 3y ago

Off-topic, but does anyone else love the design of that blog?

bjord 3y ago
I think it's a pleasant departure from the norm, but I'm not sure I'd use it myself.
Ilasky 3y ago
It has got some neobrutalism vibes
edent 3y ago
Thank you :-) I designed it myself on top of a bare-bones WordPress theme. The source code is at https://gitlab.com/edent/blog-theme/ https://gitlab.com/edent/blog-theme/ Pull Requests - and commit rights - welcome!
- ChatGTP 3y ago
  It was so refreshing, cheers :)

bjord 3y ago

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.

api 3y ago

Attackers would use it to gain access to inject malware if the project was at all popular. The Internet is a dark forest. This only works as a skill filter. It doesn’t work in an environment with malicious actors.

capableweb 3y ago
If only the author had something to say about this problem... > 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.
- api 3y ago
  He did, but the problem is that any package anyone uses for anything could compromise security. So what could you use this with? This sort of openness is an elegant weapon from a more civilized age. These days the net is like a zombie movie where if you leave a crack in the boards covering the windows the arms will reach in.
  - imtringued 3y ago
    >So what could you use this with? Dead projects and projects that are so young they are more likely to be abandoned than finished. It doesn't work for projects that already have enough vetted members.
  - capableweb 3y ago
    Ok, lets consider the authors example of SuperTinyIcons (https://github.com/edent/SuperTinyIcons https://github.com/edent/SuperTinyIcons). What are some possible ways you could send a PR, gain commit rights and then use it for compromising security?
    - flaviut 3y ago
      Javascript in the SVGs?

pipes 3y ago

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. Edit here it is: https://www.theserverside.com/feature/Recent-open-source-flaw-highlights-danger-of-social-engineering-hacks https://www.theserverside.com/feature/Recent-open-source-fla...

aaron695 3y ago
[dead]
duncan-donuts 3y ago
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.
- Cpoll 3y ago
  > how do you vet that 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.
alexandre_m 3y ago
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.

politelemon 3y ago

It only works for certain kinds of projects. It makes sense for the icons repo, the contributions are minimal in variance. In the case of large complex codebase though, the change is something that you will have to maintain going forward. The committer will have attained their goal of introducing a change they wanted and may not be around to deal with issues arising from that new feature. That's been my observation so far across many repos. Having a maintainer that chooses to accept or deny something is vital imo.

seba_dos1 3y ago

> It sounds mad, I know. No, it sounds like it usually works, even if not necessarily right after the first contribution. I've got commit access to many repositories just by contributing things to them (and sometimes it happened already after I was done with stuff I wanted to do there and never actually used that access). It doesn't make sense if you have enough responsive maintainers, but many projects don't.

stavros 3y ago

I created https://www.codeshelter.co/ https://www.codeshelter.co/ years ago based on basically this premise (put your project in the community, any vetted member of the community can be automatically approved to become a contributor). Unfortunately, there was much more demand than supply, so it never took off, but I still think it's a good model.

danpalmer 3y ago
The Python/Django ecosystem has a similar concept with Jazzband – https://jazzband.co/ https://jazzband.co/ I've always found their projects to be high quality, well maintained, with a great community, and I quickly got to the point where I wouldn't think twice about adding a Jazzband dependency. The model can work, and when it does it's great for the wider community.

TrianguloY 3y ago

I applied this on my latest open source app, and I added two contributors, and so far it has worked fine! However I only added them after the second or third pr, just to know if they are interested enough, and I always monitor the repository so if for some reason someone adds malicious code I will notice (and revert back).

emmelaich 3y ago

I attended a talk on Perl6 by https://en.wikipedia.org/wiki/Audrey_Tang https://en.wikipedia.org/wiki/Audrey_Tang once. Very nicely she gave me a commit bit for Perl6. Sorry Audrey, I never used it!

jimmytucson 3y ago

This is a post about another post: https://felixge.de/2013/03/11/the-pull-request-hack/ https://felixge.de/2013/03/11/the-pull-request-hack/ The tl;dr is up top: Whenever somebody sends you a pull request, give them commit access to your project.

em-bee 3y ago
which was also discussed on hacker news: https://news.ycombinator.com/item?id=5357417 https://news.ycombinator.com/item?id=5357417

dmw_ng 3y ago

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

aseipp 3y ago
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.
woodruffw 3y ago
I don’t think “hoarding” is a useful framing. 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.

franzb 3y ago

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 http://hintjens.com/blog:125 One of the most inspiring engineering biographies I’ve ever read.

jjgreen 3y ago

Oh, the language. You wouldn't hear it from a docker! Fecking this, fecking that... Ah, you would. They use very bad language. Effin' this and effin' that... Oh, it was much worse than that, Ted, she was saying fu... Now, Dougal!

oefrha 3y ago

> 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.

tolstoshev 3y ago

Developers discover community management - news at 11.

humanistbot 3y ago

> 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."

CyberShadow 3y ago
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.
- humanistbot 3y ago
  > 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.
jtc331 3y ago
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.
electroly 3y ago
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.

arp242 3y ago

A project that I took over did this (before I took over), it's something the previous maintained did out of desperation as he didn't really want to maintain it any more, but also had trouble finding a new maintainer. I have since revoked most people's access because: - Most people were inactive and never contributed anything beyond the initial PR in terms of code or triaging issues. - One person made a horrible PR that ended up having to be reverted (happened before I become active). - One person, a Red Hat employee with no involvement for over a year, pretty much told someone to fuck off after asking a question on the issue tracker and closed the issue. The question was fine and this is very much NOT how I want to run projects (I have since removed his access). In short, I'm not a fan, especially due that last issue: people being inactive is fine, a bad PR could be caught before release, but someone making "official" rude comments and closing issues: can't really do much about that