Does it store a complete dependency graph for each of your statically built (or containerized) applications?
No. Though some of it can be inferred from the overtly verbose logs
For example, if there’s an exploit for libwebp and you need to update all the binaries that link it, can it find which binaries need updating from that information?
No again.
Currently, most packages are built from git HEAD
on alpine:edge
or debian-unstable
build containers.
So if the fix for this affected libwebp is shipped to the images that the build containers are based on (likely because we use edge/unstable images), then any affected packages would also automatically receive this fix.
To store a complete dependency graph, we will most likely need some custom tooling because our build recipes differ wildly for each package. If you have any ideas, please open a discussion on the repo. Thanks!
Yes, only if there's a new version.
We specifically mark these kinds of packages as
outdated
(evendeprecated
) if they are older than 90 daysCurrently, the stats:
This will improve if we can get more builders, currently we use the free CI provided by github actions