Activity

1. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Jul 16, 2026
2. drew commented on Jul 17, 2026

   

   drew

   on Jul 17, 2026

   Collaborator

   More actions

   I think the report may be conflating macOS host dependencies with files inherited by the Linux guest image.

   • On macOS, e2fsprogs is an external host dependency used to create ext4 images; it is not bundled in OpenShell's source or official macOS release artifacts.
   • The Linux mke2fs, debugfs, and mkfs.ext4 files in the default rootfs are inherited from the Community bootstrap image's Ubuntu parent, which also includes the package's copyright metadata and GPL-2 license text.
   • The VM driver does not copy the host tools or libraries into the rootfs. A compatible custom bootstrap_image without e2fsprogs produces a rootfs without them.
   • The reported .dylib names match Homebrew's host-side dependency closure, but I found no .dylib files in the Linux rootfs artifacts I inspected. If they were observed inside rootfs.ext4, please provide the raw scanner output and image digest.
3. drew

   removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Jul 17, 2026
4. drew

   changed the title [-]# GPL-2.0 licensed binaries bundled in sandbox rootfs — can be replaced with permissively-licensed alternatives[/-] [+]GPL-2.0 licensed binaries bundled in sandbox rootfs — can be replaced with permissively-licensed alternatives[/+] on Jul 17, 2026
5. adiaspace

   changed the title [-]GPL-2.0 licensed binaries bundled in sandbox rootfs — can be replaced with permissively-licensed alternatives[/-] [+]e2fsprogs (GPL-2.0) required as macOS host dependency — request for configurable path and permissive alternatives[/+] on Jul 22, 2026
6. adiaspace commented on Jul 22, 2026

   

   adiaspace

   on Jul 22, 2026

   Author

   More actions

   Thanks @drew for the thorough response — you're correct that the original report conflated macOS host dependencies with Linux rootfs contents. After a deeper investigation into both codebases, here's a more precise breakdown.

   Correction: .dylib files are macOS host-side, not inside the Linux rootfs

   The .dylib entries listed in the issue are macOS dynamic libraries from Homebrew's e2fsprogs formula. They do not exist inside the Linux guest rootfs (Linux uses .so). you are right — the Linux-side mke2fs/debugfs in the rootfs are inherited from the Ubuntu base image and ship with standard Debian/Ubuntu copyright metadata.

   Why we bundle e2fsprogs on the macOS host

   The OpenShell VM driver (openshell-driver-vm) requires mke2fs, mkfs.ext4, and debugfs at runtime on the macOS host to:

   1. Create ext4 disk images from rootfs.tar — format_ext4_image_from_dir() in [crates/openshell-driver-vm/src/rootfs.rs](https://github.com/NVIDIA/OpenShell/blob/main/crates/openshell-driver-vm/src/rootfs.rs) invokes mke2fs/mkfs.ext4
   2. Inject files into the ext4 image (TLS certs, JWT keys, init scripts) — write_rootfs_image_file() and set_rootfs_image_file_mode() invoke debugfs

   Hardcoded Homebrew paths in OpenShell source

   The driver's tool resolution function hardcodes Homebrew prefixes for both Apple Silicon and Intel Macs:

   // crates/openshell-driver-vm/src/rootfs.rs
   fn e2fs_tool_candidates(tool: &str) -> Vec<PathBuf> {
       let mut candidates = vec![PathBuf::from(tool)];
       for root in ["/opt/homebrew/opt/e2fsprogs", "/usr/local/opt/e2fsprogs"] {
           candidates.push(Path::new(root).join("sbin").join(tool));
           candidates.push(Path::new(root).join("bin").join(tool));
       }
       candidates
   }

   This means the driver searches in this order:

   1. $PATH lookup (bare tool name — e.g. mke2fs)
   2. /opt/homebrew/opt/e2fsprogs/{sbin,bin}/ (Apple Silicon Homebrew)
   3. /usr/local/opt/e2fsprogs/{sbin,bin}/ (Intel Homebrew)

   If the tool is not found anywhere, rootfs provisioning fails with:

   failed to create ext4 rootfs image: ... Install e2fsprogs (mke2fs/mkfs.ext4) and retry
   

   macOS ships no ext4 utilities natively, and for enterprise distribution we cannot assume end users have Homebrew installed. So our installer bundles precompiled e2fsprogs binaries from Homebrew into a private prefix at /usr/local/share/arc/e2fsprogs/{bin,sbin,lib}/ — never into Homebrew's own paths. At runtime, we prepend this path to PATH when spawning the gateway, so candidate Point#1 above resolves to our bundled copy.

   The bundled files and their licenses:

   File	License
   bin/mke2fs, sbin/mke2fs	GPL-2.0
   bin/debugfs, sbin/debugfs	GPL-2.0
   bin/mkfs.ext4, sbin/mkfs.ext4	symlink → mke2fs
   lib/libext2fs.*.dylib	LGPL-2.0
   lib/libe2p.*.dylib	LGPL-2.0
   lib/libblkid.*.dylib	LGPL-2.1
   lib/libcom_err.*.dylib	MIT-derived
   lib/libss.*.dylib	MIT-derived
   lib/libuuid.*.dylib	BSD-3-Clause
   lib/libintl.*.dylib	LGPL-2.1 (gettext)

   Dylib references are rewritten via install_name_tool to load from the bundled lib/ directory, and all binaries are re-signed ad-hoc in the postinstall script to ensure consistent code signing.

   Questions for the OpenShell team

   1. Environment variable override: Would you consider adding an OPENSHELL_E2FSPROGS_DIR (or similar) environment variable to let integrators specify a custom e2fsprogs prefix? This would let us point the driver directly at our bundled path without relying on $PATH injection.

   2. Permissive alternatives: Are there plans to replace the mke2fs/debugfs dependency with a Rust-native or permissively-licensed ext4 implementation? This would eliminate the GPL-2.0 bundling requirement entirely for downstream distributors.

   3. Compliance guidance: For distributors who must bundle these GPL-2.0 binaries — is including the GPL-2.0 license text alongside the binaries plus a source-code URL (pointing to the e2fsprogs upstream git) sufficient, or does NVIDIA recommend a specific compliance approach?

   ---
7. drew commented on Jul 28, 2026

   

   drew

   on Jul 28, 2026

   Collaborator

   More actions

   Permissive alternatives: Are there plans to replace the mke2fs/debugfs dependency with a Rust-native or permissively-licensed ext4 implementation?

   No concrete plans, but I have an idea to prebuild sparse ext4 templates in CI using e2fsprogs. Then we can ship the compressed filesystem artifacts and remove the host dep. Let me give this approach a try and see if it works.
8. github-actions commented on Aug 28, 2026

   

   github-actionsbot

   on Aug 28, 2026 – with GitHub Actions

   More actions

   This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
9. github-actions

   added

   state:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.

   on Aug 28, 2026
10. johntmyers

    closed this as not plannedon Sep 21, 2026