• Ajam@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    10 days ago

    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!

    • drspod@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 days ago

      Thanks for the reply.

      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.

      How often do packages get rebuilt? Is it only when there’s a new version? The problem in that case would be that a package that is no longer developed (or has very long release cycles) would not receive the fix.

      • Ajam@lemmy.worldOP
        link
        fedilink
        English
        arrow-up
        5
        ·
        10 days ago

        How often do packages get rebuilt? Is it only when there’s a new version?

        Yes, only if there’s a new version.

        The problem in that case would be that a package that is no longer developed (or has very long release cycles) would not receive the fix.

        We specifically mark these kinds of packages as outdated (even deprecated) if they are older than 90 days

        Currently, the stats:

        This will improve if we can get more builders, currently we use the free CI provided by github actions