4 ms·

That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, th

That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?

pmontra 5y ago
I happened to create an infinite loop in some of my programs but not intentionally like the author did. Furthermore he intentionally pushed the infinite loop with the result to DoS everybody knowingly or unknowingly using his software. This is malicious behavior IMHO.
ulimn 5y ago
If they wanted to publish it for themselves, wouldn't they make a private repo? I'm (honestly) trying to understand why GitHub can't just go ahead and remove any account as they see fit. Edit: Am I being downvoted for asking a question?
- throwawayay02 5y ago
  There are many valid reasons to make code for yourself public, even before discussing the type of license.
afiori 5y ago
The keyword is malicious, which does not lend nicely to be deconstructed by reductionism. If the intent of the push was to damage downstream users of the software then it is malicious towards them.
ajkjk 5y ago
If they're malicious, yes?
sailingparrot 5y ago
Sure, trying to find exactly where the malicious line gets crossed is pretty hard and subjective, and maybe that will bite GH one day. But this specific case is not anywhere near that line, the sole intent of those commits was to break others, and he admitted so himself. This is like arguing about whether the james webb telescope really is in space since we don't have a precise consensus about what altitude is considered the frontier with space.
- raesene9 5y ago
  I'm sure this case is clear, my point was around the wider principal that by going down this line GH set themselves up as arbiter of "malice" To take a trickier example, say a GH user has a lib, then decides to re-architect it, breaks the API and for their own purposes pushes it to an existing version, breaking all other use of it. Now that's a nasty thing to do, but is it malice? Another, real-world, example is I know of a user who publishes "honey PoCs" for security issues, where the repo. appears to be a exploit code but actually isn't. He's been accused of malice in doing this, but his intent is research for a talk on how people use code blindly without testing. Is that malice, should GH take his account down? By stepping into this area GH are going to have to find answers to this and also the problem of who maintains the repos of accounts they nuke?
  - sailingparrot 5y ago
    > By stepping into this area GH are going to have to find answers to this a I think they already have, those 2 examples you mentioned already happened and were dealt with. I think intent is important to take into consideration, since after all that is the definition of malicious: intent to cause harm. Your first example clearly has no intent to cause harm. That case probably happened thousands of time already since not everyone is willing/able to follow semver cleanly and strictly. Never heard about GH taking any measure against that. And I would definitely not expect them to as a user/maintainer. For the second case, I think GH policy is that you can host that kind of PoCs, but the repo has to be clearly documented as doing such (e.g. you can't just add some vuln into some unrelated code "for research"), and the vulnerability cannot be an active one: "We understand that the publication and distribution of proof of concept exploit code has educational and research value to the security community, and our goal is to balance that benefit with keeping the broader ecosystem safe. In accordance with our Acceptable Use Policies, GitHub disabled the gist following reports that it contains proof of concept code for a recently disclosed vulnerability that is being actively exploited." - GitHub." [1] Back to Marak's case, my opinion is that GH did the right thing: If he just had his code in a repo, with no semver, no other contributors/maintainers, and such, and decides to nuke it, then I hope GH would not have done anything. But when you are using all the tools and trust of open source: Other people contributing to your repo, other people being active maintainers/admins and spending times out of their days to fix bugs on it, when you leverage NPM to make it easier for you to distribute your package to others widly etc, you give up the privilege being able to act unilaterally like an asshole without consequences. [1]: https://www.bleepingcomputer.com/news/security/githubs-new-policies-allow-removal-of-poc-exploits-used-in-attacks/ https://www.bleepingcomputer.com/news/security/githubs-new-p...
viro 5y ago
That's not what happened here. Author intentionally pushed malware.
kzrdude 5y ago
With great power comes great responsibility. Having a much-depended on package is a great responsibility.

pmontra 5y ago

I happened to create an infinite loop in some of my programs but not intentionally like the author did. Furthermore he intentionally pushed the infinite loop with the result to DoS everybody knowingly or unknowingly using his software. This is malicious behavior IMHO.

ulimn 5y ago

If they wanted to publish it for themselves, wouldn't they make a private repo? I'm (honestly) trying to understand why GitHub can't just go ahead and remove any account as they see fit. Edit: Am I being downvoted for asking a question?

throwawayay02 5y ago
There are many valid reasons to make code for yourself public, even before discussing the type of license.

afiori 5y ago

The keyword is malicious, which does not lend nicely to be deconstructed by reductionism. If the intent of the push was to damage downstream users of the software then it is malicious towards them.

ajkjk 5y ago

If they're malicious, yes?

sailingparrot 5y ago

Sure, trying to find exactly where the malicious line gets crossed is pretty hard and subjective, and maybe that will bite GH one day. But this specific case is not anywhere near that line, the sole intent of those commits was to break others, and he admitted so himself. This is like arguing about whether the james webb telescope really is in space since we don't have a precise consensus about what altitude is considered the frontier with space.

raesene9 5y ago
I'm sure this case is clear, my point was around the wider principal that by going down this line GH set themselves up as arbiter of "malice" To take a trickier example, say a GH user has a lib, then decides to re-architect it, breaks the API and for their own purposes pushes it to an existing version, breaking all other use of it. Now that's a nasty thing to do, but is it malice? Another, real-world, example is I know of a user who publishes "honey PoCs" for security issues, where the repo. appears to be a exploit code but actually isn't. He's been accused of malice in doing this, but his intent is research for a talk on how people use code blindly without testing. Is that malice, should GH take his account down? By stepping into this area GH are going to have to find answers to this and also the problem of who maintains the repos of accounts they nuke?
- sailingparrot 5y ago
  > By stepping into this area GH are going to have to find answers to this a I think they already have, those 2 examples you mentioned already happened and were dealt with. I think intent is important to take into consideration, since after all that is the definition of malicious: intent to cause harm. Your first example clearly has no intent to cause harm. That case probably happened thousands of time already since not everyone is willing/able to follow semver cleanly and strictly. Never heard about GH taking any measure against that. And I would definitely not expect them to as a user/maintainer. For the second case, I think GH policy is that you can host that kind of PoCs, but the repo has to be clearly documented as doing such (e.g. you can't just add some vuln into some unrelated code "for research"), and the vulnerability cannot be an active one: "We understand that the publication and distribution of proof of concept exploit code has educational and research value to the security community, and our goal is to balance that benefit with keeping the broader ecosystem safe. In accordance with our Acceptable Use Policies, GitHub disabled the gist following reports that it contains proof of concept code for a recently disclosed vulnerability that is being actively exploited." - GitHub." [1] Back to Marak's case, my opinion is that GH did the right thing: If he just had his code in a repo, with no semver, no other contributors/maintainers, and such, and decides to nuke it, then I hope GH would not have done anything. But when you are using all the tools and trust of open source: Other people contributing to your repo, other people being active maintainers/admins and spending times out of their days to fix bugs on it, when you leverage NPM to make it easier for you to distribute your package to others widly etc, you give up the privilege being able to act unilaterally like an asshole without consequences. [1]: https://www.bleepingcomputer.com/news/security/githubs-new-policies-allow-removal-of-poc-exploits-used-in-attacks/ https://www.bleepingcomputer.com/news/security/githubs-new-p...

viro 5y ago

That's not what happened here. Author intentionally pushed malware.

kzrdude 5y ago

With great power comes great responsibility. Having a much-depended on package is a great responsibility.