chore: upgrade 7zip binaries to v24.09 and add documentation

[ollm]

This pull request its based on the #27 of @mmaietta, so it also includes its changes.

Updating to the latest binaries fixes some vulnerabilities in the current binaries and homogenizing all the binaries to the same version with the same features, functions and performance improvements.

Fixes: #21, #22, #26 and probably some more.

Pull rquest changes

Updated all bianries to v24.09 from official release on GitHub: https://github.com/ip7z/7zip/releases

All binaries are now full feature versions #27 (comment)

• Win: 7z.exe and 7z.dll are extracted from windows installer
• Mac: 7zz are extracted from tar.xz
• Linux: 7zz and 7zzs are extracted from tar.xz

Changed package version to match 7zip version, this way it is easier to know which version 7zip-bin is using: package.json

Export a new path7zzs to use 7zzs binarie in Linux: index.js

Add package documentation usage in README.md

Add auto update script to easy update all bianries from official release on GitHub: update.js

Binaries status

Platform	Binary	Version	Tested
Windows x64	7z.exe and 7z.dll	24.09	Yes
Windows ia32 (x86)	7z.exe and 7z.dll	24.09
Windows arm64	7z.exe and 7z.dll	24.09
Windows arm	7z.exe and 7z.dll	24.09
Mac x64	7zz	24.09	Yes
Mac arm64	7zz	24.09
Linux x64	7zz and 7zzs	24.09	Yes (Both)
Linux ia32 (x86)	7zz and 7zzs	24.09
Linux arm64	7zz and 7zzs	24.09
Linux arm	7zz and 7zzs	24.09

I've only been able to test the x64 binaries, as I don't have any devices with other architecture.

If anyone wants to try it an test, they can install it from my fork.

npm install github:ollm/7zip-bin

Please let me know if the pull request needs any changes.

[mmaietta]

This is absolutely brilliant, thank you!

Could you split out your auto-update script into a separate PR?

I'd like to leverage it with some CI/CD automation for download/committing directly to the repo during CI/CD and utilize Github's attestation feature to secure binaries coming from this repo. Then I can add a deployment CD job for publishing to npm.

Context: I'm now very adverse to adding binaries directly to repo's from user's local machines, especially in light of a recent supply chain vulnerability that happened with changeset-files GHA. Instead, I propose we take the same route as to what I'm implementing in electron-builder-binaries that commits+publishes these binaries only during a release pipeline

[ollm]

Thanks for your reply!

Could you split out your auto-update script into a separate PR?

I have removed the auto-update script in this pull request #5c5fbb2 and opened a separate one #29

I'd like to leverage it with some CI/CD automation for download/committing directly to the repo during CI/CD and utilize Github's attestation feature to secure binaries coming from this repo. Then I can add a deployment CD job for publishing to npm.

I think it's a great idea, I'm not very familiar with GitHub automation/actions, so if anything needs to be changed, let me know.

[mmaietta]

Your other PR looks solid, I can merge it once it's in Ready For Review state

Re: the GHA CI/CD, it'll look something like these:
https://github.com/mmaietta/electron-builder-binaries/blob/master/.github/workflows/release.yaml
https://github.com/mmaietta/electron-builder-binaries/blob/master/scripts/changeset-version.js
https://github.com/mmaietta/electron-builder-binaries/blob/master/scripts/changeset-publish.js

If you're willing to give it a shot, happy to provide pointers! Otherwise just let me know and I can add this to my lengthy to-do list 😅

The gist of it is:

• Changesets/CLI is used for generating release notes and triggering a Release action with the attestation logic.
• Only the Release action is allowed to download/build/compile and commit binaries to this repo (commits will always be signed by github-action[bot])
• On release, the binaries are "attested" by github, a GH release version created with attested binaries attached. (part missing from the linked scripts is the npm publish, but we can copy that code from electron-builder)

https://github.com/electron-userland/electron-builder/blob/b87b158c12d3a096e8e7b4883438a277633ca3c7/.github/workflows/pr-release.yml#L30-L45

With Changesets/CLI automation, release PRs look like this mmaietta/electron-builder-binaries#39 and automate the binary generation+commit+release

[ollm]

Thanks! I'm happy to give it a shot. I'll take a look at the examples you shared, and if I have any questions along the way, I’ll be sure to reach out.

[ollm]

Hi @mmaietta.

I've made some progress with the GitHub action, although I have some issues/questions.

• Versioning: Changesets generates its own version numbers for the package. Is there a way to override this so the package version matches the 7z binary version? I also use the 7zip-bin version to abort the action if it is the same as the latest 7z version update-binaries.js#L186-L199
• Publishing to npm: I haven’t added logic to automatically publish to npm yet. This should be handled by a separate action that runs after the github-actions pull request is merged, right?

Let me know if I missed anything or need to make changes.

Progress so far:

• Action: update-binaries.yaml
• Update script: update-binaries.js
• Pull request generated: chore: upgrade 7zip binaries to v24.09 ollm/7zip-bin#9

GitHub actions runs:

• First run: (Open the pull request): update-binaries
• Second run: (Aborted due a existent pull request with the same 7z version): update-binaries, update-binaries.js#L201-L237

