Make release for v3.5
baparham opened this issue · 65 comments
I'll start trying to put together a release of v3.5.0 (with new binaries in a v3.5 release area) with the following known "issues"
- [edit: this has since been fixed and merged in] As captured in #282 I think our binaries may not work right now with node workers. More debug necessary, but I don't think this should block releasing so we can provide the majority of users with security updates.
- ARM support is currently coming from cross compiling. We had a few testers (thanks @ospencer and @robertsLando !) try out the built binaries with no complaints, however, I have a hunch that with wider distribution we'll find some issues in this space. Again, better to enable some customers while others can remain on the older binaries, or build them themselves.
I'll keep this issue updated as we progress.
this will close #257
- Create draft release (tag: v3.5)
- merge in #284
- Test/approve/merge in vercel/pkg#1862 to support node 19 in
pkg - merge in #288 to fix #282
- kick off binary build job (running in
https://github.com/vercel/pkg-fetch/actions/runs/4446969017https://github.com/vercel/pkg-fetch/actions/runs/4541231471) - Collect and upload previous binaries and .sha256sums
- [ ] Generate a newly signed SHA list for the body of the release - build job generates draft release
- trim out unnecessary binaries where we have newer versions (e.g. 16.16.0, 14.20.0, 18.5.0, etc)
- publish and tag
v3.5GitHub release🎉 🎉 https://github.com/vercel/pkg-fetch/releases/tag/v3.5🎉 🎉 - tag main branch for npm release tag:
v3.5.0 - @robertsLando fixed #291 which is now in tag
v3.5.1 - @n0cloud fixed #292 to update expected shas and bump package.json version
🙏 - publish
pkg-fetch@3.5.2to NPM (@leerob)
Post-release
- Merge in vercel/pkg#1862 to pkg to support node 19
- Create PR bumping
pkg-fetchin vercel/pkg (this could be handled by dependabot, but we probably want it sooner than nightly) - tag and release minor version bump in
pkg - publish
pkg@5.9.0or similar version number to NPM (@leerob)
Please let me know if you spot something missing!
I know @phated @ospencer @mertushka @emahfoud at least might be interested in seeing this completed, so here's your heads up :-)
LGTM 👍🏼
Also worth noting that vercel/pkg#1862 needs to land for node 19 support in pkg.
@robertsLando and @leerob I'm not putting together a GPG signed sha list. I don't immediately see (correct me if I'm wrong!!) the value in doing so.
Considering that a person with write access to modify the binaries of a release, also therefore has permissions to modify the text of the release body, and there is no central location for the key of such a GPG key (as far as I can find) then user's have no trust in the public GPG key listed in the release in addition to the trust the give the release content itself.
I'm working instead on adding more clear SHA output data to the workflow summaries, which do not appear to be editable, and we can link back to them in the release to highlight discrepancies. The previous method of linking back to the artifacts themselves from the workflow doesn't work with the current expiration date assigned to artifacts, one cannot view the sha anymore from previous workflows.
This change, combined with the hard coded SHAs in the expected.ts file should be enough security to prevent unauthorized modification of the binary assets of a release without suitable visibility in to the changes to the expected.ts shas since this is tracked in the git SCM commits.
This means an update to the README.md file is necessary as part of this release to remove the GPG signed sha "security" and explain a bit better how we can refer back to workflows that produced binaries to view the SHAs.
An example of such a workflow summary is here: https://github.com/baparham/pkg-fetch/actions/runs/4489034925/attempts/1#summary-12188328945
@baparham Absolutely 👍🏼 Good job with that, this will also be easier to maintain
for reference to security: #169 relates to the original decision to hard code hashes.
Is there anything to speed up the release process?
#282 is merged in now, so that will get included in this release, I'm trying to get the sha tracking for the workflow suitable before we do this release though
It seems at this point, the binaries produced by https://github.com/vercel/pkg-fetch/actions/runs/4541231471 should be getting copied into a draft release today (assuming things go well) and then I can tag and make that release here in GitHub, but we'll need @leerob to push it to the NPM registry. At least users should be able to use the github release temporarily in their environments until npm get's updated. I'll follow up with @leerob via email as well to make sure this doesn't fall through the cracks.
pkg. I believe he's on the west coast, so probably only just starting his day. In the meantime, you can of course resolve your pkg-fetch dependencies to use the github tagged v3.5.0 version, which in theory should still work
KUDOS @baparham for the awesome job done here 🙏🏼
Thank you for your work @baparham .
I just tested and the release seem to have an error:
Error: Cannot find module './expected-shas.json'
Require stack:
- /build/node_modules/pkg-fetch/lib-es5/expected.js
- /build/node_modules/pkg-fetch/lib-es5/index.js
- /build/node_modules/pkg/lib-es5/index.js
- /build/node_modules/pkg/lib-es5/bin.js
I submitted a possible fix to that, seems it was not listed on package.json files. It is like the .npmignore
Thank you for your work @baparham .
I just tested and the release seem to have an error:
Error: Cannot find module './expected-shas.json' Require stack: - /build/node_modules/pkg-fetch/lib-es5/expected.js - /build/node_modules/pkg-fetch/lib-es5/index.js - /build/node_modules/pkg/lib-es5/index.js - /build/node_modules/pkg/lib-es5/bin.js
Thanks for finding this!
Hello, I just updated pkg from 5.8.0 -> 5.8.1 and it broke the binary compilation. My target is node18-macos-arm64 (m1 silicon) and I noticed that in v3.5 this target is not built.
I have this log repeated a dozen time:
prebuild-install warn install No prebuilt binaries found (target=18.15.0 runtime=node arch=arm64 libc= platform=darwin)edit:
Ok I missed the fact that it wasn't released to pkg yet! I used pnpm overrides to point to "pkg-fetch": "vercel/pkg-fetch#v3.5.2" and I can confirm that there is no prebuilt binary for node18-macos-arm64 (it's currently building from source
I'm not sure why 3.5.2 was tagged vs 3.5, but regardless, pushed up the release to npm.
Sorry maybe it was lost in my comment but is it intentional that the node18-macos-arm64 target is missing in the release? Every developer on a mac m1 will have to build it from source (I assume we are a lot
It was not lost, I'm just on vacation right now. You are correct that it was missed.
I can take a look next week when I'm back, and I'll happily review pull requests adding arm Mac cross compiling to the workflow of somebody wants to take a stab at it.
Thanks for releasing @leerob it sounds like we'll need to add some more binaries to the 3.5 release on GitHub but that should not necessarily require a new release I think.
@jgoux I've got nothing yet on how to cross compile this on Mac, any ideas?
Sorry I have no knowledge about this. How was it done for the previous versions?
@baparham Just use macos-latest runner?
Seems it's on roadmap btw: github/roadmap#528
Maybe this could be an option? https://tart.run/integrations/github-actions/
Dunno if they have any free plan btw...
About arm64 images we could ask to someone that owns a mac to build them for us and manually upload them on release.
Needed ones are:
- v19.8.1
- v18.15.0
- v16.19.1
- v14.21.3
- v12.22.11
- v10.24.1
- v8.17.0
Using this to keep track of the needed. I'm going to ask some friend with a MAC if can do some.
Command to run:
npx pkg-fetch --node-range node18.15.0 --output ./
@robertsLando I'll do v18.15.0, and try a couple more if I have the time.
The syntax is: npx pkg-fetch --node-range node18.15.0 --output ./
Yeah I made a typo in the command, thanks for that 🙏🏼
@robertsLando Here is v18.15.0: https://wormhole.app/xjnjX#Ub6s0p_DRDjOIjvpjNa8eQ
I mean, I really appreciate the idea and effort here, but don't we need something transparent and auditable to help vouch for the security of these binaries? However trustworthy I'm sure you are @jgoux I have no good way to verify the authenticity of a binary built by you that is outside the normal github actions (or other mainstream CI provider's) flow
Thought about that but I don't see any other quick alternative right now. Dunno if there is known docker way using qemu for that
We may add a disclaimer regarding those binaries...
I mean, I really appreciate the idea and effort here, but don't we need something transparent and auditable to help vouch for the security of these binaries? However trustworthy I'm sure you are @jgoux I have no good way to verify the authenticity of a binary built by you that is outside the normal github actions (or other mainstream CI provider's) flow
I totally understand!
This person seems to use https://cirrus-ci.org/ in combination to GitHub to support M1: actions/runner#805 (comment)
Maybe worth exploring?
edit: nevermind it's only for self-hosted runners
edit again (xD): maybe it could work with https://github.com/apps/cirrus-runners ?
I'll stop posting other binaries if that's not a viable option.
edit again (xD): maybe it could work with github.com/apps/cirrus-runners ?
I also checked that but seems they don't have open source (free) plans
edit again (xD): maybe it could work with github.com/apps/cirrus-runners ?
I also checked that but seems they don't have open source alternatives
If there is no free solution, can't Vercel afford the cost?
If there is no free solution, can't Vercel afford the cost? sweat_smile
Asked for this a while ago but seems Vercel has no interest in this project, the only person in vercel that help us is @leerob that makes the releases when needed
@baparham could we build a universal binary? Apple claims they can be built via x86
How can we speed up the last three steps?
@baparham could we build a universal binary? Apple claims they can be built via x86
this is probably the best, but I'm not sure how to translate apple's how-to-guide to node.js. Anyone able to find anything from Node about building a universal binary?
this comment nodejs/build#2474 (comment) and nodejs/build#2474 (comment) seems promising for cross compiling, maybe an option could be to selectively apply some of the mentioned patches to the https://github.com/nodejs/node/blob/main/tools/gyp/pylib/gyp/xcode_emulation.py file and then a different ./configure parameter before building. I'm unable to test this hypothesis out right now, so anyone please (please) feel free to take a shot at it. Presumably you can kick off a custom debug workflow in your own fork to test cross compiling for arm on a regular github hosted x86-64 mac runner, and then link to the artifact for someone with apple silicon to try the binary out?
I also thought about the fat universal binary some more and I see no value to it if we still have to do the work to cross compile the arm version anyway, we just omit the final step of mangling the platform binaries together and we still should have two viable binaries, which seem to fit with our binary delivery pattern anyway.
@baparham could we build a universal binary? Apple claims they can be built via x86
not sure if that's what you had in mind: if you have an x86 build and an arm build you can merge it into a universal binary: lipo x86Build armBuild -create -output universalBuild