OMG, am dying!!!
Someone used the bug GitHub refused to fix, that allows you to add a commit to a repo you don’t control... to upload YouTube-dl to the DMCA request repo on GitHub.
@thegibson That is just amazingly hilarious.
*immediately mirrors to git.aardwolf.social*
@thegibson truly one for the ages.
@thegibson do you have a link to any info on the bug itself? Very curious what's that about.
@rysiek I do not, there is a user on hellbird that did this referencing it. I have no knowledge of the reported vuln.
@mr64bit @thegibson yup, also found it: https://twitter.com/lrvick/status/1320250534004203521
This is comedy gold.
@rysiek you sir, are disturbingly devious!
@thegibson now why on Earth would you say that.
@rysiek Perhaps I misread your intent... but perhaps not. :)
@TheGibson wow, this is just... beautiful :)
@thegibson This is the funniest thing I've seen all week, and it's still monday!
@thegibson hahah priceless
It's a cute trick, but this is not a " bug that GitHub refuses to fix" -- it's how git forks work fundamentally. The alternative is to either deep-copy each repo on fork, or to calculate reachability on each direct object request. Both options extremely expensive.
Because it creates a culture of weak authorization in ever project, and lets people do things like upload Youtube-dl to a repo that isn't theirs?
I mean ultimately we can record it as a feature if you want, but what if someone decided to just start pumping multiple TB of randomized data into a downstream project?
At the very least his reduces github's ability to meet compliance standards, and is a problem for them....
But as we can see right here, it can be very effectively, and practically abused.
I mean I see models of failure due to this lack of downstream control for the maintainer of the attacked repo.
but this hasn't "uploaded Youtube-dl to a repo that isn't theirs," though. If you clone the DMCA repo, you won't find these objects there, because they aren't part of it. This merely allows someone to view objects via arbitrary web paths. It's confusing -- and can be amusing (https://github.com/torvalds/linux/blob/b4061a10fc29010a610ff2b5b20160d7335e69bf/drivers/hid/hid-samsung.c#L113-L118), but it's not really different than using debugfs to show arbitrary inode contents regardless of where you are in the actual FS tree.
I agree that it would be best if objects not belonging to that specific tree would return a 404, but until git learns to do this cheaply, this is not feasible for projects like github (or git.kernel.org, for that matter) to do, as this would invite a way to do a very simple and efficient DoS via requesting a bunch of arbitrary object paths and forcing the server end to run a bunch of expensive reachability calculations.
Well, git protocol doesn't solve this either, it merely refuses to serve you a direct object request unless it's associated with a ref (tag/branch). You can allow requesting only reachable objects via uploadpack.allowReachableSHA1InWant, but even the manpage sternly warns you that it's expensive and doesn't quite solve the problem anyway (https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackallowReachableSHA1InWant).
@monsieuricon @thegibson @notclacke Oh, cool, the DT Overlay configfs interface has been accepted in Linus' tree ;-)
Right, kernel.org is susceptible, too..
@geert This is how we only need 18G for all of git.kernel.org instead of 300G. :)
A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.