[ollm]

Hi @mmaietta.

I've finished implementing automatic updates and publishing to npm. For now, I've done it in a separate repository (ollm/7zip-bin-full) to test the npm publishing. If everything looks good to you, I'll send a new pull request with the new changes.

I switched from changesets to peter-evans/create-pull-request to handle pull request creation, which now allows me to use the same package version as the 7zip version.

Update binaries

Script: update-binaries.js
Workflow: update-binaries.yaml
Run 1: Update 7zip binaries
Run 2: Update 7zip binaries
Pull request generated: ollm/7zip-bin-full#2
Generated README.md: https://github.com/ollm/7zip-bin-full/blob/main/README.md
Generated CHANGELOG.md: https://github.com/ollm/7zip-bin-full/blob/main/CHANGELOG.md

Publish to npm

Workflow: publish.yml
Run: Publish Package

Npm package

Package: 7zip-bin-full
Npm Provenance: Provenance

[gengjiawen]

@mmaietta Can you take another look ?

[mmaietta]

Holy moly, your linked changes (workflow/script/all of it), it looks great.

which now allows me to use the same package version as the 7zip version.

My one nit pick is regarding package versioning. I personally think we should retain the previous versioning system with a VERSION.txt in the repo representing the version of the package. Ideally, the package structure would look akin to

• vendor
  |- linux
  |- mac
  |- win
  |- VERSION.txt
• package.json
• 7x.sh
• other root/entry files

What are your thoughts?

[ollm]

Hi @mmaietta.

My one nit pick is regarding package versioning. I personally think we should retain the previous versioning system with a VERSION.txt in the repo representing the version of the package. Ideally, the package structure would look akin to

I would prefer to align the package version with the 7zip version, if possible. Since this package only distributes the 7zip binaries and does not provide its own API, so I don't think maintaining a separate versioning scheme adds much value, it mainly makes it harder to identify the actual 7zip version. While using independent version numbers may have made sense in the past when there were multiple 7zip versions, I don't think that's necessary anymore.

The version number is also used for checks, such as aborting when the package version matches the 7zip version update-binaries.js#L190-L203, or when validating existing pull requests update-binaries.js#L205-L241.

If you feel the current versioning system is more appropriate, I can make the necessary changes to switch to it.

Regarding VERSION.txt, the CHANGELOG.md already lists the 7zip version number along with the related binary changes, and the README.md shows the current version, so I don't think an additional file is necessary.

[mmaietta]

The use cases I'm thinking of are for when:

• this package needs to do a new semver release (such as due to incorrect file permissions post-upload to npm) without updating 7zip binaries
• index.js or package.json or other npm-related file need to be changed and published with updated logic w/o 7zip binary update

[ollm]

I think in these cases it's fine to increase the patch number, since 7zip uses year.count as its versioning scheme and the patch slot remains free. For example, for 7zip 24.09 we could use 24.9.1 for a patch release. That's how I handled it in the npm test package I published, which is currently at version 25.1.1 (7zip-bin-full).

Looking at the commit history of 7zip-bin, most of the major version bumps happened when the binaries were updated, for example: f1b28a1, 9f96623, f622093, and d8bcecb. So in practice, there wouldn't really be any difference if the versions were aligned with 7zip.

The only potential issue I can see is if a major change is required in the repository, but I don't think that's likely. And in that case, we could just wait for the next 7zip release before publishing it.

[mmaietta]

Sounds good to me. Will you be opening a new PR with the workflow changes?

[ollm]

I've opened the new pull request (#30) that includes three commits: the first adds the necessary changes for automatic updates via GitHub Actions, the second adds an updated 7zz binary for Linux to be used in the action, and the last one removes the old binaries and adds placeholder (empty) binaries that will be replaced when the GitHub Action runs.

Commits:

• feat: script and action to auto-update binaries from the official 7zip GitHub 77fb8e7
• feat: add 7zz 25.01 Linux binary for use in GitHub Action a61502c
• feat: replace existing 7za binaries with empty files to keep folders in git 37095f8

[gurunathg]

Upgrade to 25.01 is necessary as versions < 25.0 have vulnerabilities associated with them https://www.zerodayinitiative.com/advisories/ZDI-25-950/ and https://www.zerodayinitiative.com/advisories/ZDI-25-949/

[mmaietta]

Hi folks, so with the changes to NPM publishing and related tokens, I'm not able to push out updates to this npm package anymore. Only @develar can enable that publishing connection.

What I CAN do though is serve these binaries out of electron-builder-binaries monorepo. You might be able to directly npm install since it has a package.json, maybe? I haven't tried an approach like that before, but I did find this:
https://zfir.medium.com/installing-a-dependency-from-a-monorepo-easily-6b810c0189f8

I have full admin rights on the artifacts generated through the pipelines on that repo.
https://github.com/electron-userland/electron-builder-binaries/tree/master/packages
https://github.com/electron-userland/electron-builder-binaries/releases

[ollm]

Hi @mmaietta, I'm currently using my fork in my project (ollm/7zip-bin-full), which can be installed directly from npm (7zip-bin-full).

For now, I'm committed to maintaining it until @develar updates this repository, in case anyone else wants to use it.