SingularityPRO 3.9-7 is a bugfix and packaging release for SingularityPRO 3.9.

Packaging

• SingularityPRO 3.9-7 is now packaged for and supported on RHEL / AlmaLinux / Rocky Linux 9 across AMD64 / ARM64 / POWER architectures.
• Packages now contain a CycloneDX format Software Bill of Materials (SBOM).
• SingularityPRO 3.9-7 is built with Go 1.18.4. This release of Go addresses multiple CVEs in earlier versions of Go, used to build prior SingularityPRO releases. These CVEs are denial of service issues, not critically applicable to SingularityPRO. However administrators may wish to update.

New features / functionalities

• Debug output can now be enabled by setting the SINGULARITY_DEBUG env var.
• Debug output is now shown for nested singularity calls, in wrapped unsquashfs image extraction, and build stages.
• Add support for %files section in remote builds, when a compatible remote is used.

Software Bill of Materials

A Software Bill of Materials (SBOM) is a complete inventory of a codebase. It can be used to audit the content of a software package, and to identify any known vulnerabilities in those components.

SingularityPRO 3.9 packages contain a CycloneDX SBOM file listing the components used in the codebase. The file is installed to the default package documentation location of your Linux distribution.

Singularity Security

Singularity uses a number of strategies to provide safety and ease-of-use on both single-user and shared systems. Notable security features include:

• The user inside a container is the same as the user who ran the container. This means access to files and devices from the container is easily controlled with standard POSIX permissions.
• Container filesystems are mounted nosuid and container applications run with the PR_NO_NEW_PRIVS flag set. This means that applications in a container cannot gain additional privileges. A regular user cannot sudo or otherwise gain root privilege on the host via a container.
• The Singularity Image Format (SIF) supports encryption of containers, as well as cryptographic signing and verification of their content.
• SIF containers are immutable and their payload is run directly, without extraction to disk. This means that the container can always be verified, even at runtime, and encrypted content is not exposed on disk.
• Restrictions can be configured to limit the ownership, location, and cryptographic signatures of containers that are permitted to be run.

Support

If you have any questions about this release, or require assistance with installation or upgrades please contact your reseller or Sylabs support via support@sylabs.staging.sycloud.io

About Sylabs 

Sign up for the Sylabs newsletter at: https://sylabs.staging.sycloud.io/newsletter-sign-up/

Or contact Sylabs at https://sylabs.staging.sycloud.io/contact-us/