Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cooldown Support for Ruby Bundler

blog.rubygems.org

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Cooldown Support for Ruby Bundler

#21

Post by shevy-java »

Meanwhile ruby is dropping ranks.

How active is rubygems.org itself? I retired when the 100k download threshold was installed onto developers there; on github I don't have any such restriction pertaining to code I publish and maintain. But even before that restriction, numerous gems were abandoned. I understand that this is a natural cycle anyway, but without an influx of new developers, ruby will fossilize and age out just as perl did before.

None of those "cooldowns" will bring in new developers either. It all seems to be about meta-appeasing companies; this could indirectly help, but I doubt it will help much.

Re: Cooldown Support for Ruby Bundler

#22

Post by weaksauce »

teeray wrote: post #19
embedding-shape wrote: post #17

Earlier quoted context omitted.

> It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be. Except there is lots to gain from being the first to write about the new malware on some registry, so companies are actively downloading and inspecting literally every package. Back in the day (maybe 6-7 years ago?) you could detect this by uploading a new npm package that hit back some endpo…

> Except there is lots to gain from being the first to write about the new malware on some registry Show me the company writing to their customers “we intentionally decided to ship code with potentially novel vulnerabilities. One of those vulnerabilities caused disclosure of your data, but cheer up! We have this cool security blog post about it now.” Meanwhile their competitors freeride and their customers’ data is s…

security researchers not the ones shipping the faulty code.

Re: Cooldown Support for Ruby Bundler

#23

Post by teeray »

weaksauce wrote: post #22
teeray wrote: post #19

Earlier quoted context omitted.

> Except there is lots to gain from being the first to write about the new malware on some registry Show me the company writing to their customers “we intentionally decided to ship code with potentially novel vulnerabilities. One of those vulnerabilities caused disclosure of your data, but cheer up! We have this cool security blog post about it now.” Meanwhile their competitors freeride and their customers’ data is s…

security researchers not the ones shipping the faulty code.

We’re not talking about security researchers here:

> there is lots to gain from being the first to write about the new malware on some registry, so *companies* are actively downloading and inspecting literally every package.

(Emphasis mine)

Re: Cooldown Support for Ruby Bundler

#24

Post by x0x0 »

password4321 wrote: post #6
swader999 wrote: post #4

Aren't we back to the drawing board once everyone uses this?

The point is to allow the automated scanners a chance to run. Every security company and their cousin wants to be the one to find the next big dependency malware.

The idea that a package can be updated and with a deploy at the right time could be live on your servers in prod 10 minutes later has always been crazy, and the last years have just reinforced that.

People are encouraged by package managers to treat any bit of code someone tosses onto a package manager as equivalent in reliability to the core language and sdk.

Re: Cooldown Support for Ruby Bundler

#25

Post by ashishb »

Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates.

So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread.

Even for single page website built using Vue, I would get about 5 updates a week.

Re: Cooldown Support for Ruby Bundler

#26

Post by weinzierl »

grncdr wrote: post #7
swader999 wrote: post #4

Aren't we back to the drawing board once everyone uses this?

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release?

You need an early release in the "given enough eyeballs all bugs are shallow" world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

Re: Cooldown Support for Ruby Bundler

#27

Post by k3nx »

trevor-e wrote: post #13
doctorpangloss wrote: post #12

you have 1.0 installed. you enable 7 day cooldowns. an exploit is discovered in 1.0, and 1.1 is immediately released to fix the exploit. do you sit on 1.0 for 7 days?

it specifically addresses this in the "The escape hatch" section...

So, the threat actor now, after making the compromise, just needs to announce that the previous version has a 0-day, and folks need to install the latest version? I love the idea of a cool down, but it can still be thwarted. I would just hope folks that are trying to patch a 0-day take extra caution to vet the new version. I wouldn't be opposed to a --cooldown 0 doing a side by side diff. I may not know what's going on in the code, but a 0-day shouldn't be a ton of new code either.

Re: Cooldown Support for Ruby Bundler

#28

Post by john_strinlai »

weinzierl wrote: post #26
grncdr wrote: post #7

Earlier quoted context omitted.

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release? You need an early release in the "given enough eyeballs all bugs are shallow " world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

i am not sure what the benefits of your proposal are compared to the "cooldown period" way.

the releases will be delayed for the same time period, but you increase the amount of coordination required significantly and reduce user agency.

Re: Cooldown Support for Ruby Bundler

#29

Post by scheme271 »

teeray wrote: post #19
embedding-shape wrote: post #17

Earlier quoted context omitted.

> It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be. Except there is lots to gain from being the first to write about the new malware on some registry, so companies are actively downloading and inspecting literally every package. Back in the day (maybe 6-7 years ago?) you could detect this by uploading a new npm package that hit back some endpo…

> Except there is lots to gain from being the first to write about the new malware on some registry Show me the company writing to their customers “we intentionally decided to ship code with potentially novel vulnerabilities. One of those vulnerabilities caused disclosure of your data, but cheer up! We have this cool security blog post about it now.” Meanwhile their competitors freeride and their customers’ data is s…

I think it's more some security company writing about a vulnerability they discovered in this module or a worm/backdoor and not the company that wrote the software. The security company gets publicity and potentially gets more biz for security consulting.

Re: Cooldown Support for Ruby Bundler

#30

Post by john_strinlai »

teeray wrote: post #23
weaksauce wrote: post #22

Earlier quoted context omitted.

security researchers not the ones shipping the faulty code.

We’re not talking about security researchers here: > there is lots to gain from being the first to write about the new malware on some registry, so *companies* are actively downloading and inspecting literally every package. (Emphasis mine)

>We’re not talking about security researchers here:

we are.

"companies" in this context is "security companies" (hence why they are "downloading and inspecting every package", which would not make sense if referring to the people authoring and shipping a single package)

Post reply on HN