CHANGELOG.md missing entries
hardillb opened this issue · comments
Is there a reason the CHANGELOG.md is missing entries for 6.1.14, 6.1.15 & 6.2.1?
Especially as 6.2.1 appears to contain a fix for a now public CVE (CVE-2024-28863)
I try not to just blindly apply dependbot updates and actually look at what's in the updates it's suggesting, but stealth releases make that a lot harder.
Can I suggest the auto generated release notes that GitHub can create when releases are tagged if you don't want to update the CHANGELOG.md manually every time.
Thanks.
Yeah. We've also had Dependabot generate a PR to this non-existent release, so are holding off until we find out if it's legit vs a supply chain attack.
Interestingly, #312 might be an early report of that CVE bug, prior to looking at it as anything other than a bug.
These are legit publishes. The changelog will be updated shortly, with the release of v7.
Of course, you can always check this page for an authoritative, thorough, detailed, and up to date description of every change in the codebase.
The concern about this being a supply chain attack gave me a good laugh.
If a supply chain attack ever gets ahold of my packages, it's going to be a Very Big Deal, and probably require either a very advanced state actor or me being personally compromised. (Or both, I suppose. If agents show up at my door with a suitcase full of cash and a hammer, I'm choosing the cash, just fyi 😅)
Everything I publish to npm references a commit signed with my GPG key (as pretty much all of my commits are), which is secured with a password-protected hardware card and has no backup. If the card is destroyed, then I just have to make a new key (this has happened); if it's lost, then the key will be revoked as soon as I become aware of it (luckily, that's never happened, because I keep the key in a secure location). Publishes to npm are secured with a biometric MFA.
So in order to pull this off, someone would need:
- my password to GitHub (or my SSH key)
- my password to npm (or my auth token)
- my yubikey
- my laptop
- my finger
Or they just have to have me, since I already have all those things.
If they have that, then any attacker would be perfectly capable of writing a few changelog entries.
And even then, since so many of my modules (especially this one) are widely used and among the top 1000 most downloaded packages on npm, they're watched closely by services like snyk and socket. So they'd also have to ensure that any malware could escape detection for long enough that you'd install and use it. I don't see the window of opportunity being more than a few hours, to be honest. So even if I wanted to pwn you, it'd be tough to do so.
Cool. While that's nice and all, it's kind of a tough sell to expect everyone to know all that rather than just you know... checking if the project has actually announced the release.
But, all good in the end it seems. Thanks for getting it done @isaacs. 😄
Ugh, actually 6.2.1 (what dependabot made the PR for in our case) still isn't listed on the CHANGELOG page.
Is 6.2.1 just a renamed 7.0?
Of course, you can always check this page for an authoritative, thorough, detailed, and up to date description of every change in the codebase.
Note that the commit with the title 6.2.1 has "Unverified" prominently displayed next to the commit hash:
As you mention above, these changes are actually legit.
But when someone who doesn't know you is trying to work out whether this is a legit release or not, that just raises more questions. 😉
Note that the commit with the title 6.2.1 has "Unverified" prominently displayed next to the commit hash:
Oh, jeez. Well that's a somewhat amusing UX fail.
When you land a commit through GitHub's security reporting secret branch feature, it doesn't preserve the GPG signature verification.
Ya know. Like, the one time it probably actually would matter, because it's associated with a CVE. sigh
Sorry, missed this comment:
Ugh, actually 6.2.1 (what dependabot made the PR for in our case) still isn't listed on the CHANGELOG page.
Is 6.2.1 just a renamed 7.0?
I'm only doing changelog sections by minors. Bugfixes just get added to that list, since the vast majority of people will just take the latest patch version anyway.
So,
- Add support for brotli compression
- Add `maxDepth` option to prevent extraction into excessively
deep folders.The brotli landed on 6.2.0, maxDepth on 6.2.1. I guess maybe that should've really been 6.3, since maxDepth is a new options addition, but whatever, it's not a mistake that's likely to harm anyone, and hopefully I've made enough sacrifices to the gods of semver that they'll forgive me.
k, thanks for adding some clarifying info. 😄
@isaacs From the CVE description, it sounds like node-tar hasn't really been designed for handling malicious input (tar) files, and you've found a case where it needed a bit of fixing. 😄
With that in mind, perhaps someone (not me!) should look into whether it handles tar bombs ok?
Tar bombs are more an annoyance than an actual danger. There's much worse things you can get up to.
The malice you can cause with tar usually stem from shenanigans around symbolic links (especially, extracting through symlinks, and then afterwards, replacing the symlink with a normal file or directory, so the extraction covers up its bad behavior), or unicode, because [0x63, 0x61, 0x66, 0xc3, 0xa9] and [0x63, 0x61, 0x66, 0x65, 0xcc, 0x81] may both spell café, and end up referencing the same file on disk, but they're different strings in JavaScript. Not to mention case sensitivity. And the fact that windows does it's weird 8.3 shortname thing, meaning it's actually impossible to ever know what a path actually refers to, because PROGRA~1 and PROGRA~2 might refer to the same thing, or different things, and if there's two entries starting with "progra" that are both longer than 8 characters, you'll never be able to know. Almost any kind of caching you'd add to make extraction faster will open the door for these kinds of shenanigans, which is why there's so many sorts of path normalization in this lib. And the security protections actually make it violate the specification in some key ways, but safer defaults are usually good, and it's not like this can do everything tar supports anyway, since it's only able to do the cross-platform fs stuff that node provides.
The type of "bombs" that are much more interesting are gzip bombs. Which this implementation doesn't do anything with. (It just uses the gzip implementation from zlib, not sure if there's any protection there.)
I hesitate to say that this tar implementation is "secure", because really, that's not a guarantee anyone can ever reliably make. But what I can say is that it's had multiple world-class security teams bang on it and collect bug bounties.
Thanks, thought I'd check just in case. 😄