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

Turn Dependabot off

words.filippo.io

Post reply on HN
Print view View original

181–190 of 195 posts

Re: Turn Dependabot off

#181

Post by gopher_space »

Chris_Newton wrote: post #142
varispeed wrote: post #118

Earlier quoted context omitted.

Bumping version of dependencies doesn't guarantee any improved safety as new versions can introduce security issues (otherwise we wouldn't have a need of patching old versions that used to be new).

If you replace a dependency that has a known vulnerability with a different dependency that does not, surely that is objectively an improvement in at least that specific respect? Of course we can’t guarantee that it didn’t introduce some other problem as well, but not fixing known problems because of hypothetical unknown problems that might or might not exist doesn’t seem like a great strategy.

I think he's referring to this part of the article:

> Dependencies should be updated according to your development cycle, not the cycle of each of your dependencies. For example you might want to update dependencies all at once when you begin a release development cycle, as opposed to when each dependency completes theirs.

and is arguing in favor of targeted updates.

It might surprise the younger crowd to see the number of Windows Updates you wouldn't have installed on a production machine, back when you made choices at that level. From this perspective Tesla's OTA firmware update scheme seems wildly irresponsible for the car owner.

Re: Turn Dependabot off

#183

Post by andrewaylett »

I approve of Renovate's distinct recommendations for libraries vs applications.

For a library, you really want the widest range of "allowed" dependencies, but for the library's test suite you want to pin specific versions. I wrote a tool[1] that helps me make sure (for the npm ecosystem) my dependency specifications aren't over-wide.

For an application, you just want pinned specific dependencies. Renovate has a nice feature wherein it'll maintain transitive dependencies, so you can avoid the trap of only upgrading when forced to by more direct dependencies.

The net result is that most version bumps for my library code only affect the test environment, so I'm happy allowing them through if the tests pass. For application code, too, my personal projects will merge version bumps and redeploy automatically -- I only need to review if something breaks. This matches the implicit behaviour I see from most teams anyway, who rely on "manual review" but only actually succeed in adding toil.

My experience is that Renovate's lock file maintenance makes update a whole load safer than the common pattern of having ancient versions of most transitive dependencies then upgrading a thread of packages depended on by a newer version of a single dependency.

1: https://www.npmjs.com/package/downgrade-build

Re: Turn Dependabot off

#184

Post by david_allison »

Chris_Newton wrote: post #113

Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability. One security checking tool that has genuinely impressed me recently is CodeQL. If you’re using GitHub, you can run this as part of GitHub Advanced Security.…

CodeQL has been disappointing with Kotlin, it lagged behind the official releases by about two months, blocking our update to Kotlin 2.3.0

https://kotlinlang.org/docs/whatsnew23.html

https://github.com/github/codeql/issues/20661

Re: Turn Dependabot off

#185

Post by estimator7292 »

DecoySalamander wrote: post #129
Twirrim wrote: post #74

Earlier quoted context omitted.

I've been fighting with an AI code review tool about similar issues. That and it can't understand that a tool that runs as the user on their laptop really doesn't need to sanitise the inputs when it's generating a command. If the user wanted to execute the command they could without having to obfuscate it sufficient to get through the tool. Nope, gotta waste everyone's time running sanitisation methods. Or just ignor…

There is a plausible scenario in which a user finds some malicious example of cli params for running your command and pasts it in the terminal. You don't have to handle this scenario, but it would be nice to.

There is a plausible scenario where a user cuts their wrist open cooking dinner. You don't have to file the edge off cooking knives, but won't you think of the children?

Re: Turn Dependabot off

#186

Post by TZubiri »

1718627440 wrote: post #148
TZubiri wrote: post #145

Earlier quoted context omitted.

Yes, it's a joke. The Free in Free Software is sold as being Free as in Freedom to devs by recruiters of the cause, however the bulk of actual consumers see Free Software as equivalent to Open Source and the defining characteristic for them is Free as in Gratis.

Honestly, that whole "free as in X" problem to me seems like an English only problem. As an ESL I perceive "free" to be the adjective to "freedom" by default and the other meaning to be a contraction of "free of charge".

Which is not a minor or trivial language, GPL was written in English, by an American developer, while working at an American company, etc... Same with GNU and FSF

Re: Turn Dependabot off

#187

Post by jpollock »

prmoustache wrote: post #153
jpollock wrote: post #52

Earlier quoted context omitted.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

If that is the mindset in your company, why even bother looking for vulnerabilities?

There is _always_ fraud, and you can't stop it all. All you can do is try to minimize the cost of the fraud.

There is an "acceptable" fraud rate from a payment processor. This explains why there are different rates for "card present" and "card not present" transactions, and why things like Apple Pay and Google Pay are popular with merchants.

Re: Turn Dependabot off

#188

Post by TeMPOraL »

jpollock wrote: post #38
staticassertion wrote: post #31

Earlier quoted context omitted.

TBH I Think that DoS needs to stop being considered a vulnerability. It's an availability concern, and availability, despite being a part of CIA, is really more of a principle for security rather than the domain of security. In practice, availability is far better categorized as an operational or engineering concern than a security concern and it does far, far more harm to categorize DoS as a security conern than it…

The severity of the DoS depends on the system being attacked, and how it is configured to behave on failure. If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly. Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shaked…

> Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

But that is what security is in the real world anyway. Once you move past the imaginary realms of crypto and secure coding that some engineers daydream in, the ultimate reality is always about "do I want to spend $X dealing with consequences of ${specific kind of atack}, or $Y on trying to prevent it" - and the answer is to consider how much $X is likely to be, and how much it'll be reduced by spending $Y, and only spending while the $Y < reduction in $X.

Re: Turn Dependabot off

#189

Post by TeMPOraL »

everforward wrote: post #157
jpollock wrote: post #52

Earlier quoted context omitted.

If the majority of your customers are good, failing closed will cost more than the fraud during the anti-fraud system's downtime.

You are really running with scissors there. If anyone with less scrupulous morals notices, you’re an outage away from being in deep, deep shit. The best case is having your credit card processing fees like quadruple, and the worst case is being in a regulated industry and having to explain to regulators why you knowingly allowed a ton of transactions with 0 due diligence.

The concept of due diligence recognizes the limits, past which it becomes too much, or undue.

Re: Turn Dependabot off

#190

Post by DecoySalamander »

estimator7292 wrote: post #185
DecoySalamander wrote: post #129

Earlier quoted context omitted.

There is a plausible scenario in which a user finds some malicious example of cli params for running your command and pasts it in the terminal. You don't have to handle this scenario, but it would be nice to.

There is a plausible scenario where a user cuts their wrist open cooking dinner. You don't have to file the edge off cooking knives, but won't you think of the children?

Kitchen knives actually do have safety features, such as non-slip handles and finger guards, which users appreciate. I certainly do. Users also appreciate safeguards in cli tools, such as not deleting all data if input happens to be slightly wrong. Sure, you could design your tool to be used exclusively by leet hackers, but the idea of sanitizing your inputs is not completely preposterous.
Post reply on HN