Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

891–894 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#891

Earlier quoted context omitted.

If you say "wait 1 day without using a calendar+locale" then the duration is unambiguously 86400s, but if you say "wait 1 day using a calendar+locale" or "wait until this time tomorrow" then the duration is ambiguous until you've incorporated rules like leap/DST. I think GP's point is that "wait 1 day" unambiguously defaults to the former, and you disagree, but perhaps it's a reasonable default.

Yep, this is exactly my point. Durations are abstract spans of "stopwatch time," they don't adhere to local times or anything else we use as humans to make time more useful to us. In that context there's no real ambiguity to using units like hours/days/weeks (but not months, etc.) because they have unambiguous durations.

Now you've got me wondering something: if a "stopwatch month" can't exist since everyone agrees that different months have different durations (and therefore you must select one like "the month of January" to know how long to run the stopwatch), isn't there an argument that a "stopwatch year" has the same need to select one since everyone agrees that different years have different day counts (unless we mean a solar year in seconds, not quantized to the nearest day, but that's probably a Bad Default)?

The collective human decision to make days-per-year vary (requiring leap rules to calculate days) seems similar to the collective human decision to make days-per-month vary (requiring month names to calculate days). So if we say a "stopwatch year" suffers the same fate as the "stopwatch month" then it's a slippery slope to saying the "stopwatch minute" is no different than a "stopwatch year" (requiring leap rules to calculate seconds) even if, for all practical purposes, it seems exempt.

I guess this is why we make "second" the SI unit, and none of our human-convenience rules mess with the duration of a second. A leap second changes the duration of a minute (and above), and a leap year changes the duration of a month (and above). Which, oddly enough, demonstrates an inconsistency: we ought to say "leap day" instead of "leap year" if the thing being added will follow the word "leap."

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#892
post #52

Supply chain attacks are so scary that I think most companies are going to use agents to hard fork their own versions of a lot of these core libraries instead. It wasn’t practical before. It’s definitely much more doable today.

Once you fork it, you are then on the hook for forking every future update and security patch. You can automate a lot of the testing, but its still adding an extra failure point that you are now responsible for.

And if you pin it, then when you inevitably get a CVE for an old version, the upgrade path is harder and more time consuming. And that's when the security teams come knocking to pass their audit.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#893
post #626
post #220

Earlier quoted context omitted.

> Workdays! This is java script , not Java. In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what…

There's an extra digit in your timestamp.

Ah but you don't know how far in the future I intended it to be :)

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#894
post #809

Earlier quoted context omitted.

The point is that you don't need the very latest version. The 20 years old version is enough.

XPath 1.0 is a pain to write queries for. XPath 2.0 adds features that make it easier to write queries. XPath 3.1 adds support for maps, arrays, and JSON. And the default Python XPath support is severely limited, not even a full 1.0 implementation. You can't use the Python XPath support to do things like `element[contains(@attribute, 'value')]` so you need to include an external library to implement XPath.

The problem of XPath 3.1 is that it is very complex [1] - this is a long page. Compared to the 1.0 spec, it is just too complex in my view. For the open source project I'm working on, I never felt that the "old" XPath version is painful.

I think simplicity is better. That's why Json is used nowadays, and XML is not.

[1] https://www.w3.org/TR/xpath-31/ [2] https://jackrabbit.apache.org/oak/docs/query/grammar-xpath.h...

Post reply on HN