add native support for flatpak and snap images #1088
Comments
|
Thanks for filling the issue @ciphernaut-rh! I think we have to do some preliminary investigation on if the images support OCI and fit nicely in with the https://github.com/anchore/stereoscope library that supports how syft breaks apart and pulls information from a given container image. Do you have any good references we could use to start digging into flatpak and snap images that could help with the design surrounding this issue? |
|
Clarifying question: is the ask to report the flatpaks themselves? or the flatpaks + what's inside of the flatpaks? If it's the latter case, this is related to #246 , where we need to run all of the enabled catalogers within the unpacked flatpack. |
Yes please, include all of the components that make up the flatpak.
|
|
$ snap info core18 $ syft packages dir:/snap/core18/ |
|
$ flatpak info org.gnome.Platform/x86_64/42 GNOME Application Platform version 42 - Shared libraries used by GNOME Collection: org.flathub.Stable $ syft dir:/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/42/active/files/ |
|
both of these examples are from installed items. Ideally it would be nice to scan them with syft and grype without having to install them |
|
At a first glance it doesn't seem like flatpaks are stored in an OCI repo flatpak/flatpak#4744 (or snaps either, but am still looking around). For that reason I don't think it makes sense to have syft do the work of pulling the packages (in the same way that we don't interact with rpm, dpk, apk registries / repos). Are there ways to get flatpaks downloaded in a distribution format? say like a single tar.gz or zip? If so, I feel that syft being able to open up the archive / container image / distribution format and running the scan correctly makes sense. This would save the user from having to know where on |
|
For snaps - they're squashfs files, which the user can download, unpack and then scan with syft, like any other directory. Download snap packageIf the user is on a machine with the $ SNAPNAME="hello-world"
$ CHANNEL="stable"
$ snap download "$SNAPNAME" --channel="$CHANNEL"If they're not on a machine with $ SNAPNAME="hello-world"
$ CHANNEL="stable"
$ curl -sL --output "$SNAPNAME".snap $(curl -s -H 'Snap-Device-Series: 16' http://api.snapcraft.io/v2/snaps/info/$SNAPNAME | jq -r '.["channel-map"][] | select(.channel.architecture == "amd64" and .channel.name == "'$CHANNEL'") | .download.url')Unpack it$ unsquashfs "$SNAPNAME"*.snap
$ tree squashfs-root/
squashfs-root/
├── bin
│ ├── echo
│ ├── env
│ ├── evil
│ └── sh
└── meta
├── gui
│ └── icon.png
└── snap.yamlScan it$ syft scan dir:squashfs-root
✔ Indexed file system squashfs-root
✔ Cataloged contents 371b4bb9660cd5035e57c09aff807bcee3de0f71b912e498818153684b206f8e
├── ✔ Packages [0 packages]
└── ✔ Executables [0 executables]
[0000] WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
No packages discoveredI should have picked a more interesting snap, to be fair. Edit: Libreoffice is more 'interesting' $ snap download libreoffice
$ unsquashfs libreoffice*.snap
syft dir:squashfs-root/
✔ Indexed file system squashfs-root
✔ Cataloged contents 371b4bb9660cd5035e57c09aff807bcee3de0f71b912e498818153684b206f8e
├── ✔ Packages [57 packages]
├── ✔ File digests [110 files]
├── ✔ File metadata [110 locations]
└── ✔ Executables [929 executables]
[0000] WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
NAME VERSION TYPE
HelloWorld UNKNOWN java-archive
Highlight UNKNOWN java-archive
MemoryUsage UNKNOWN java-archive
ScriptFramework UNKNOWN java-archive
ScriptProviderForBeanShell UNKNOWN java-archive
ScriptProviderForJava UNKNOWN java-archive
ScriptProviderForJavaScript UNKNOWN java-archive
XMergeBridge UNKNOWN java-archive
bsh 2.0b6 2024-09-05 06:18:45 java-archive
ca-certificates-java UNKNOWN java-archive
commonwizards UNKNOWN java-archive
el-api 3.0.0 java-archive
flow-engine UNKNOWN java-archive
flute 1.1.6 java-archive
form UNKNOWN java-archive
hsqldb1.8.0 1.8.0.10+dfsg java-archive
hsqldbutil1.8.0 1.8.0.10+dfsg java-archive
java_uno UNKNOWN java-archive
java_websocket UNKNOWN java-archive
javax.el-api 3.0.0 java-archive
javax.servlet-api 4.0.1 java-archive
javax.servlet.jsp-api 2.3.4-SNAPSHOT java-archive
javax.websocket-api 1.1 java-archive
javax.websocket-client-api 1.1 java-archive
jrt-fs 17.0.12 java-archive
js UNKNOWN java-archive
jsp-api 2.3.4-SNAPSHOT java-archive
juh UNKNOWN java-archive
jurt UNKNOWN java-archive
libbase 1.1.6 java-archive
libfonts 1.1.6 java-archive
libformula 1.1.7 java-archive
liblayout UNKNOWN java-archive
libloader 1.1.6 java-archive
libreoffice UNKNOWN java-archive
librepository 1.1.6 java-archive
libserializer 1.1.6 java-archive
libxml 1.1.7 java-archive
mediawiki UNKNOWN java-archive
officebean UNKNOWN java-archive
openjdk 17.0.12+7-Ubuntu-1ubuntu222.04 binary
python 3.10.12 binary
query UNKNOWN java-archive
report UNKNOWN java-archive
reportbuilder UNKNOWN java-archive
reportbuilderwizard UNKNOWN java-archive
ridl UNKNOWN java-archive
sac UNKNOWN java-archive
sdbc_hsqldb UNKNOWN java-archive
servlet-api 4.0.1 java-archive
smoketest UNKNOWN java-archive
table UNKNOWN java-archive
unoil UNKNOWN java-archive
unoloader UNKNOWN java-archive
websocket-api 1.1 java-archive
websocket-client-api UNKNOWN java-archive
xmerge #IMPL-VERSION# java-archive |
What would you like to be added: support for pulling flatpak and snap images from repos for scanning
Why is this needed: scan packages from snap and flatpak without needing to install them first
Additional context:
It is possible to scan flatpak and snap images with some level of success once they have been installed using the dir: specifier. It would be neat if syft (and grype) knew how to fetch these packages directly (from original and alternative sources) and generate an sbom without needing to 'install' them first.
The text was updated successfully, but these errors were encountered: