OpenFGA v0.4.3 is released with signed release artifacts and Software Bill of Materials (SBOM) #139
Closed
adriantam
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey folks!
We just released OpenFGA v0.4.3. It includes signed signed release artifacts, software bill of materials (SBOM).
If you are running through docker:
If you are targeting latest, make sure to update by running docker pull openfga/openfga
If you are targeting pinned releases, make sure to set your pinned version to: openfga/openfga:v0.4.3
Changes in this release
Added
Release artifacts are now signed and include a Software Bill of Materials (SBOM) (#683)
The SBOM (Software Bill of Materials) is included in each Github release using Syft and is exported in SPDX format.
Developers will be able to verify the signature of the release artifacts with the following workflow(s):
If the
checksums.txt
validation succeeds, it means the checksums included in the release were not tampered with, so we can use it to verify the hashes of other files using thesha256sum
utility. You can then download any file you want from the release, and verify it with, for example:And both should say "OK".
You can then inspect the .sbom file to see the entire dependency tree of the binary.
Developers can also verify the Docker image signature. Cosign actually embeds the signature in the image manifest, so we only need the public key used to sign it in order to verify its authenticity:
openfga migrate
now accepts reading configuration from a config file and environment variables like theopenfga run
command (#655) - thanks @suttod!The
--trace-service-name
command-line flag has been added to allow for customizing the service name in traces (#652) - thanks @jmiettinenFixed
ulid
when it is not needed. This can improve read query performance on larger OpenFGA stores (#677)openfga migrate
command (#663)requestid
middleware is registered earlier(#662)Changed
Bumped up to Go version 1.20 (#664)
Default model schema versions to 1.1 (#669)
In preparation for sunsetting support for models with schema version 1.0, the WriteAuthorizationModel API will now interpret any model provided to it as a 1.1 model if the
schema_version
field is omitted in the request. This shouldn't affect default behavior since 1.0 model support is enabled by default.Beta Was this translation helpful? Give feedback.
All reactions