5 ms·

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

AndrewGaspar 8y ago
The reasonable answer is that he should absolutely not have handed over publish capabilities to a completely unknown third-party. This seems obvious to me.
- jimison 8y ago
  It's the internet... we're all unknown to each other, and many modern web apps are running a huge stack of unvetted code. Honestly, a problem like this is overdue, especially for the NPM ecosystem with its propensity for a huge number of transitive dependencies, but also for all other major repos (nuget, cargo, CPAN, Docker, etc.). OS-based repos (Debian, Ubuntu, FreeBSD) might feel a little safer because it's harder to become a publisher, but it's not at all impossible. Perhaps the only reason it hasn't been a target before now is because there are easier avenues for cybercrime.
- always_good 8y ago
  Then let me ask you, how long should have dominic let right9ctrl contribute to the project before trusting him and giving him publish capabilities? With hindsight, we know that right9ctrl is going to publish a backdoor the second he gets rights. How long do you make right9ctrl wait? And does that accomplish what you want? If you think that ownership transfer should exist at all, then the attack vector still exists no matter how long you wait to trust right9ctrl.
  - AndrewGaspar 8y ago
    If I give the maid a key to the house, there's always an attack vector, but that doesn't mean I just go hire some rando off craiglist. There are a number of factors that could be considered when giving somebody this kind of responsibility, including existing contributions to open source, contributions to the project at hand, and public profile. As far as I can tell, "right9ctrl" had none of these.
ocdtrekkie 8y ago
You can't vet the people, but you can vet the code. Of course, if you just give someone commit rights, then you can't. But generally speaking the maintainer understands the code they merge into a project, and that is the vetting that takes place.
- AndrewGaspar 8y ago
  Nobody's saying you should never accept a patch from an unknown person. "Of course, if you just give someone commit rights, then you can't." is the whole point!
- shittyadmin 8y ago
  Sure, but then they have to actively invest time into the project... not everyone can afford that.
  - heartbreak 8y ago
    Then mark the project as abandoned and add a note suggesting the new volunteer’s fork.
- kurtisc 8y ago
  If you're using auto-updating external packages, aren't you effectively giving the package author commit access to your derivative project too?
deleted 8y ago
[deleted]
rando231 8y ago
If you can't or don't want to maintain the project and can't find anyone trustworthy to take it over, just don't do anything. This effectively deprecates the project, while not harming its existing functionality. This maintainer actively ceded control of his library to some random person.
- tschellenbach 8y ago
  Yeah this one is easy to spot, but what if someone makes valid contributions and for pull request #10 slips in a backdoor. Most open source projects are not able to check that anywhere near thoroughly enough.

AndrewGaspar 8y ago

The reasonable answer is that he should absolutely not have handed over publish capabilities to a completely unknown third-party. This seems obvious to me.

jimison 8y ago
It's the internet... we're all unknown to each other, and many modern web apps are running a huge stack of unvetted code. Honestly, a problem like this is overdue, especially for the NPM ecosystem with its propensity for a huge number of transitive dependencies, but also for all other major repos (nuget, cargo, CPAN, Docker, etc.). OS-based repos (Debian, Ubuntu, FreeBSD) might feel a little safer because it's harder to become a publisher, but it's not at all impossible. Perhaps the only reason it hasn't been a target before now is because there are easier avenues for cybercrime.
always_good 8y ago
Then let me ask you, how long should have dominic let right9ctrl contribute to the project before trusting him and giving him publish capabilities? With hindsight, we know that right9ctrl is going to publish a backdoor the second he gets rights. How long do you make right9ctrl wait? And does that accomplish what you want? If you think that ownership transfer should exist at all, then the attack vector still exists no matter how long you wait to trust right9ctrl.
- AndrewGaspar 8y ago
  If I give the maid a key to the house, there's always an attack vector, but that doesn't mean I just go hire some rando off craiglist. There are a number of factors that could be considered when giving somebody this kind of responsibility, including existing contributions to open source, contributions to the project at hand, and public profile. As far as I can tell, "right9ctrl" had none of these.

ocdtrekkie 8y ago

You can't vet the people, but you can vet the code. Of course, if you just give someone commit rights, then you can't. But generally speaking the maintainer understands the code they merge into a project, and that is the vetting that takes place.

AndrewGaspar 8y ago
Nobody's saying you should never accept a patch from an unknown person. "Of course, if you just give someone commit rights, then you can't." is the whole point!
shittyadmin 8y ago
Sure, but then they have to actively invest time into the project... not everyone can afford that.
- heartbreak 8y ago
  Then mark the project as abandoned and add a note suggesting the new volunteer’s fork.
kurtisc 8y ago
If you're using auto-updating external packages, aren't you effectively giving the package author commit access to your derivative project too?

deleted 8y ago

[deleted]

rando231 8y ago

If you can't or don't want to maintain the project and can't find anyone trustworthy to take it over, just don't do anything. This effectively deprecates the project, while not harming its existing functionality. This maintainer actively ceded control of his library to some random person.

tschellenbach 8y ago
Yeah this one is easy to spot, but what if someone makes valid contributions and for pull request #10 slips in a backdoor. Most open source projects are not able to check that anywhere near thoroughly enough.