Pyoxidizer

Latest version: v0.24.0

Safety actively analyzes 688568 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 4

0.17

Release notes at https://pyoxidizer.readthedocs.io/en/pyoxidizer-0.17/pyoxidizer_history.html#version-0-17-0

0.17.0

**The apple-codesign project has moved to https://github.com/indygreg/apple-platform-rs. This is the final release to be published from the PyOxidizer repository. All future releases can be found at https://github.com/indygreg/apple-platform-rs/releases.**

Release Info

* [Documentation](https://gregoryszorc.com/docs/apple-codesign/0.17.0/)
* [Known issues and limitations](https://gregoryszorc.com/docs/apple-codesign/0.17.0/apple_codesign_quirks.html)
* [Debugging and bug filing instructions](https://gregoryszorc.com/docs/apple-codesign/0.17.0/apple_codesign_debugging.html)

Changelog

* **Major feature**: Notarization is now implemented in Rust and no longer
requires Apple's *Transporter* application. Going forward, you only need
the ``rcodesign`` executable (or this crate embedded as a library) and an
App Store Connect API Key to notarize. Major thanks to Robin Lambertz
(roblabla) for contributing the bulk of the implementation in 593.
* As a result of native notarization, integration with Apple's *Transporter*
has been removed. The ``find-transporter`` command has been removed. Rust
APIs related to Transporter, the *app metadata* XML format it used, and App
Store Connect APIs previously used have been removed.
* As a result of native notarization, UI and implementation details of
notarization have changed. The output when uploading assets is much more
concise. Before, code existed to normalize uploaded assets to a data format
required by Transporter. As a side-effect, assets were somewhat validated
locally before upload. In the new world, minimal checks are performed locally.
This can result in errors (such as attempting to upload an asset without a
code signature) occurring later than they did previously.
* A new ``encode-app-store-connect-api-key`` command can be used to encode an
App Store Connect API Key in a single JSON object. These keys are used for
notarization and having all the API Key metadata in a single file / JSON
blob means you have 1 entity to define your App Store Connect API Key instead
of 3, making UI simpler.
* The ``notarize`` command has been renamed to ``notary-submit``. This follows
the terminology of Apple's ``notarytool`` and mimics the nomenclature used
by the Notary API. The old ``notarize`` command is an alias to
``notary-submit``.
* The ``notary-submit`` command now has an ``--api-key-path`` argument defining the
path to a JSON file containing the unified App Store Connect API Key emitted
by the ``encode-app-store-connect-api-key`` command. We recommend using this
method for specifying the API Key going forward, as it is simpler. The old
method was required for use with Apple's Transporter application, which we
no longer use so we're no longer bound by its requirements. The old method
will likely be dropped from a future release.
* A new ``notary-wait`` command can be used to wait on a previous notary
submission to complete and to view its log info. This command can be useful if
``notary-submit`` times out or otherwise fails and you want to query the
status of a previous notarization.
* A new ``notary-log`` command will fetch the notarization log of a previous
submission from the Notary API server.
* Fixed signing of Mach-O binaries having a gap between segments. (This is known
to commonly occur in Go binaries.) In previous versions, we would compute
digests of the file incorrectly and would encounter an assertion when copying
Mach-O data to the output binary. Both of these issues should now be fixed.
(588 and 616)
* minicbor crate upgraded from version 0.15. This created API differences in
remote signing code.
* The APIs around Mach-O file parsing have been significantly overhauled. It
is probably best to diff the ``macho`` module to see the full differences.
There are now ``MachFile`` and ``MachOBinary`` types serving as interfaces
to custom Mach-O functionality. Most code interfacing with a Mach-O file now
uses these types. The ``AppleSignable`` trait has been deleted as it is no
longer needed since we have the dedicated ``MachOBinary`` type.

0.16.0

See the release notes at https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_history.html#version-0-16-0

The Python wheels have a `0.16.2` version component because the initial build of the `0.16.0` and `0.16.1` macOS wheels was buggy due to the `pyoxidizer` file not being executable and therefore not being installed by `pip`. There were no functional changes between `0.16.0` and `0.16.2`.

0.15.0

See release notes at https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_history.html#version-0-15-0.

0.14.1

See release notes at https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_history.html#version-history.

Release artifacts/installers coming shortly.

0.14.0

This is the first GitHub release for apple-codesign / `rcodesign` with pre-built executables!

The macOS binary is self-signed using the new *remote signing* feature. The signing was initiated on GitHub Actions (https://github.com/indygreg/PyOxidizer/runs/6152561538?check_suite_focus=true) and signing was performed from the maintainer's Windows machine using a YubiKey.

The permalink for documentation for this release is https://pyoxidizer.readthedocs.io/en/apple-codesign-0.14.0/apple_codesign.html

* Fixed a bug where symlinks weren't been written in notarization zip file
files properly. This prevented bundles containing symlinks from notarizing
correctly.
* The filename used in notarization uploads is now normalized to avoid
rejection due to spaces and colons.
* Support for remote signing. The feature is documented extensively in the
Sphinx documentation. Essentially, 2 independent machines communicate with
each other with end-to-end encrypted messages via a websocket bridged through
a central server. Signing requests are sent to a remote machine which is in
possession of the signing key. Signatures are made on the remote machine and
transmitted back to the originating machine. Remote signing enables signing
to be performed more securely by facilitating signing without having to give
the initiating machine access to the signing key.
* Default log output format has changed. Lines are no longer prefixed with the
time, log level, or logging module by default. A ``-v/--verbose`` global flag
has been added to increase the verbosity of logging. This can restore the
printing of the prefixes. This crate uses
`env_logger <https://crates.io/crates/env_logger>`_, so it is possible
to customize default behavior via environment variables.
* The possible values for the ``--code-signature-flags`` are now advertised in
help output.
* Written Mach-O files should now always have their filesystem permissions
preserved. Before, we may not have preserved file permissions in all code
paths writing Mach-O files.
* A new ``keychain-print-certificates`` command can be used to print
certificates available in macOS keychains.
* Initial support for using macOS keychain certificates for code signing.
Previously, we required that certificates be exported from keychain in
order to sign. We now support signing using SecurityFramework APIs so
keys don't have to leave the keychain. Due to a limitation in the Rust
bindings to SecurityFramework, decryption using keychain keys is not
supported. So the *public key agreement* method of remote code signing
will not yet work with keychain-based keys. The new ``--keychain-domain``
and ``--keychain-fingerprint`` arguments can be used to specify how to
search for and use keychain hosted keys.

Page 2 of 4

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.