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

A routine gem update ended up creating $73k worth of subscriptions

serpapi.com

Post reply on HN
Print view View original

91–100 of 336 posts

Re: A routine gem update ended up creating $73k worth of subscriptions

#91

Post by forgot_old_user »

gruez wrote: post #62
seanwilson wrote: post #39

> SerpAPI: Scrape Google and other search engines from our fast, easy, and complete API. Does anyone know how this works behind the scenes at scale? How do they get around Google trying to stop their scraping attempts? Just lots of proxies and some way around captcha challenges?

probably a combination of realistic-seeming desktop browsers (eg. headless chrome with stealth patches) and residential IP providers (eg. luminati)

Their website says

>In addition, each API request runs in a full browser, and we'll even solve all CAPTCHAs. Mimicking completely what a human will do.

Wow how would they do that?

Re: A routine gem update ended up creating $73k worth of subscriptions

#92

Post by booleanbetrayal »

userbinator wrote: post #72

I wish more developers would abide by the old saying "don't fix it if it ain't broke." It's one thing to update because you know a newer version has fixed a bug you're experiencing, but if everything is already working as you'd expect, IMHO you're just asking for trouble. There's a reason a lot of the infrastructure systems that many people don't even know about --- until something breaks --- hasn't changed in litera…

You are asking for security issues if you take this approach. Better to increment on several small iterations of dependencies, making changes accordingly, such that you will be able to take a CVE-fixing patch without having to refactor your entire app all at once.

Re: A routine gem update ended up creating $73k worth of subscriptions

#93

Post by Retric »

thrwn_frthr_awy wrote: post #81
andrewxdiamond wrote: post #76

Earlier quoted context omitted.

All dependency changes are changes. And changes should be tested before being deployed. If you update your dependencies and ship it based on version numbers alone, you can’t blame the maintainers

> All dependency changes are changes. And changes should be tested before being deployed. OP did not say changes should not be tested. > If you update your dependencies and ship it based on version numbers alone, you can’t blame the maintainers OP did not if you update your dependencies and ship it based on version numbers alone you can blame the maintainers.

Shipping something with zero testing is always crazy.

Even a minor bug fix in a library can expose a critical bug in your own code.

Re: A routine gem update ended up creating $73k worth of subscriptions

#94

Post by compiler-guy »

This change gives me new respect for Denis Ritchie's decision not to mess with a wart in operator precedence in C. Even though we still live with this wart 30 years later. It was exactly this type of failure he sought to prevent.

He refused to fix it because, "After all, we had several hundred kilobytes of source code, and maybe 3 installations...."

https://www.lysator.liu.se/c/dmr-on-or.html

Re: A routine gem update ended up creating $73k worth of subscriptions

#95

Post by mchusma »

Stripe also bears some responsibility here, as they don't support production testing, so it's impossible to have a test suite checking for charge related behaviors in production. If you use stripe, please contact them and request this long overdue feature. (I do not think that is the primary issue, but it does not help)

Re: A routine gem update ended up creating $73k worth of subscriptions

#97

Post by jrochkind1 »

noneeeed wrote: post #21

We use Mongoid. I treat every upgrade, no matter how small as its own piece of work involving going through the changelogs with a fine-tooth comb. This particular issue got flagged up when we last looked at upgrading. Currently Mongoid upgrades are stalled until we have the time to figure out the impact of some of their more egregious changes. I have a generally low trust approach to all dependency upgrades, irrespec…

That sure doesn't seem to be an endorsement of mongoid.

Re: A routine gem update ended up creating $73k worth of subscriptions

#98

Post by jrochkind1 »

userbinator wrote: post #72

I wish more developers would abide by the old saying "don't fix it if it ain't broke." It's one thing to update because you know a newer version has fixed a bug you're experiencing, but if everything is already working as you'd expect, IMHO you're just asking for trouble. There's a reason a lot of the infrastructure systems that many people don't even know about --- until something breaks --- hasn't changed in litera…

The problem is the technical debt you acquire this way.

Eventually you're going to need to upgrade X for a security fix, but the new version of X isn't compatible with the version of Y you are using, and upgrading that would break Z, and Z would break your app here and here. Now you're spending a couple weeks trying to do the upgrade to get a security fix that was 0 day two weeks ago, when you should have been writing things that actually advanced your app instead.

I keep my dependencies up to date, and consider it technical debt when they are not, and would never want to go back.

Re: A routine gem update ended up creating $73k worth of subscriptions

#100

Post by mickotron »

mchusma wrote: post #95

Stripe also bears some responsibility here, as they don't support production testing, so it's impossible to have a test suite checking for charge related behaviors in production. If you use stripe, please contact them and request this long overdue feature. (I do not think that is the primary issue, but it does not help)

Why not test with a stub? Issue would have been picked up in testing even without Stripe integration.
Post reply on HN