Any idea of when the npm package will update? 👀

A maintainer have to release the projet to NPM. I'm not sure if I've the right to do that.
EDIT: I don't

@OrKoN

We are stuck on an old version of Puppeteer - which is also affected by that tight pin to 2.6.1 - because of a bug, evidently in Chrome, that affects the use of IO.StreamHandle with specific read sizes when generating PDFs:

#7757

There's a deep dive there, along with a straightforward fix for the issue:

#7868

However, this ticket has not yet been seen by any Puppeteer devs. As this is actually a pretty severe issue when it's encountered, attention to this would be appreciated (and would allow those of us affected to properly upgrade Puppeteer to the more secure, current version).

Can we also patch the other major versions?
As per https://github.com/puppeteer/puppeteer/blob/main/docs/api.md that means:

• 11.0.0 to 11.0.1 as the last one supporting v93 chromium.
• 12.0.1 to 12.0.2 as the last one supporting v97 chromium.

In my use case, we are running the v93 version of chromium as it is available on latest alpine.

13.1.2 has just been released https://github.com/puppeteer/puppeteer/releases/tag/v13.1.2

I don't think we support back-merges in Puppeteer as we don't keep branches for releases? Also, you should try to use the latest version of Chromium since there are probably security fixes included. cc @mathiasbynens

Indeed, we don’t actively support older versions. Always use the latest possible version. (Perhaps we should more aggressively npm deprecate Puppeteer releases that bundle an outdated Chromium binary.)

The issue is that latest chromium installation on latest alpine is v93: https://pkgs.alpinelinux.org/packages?name=chromium&branch=v3.15 so I'm not sure if I would call it "outdated" 😄.
Of course, the automatically downloaded chromium won't work as it's compiled with glibc and not musl that is used in alpine.
Even in the unstable edge, the latest is v97: https://pkgs.alpinelinux.org/packages?name=chromium&branch=edge and not v98 that is now used in latest release.
Do you have a proposal how we should go forward with this? Creating the branch from the tags is is simple and I don't see this as a blocker if we want to go this way.

drealecs@ would it be an option for you to use npm-force-resolutions or similar to patch the vulnerable package?

drealecs@ would it be an option for you to use npm-force-resolutions or similar to patch the vulnerable package?

Yes, it would be an option but I think my use case is broader and it would only fix my project so it's not in the spirit of open-source collaboration.
@OrKoN, my first option would be to have a security release for older major versions, the 2 mentioned.
Other than the branches and the cherry-picks, would this involve other major work? Is there anyway I can help with some of it?

For that to work, we need to update the documentation, set up GitHub actions for releasing and testing from the branches and test all of those processes. Ideally, automate most of it. @mathiasbynens WDYT? I don't think we can handle it right now but maybe we can have it on a roadmap in near/mid future.

Thanks for the update! Sounds like a longer timeline target for update than what I would need now but it would be good to have it, whenever there is time for it.

Just leaving a note here for future developers encountering this:
I ended up using the new npm 8.3 overrides feature: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides and in term of changes that means adding to package.json:

  "overrides": {
    "puppeteer": {
      "node-fetch@2.6.5": "2.6.7"
    }
  },