Roadmap - SingularityCE 4.3

[dtrudg]

SingularityCE 4.3 is targeted for release in the period December 2024 - January 2025.

Please use this thread to comment and suggest features for inclusion in 4.3. We'll update this top post as items are suggested and discussed.

The focus of SingularityCE 4.3 will be improved integration with external tooling that has become prominent for OCI container signing and audit. Some of the work will take place in third-party projects, rather than SingularityCE, but is considered to be part of the SingularityCE roadmap.

4.3 Planned Features

Sigstore integration

Singularity currently supports PGP key and PEM Key / X.509 Certificate Support in its signing and verification flows. While both native SIF and OCI-SIF images can be signed, there is currently no direct integration of signature verification into OCI-SIF execution / distribution workflows etc.

In the broader OCI world, the sigstore project has emerged as the dominant solution for container signing and verification via the cosign tool.

To further the compatibility of Singularity OCI-SIF with existing OCI workflows we will support sigstore container signing for OCI-SIF in Singularity. This will include support for interacting with remote registries.

Improved Anchore tooling integration

The Anchore tools syft & grype provide a convenient way to create a Software Bill of Materials (SBOM) for a container, and to audit containers vs published vulnerability databases.

Previously, Sylabs has worked with the Anchore open source projects to add support for scanning native SIF files directly with syft & grype. This functionality is limited to native SIF, and does not currently extend to support for OCI-SIF.

We will aim to contribute support for OCI-SIF to the Anchore open source projects. This should include the ability to scan OCI-SIF files locally, and those that are located in a remote registry.

Improve, document, and test nested container behaviour

E.g.

• e2e: implement nested container/namespace tests #2700
• Nested Singularity: failed to add as session directory #3217
• singularity in docker <23.0.0: Requesting capability set 0x000001ffffffffff while permitted capability set is 0x0000003fffffffff #1466

Support for running Singularity-in-Docker or Singularity-in-Singularity has been informally tracked throughout the life of SingularityCE to date. We do not currently perform any automated testing of nested container execution. Issues arise from changes made to code where the effect on nested execution was not tested / considered.

Given extensive use of container-based CI systems to build containers, it is not uncommon for Singularity to be run under Docker or another OCI runtime. Similarly, HPC centers may e.g. run Singularity from a workflow that is itself run in a Singularity-based workflow automation.

We will introduce basic testing of nested workflows in SingularityCE's e2e suite. We catalogue, and will aim to address any blocking issues that prevent nested execution in native and OCI mode.

Tidy GO_GC Handling

• Tidy up GO_GC handling? #2839

SingularityCE currently uses a blunt, but effective, method to address the issue of the Go garbage collector vs the closing of file descriptors during container startup under certain circumstances.

We have previously avoided following Apptainer's approach to solve this problem, as it did not address all failures in our testing. However, more recent further changes in Apptainer warrant a closer review. We can also consider the approach implement in runc, that uses some Go internals to avoid closing GC related file desccriptors.

Under Consideration

Not currently planned for inclusion, but may be considered.

Create bind destinations during build

• Create bind destinations during build #2766

When a -B / --bind option is used with singularity build, the bind mount target must be present in the image before the %post step executes.

This makes it a little awkward to use -B with singularity build, as generally a well-known existing path must be used (e.g. /mnt), or directories must be created in the rootfs via a %setup block.