dlor

Yep, but workarounds come with a cost. We're trying to package basically everything, so you don't need to pick between "up to date software" and "software from a trusted distro".

It's going to be hard to scale, but we're going to at least try! We have a lot of ideas on how to make this work that I'm excited to try out.

Debian does a great job! But here's one example where their packaging system makes container workloads hard. Debian, like many other distros has a strict "one version of every package" rule, meaning that Debian only ships one version of common things like programming languages or webservers.

If you "apt-get install nodejs", you can only have Node.js v18, in the very very recently released Debian bookworm. If your devs need Node.js v20, or even v22 which will both be LTS releases during the bookworm release cycle, you're out of luck.

You can go install those outside of the Debian package manager, but then you're on your own for vuln assessment and security fixes. Worse - many scanners don't actually even "see" packages that are installed outside of package managers, so you may not know that these exist or are installed.

We designed Wolfi to be more flexible around package versions. This is a very very hard problem to solve in general, but since we're focused on immutable containers, we can skip a lot of the complexity around conflicts, upgrade/downgrade scenarios, and cross-version compatibility.

The fun part of HN is that you don't get to pick your turn on the front page. This was a surprise to me too, but I'm guessing it's up here for the same reasons you are.

For static, not really just because there's so little in it. For apps that need CGO there's a benefit as more dependencies are required. CGO apps are broken right now IIUC in distroless/glibc-dynamic because of the Debian glibc bump.

Totally understand the concern. We've tried to draw a very clear line between Wolfi (the project), and Chainguard Images (our product). They're in different GitHub organizations, have different maintainers, and are documented differently.

We (Chainguard) still represent most of the maintainers to Wolfi, but there are external folks too. We're going to need help scaling Wolfi to get it to where we want it to be, and that will require a real community.

We've also tried to be very clear on the business model for us, to avoid any "rug pulls" or "bait and switches" later. Here's some more context on that too: https://www.chainguard.dev/unchained/scaling-chainguard-imag...

Thanks! By building the SBOMs as part of the build process we can ensure full coverage, vs. the other approaches that rely on "guessing" the contents after. We wrote a bit more about this approach here: https://www.chainguard.dev/unchained/make-sboms-not-guessbom...

You don't really have a choice - containers always use the host kernel. So packaging the full kernel itself is a waste of space at best, confusing to CVE scanners, and something you just don't need to bother with if you work with containers only.

I was (one of) the original creators of the Google Distroless project. The main difference is that Original Distroless uses Debian as the upstream. This is great in many ways, but makes it so stuff outside of Debian is hard to package in.

Wolfi is its own upstream - packages are sourced and built directly from source, without another Linux distro.

The rest of the differences stem from here - we get more control over what we package and how, and are able to more quickly add new versions of packages, or roll out CVE patches.

It was meant to be a tongue-in-cheek way of pointing out that a it's a Linux distro without the Linux kernel, so it's really an "unLinux distro", or an (un)distro for short.

In Wolfi's packaging system (melange) we setup a hermetic build environment. See here:

http://github.com/wolfi-dev/os

https://github.com/chainguard-dev/melange

We use this to build APK packages from source for a large set of software.

I'd love to make this happen, but there aren't really any IDPs that meet this criteria yet.

Happy to help get one going though!

I know folks hate the centralization of identity management to the big identity providers, but as AI gets better and better at defeating captcha it's going to get harder and harder for the small, independent ones to operate reliably and securely.

They have similarities in that they both can be used to sign things, but the architecture is completely different and sigstore is designed for different tradeoff - namely to be much easier to get started with and use.

I disagree here - these could be targeted and just because we haven't seen impact yet doesn't mean there wasn't any. All it takes is one download from the right person then it can be pivoted into a supply chain attack.

I don't want to speculate on exactly how the developer at CircleCI was compromised, but it wouldn't surprise me if it was something like this. They can be pretty easily targeted and it's trivial to get RCE on a developer's laptop during package install.

These are hard to detect for a few reasons:

  - Traditional endpoint protection is often disabled on developer machines
  - Developers require much more access to their machines to do their jobs
  - Installing packages in most programming languages still results in RCE at install time
  - Most solutions are aimed at protecting code once it makes it to CI and production, but developer machines are still the wild west

If you're not already operating in a world where you assume every developer laptop is compromised, you need to start. The only real protection here is requiring multi-party review for *everything*.

These attacks are more and more common and there's still little to actually solve them.

We're working on this at Chainguard by starting at the lowest levels (a containerized Linux distro) where we can deliver packages safely. Then we can use that layer to safely deliver language packages, like in this case.

This is all being done in the open, with projects like Sigstore (sigstore.dev) and our Linix distro Wolfi (wolfi.dev).

This is an incredibly complicated space and there's no silver bullet. We need to build safe delivery mechanisms for trustworthy software.

Linux distros have traditionally done this very well, but they've struggled to solve language package manager distribution, leading developers to shy away from and work around them when installing things like PyTorch.

Our hope is that we can bring the trustworthiness of Linux distros to language package managers, and the ease of language package managers to Linux distros.

CEO here. We use a transparency log (sigstore) instead of a blockchain.

Sigstore does this with a transparency log instead of a Blockchain.

Depends exactly what you're trying to create it for. I advocate for doing it during the build process rather than as a step after.

We open sourced a few tools that do it automatically for containers:

https://github.com/chainguard-dev/apko

https://github.com/chainguard-dev/melange

This type of friendly tooling is exactly what was missing from OSV! I look forward to OSV making it easier to manage and deal with vulnerabilities.

Some kind of post-mortem or statement at all about how the GitHub account got compromised, if that's what happened here.

It could have also been a researcher checking to see if anyone would notice, or something worse.

The issue from the researchers appears to be here: https://github.com/timaakulich/fastapi_toolkit/issues/4

This is definitely pretty strange. Account takeovers happen, but just reverting the commit and closing the issue after one gets discovered is not the best way to handle these.

This is the reality of our modern software development process though. Your threat model now must include the GitHub account of every maintainer of every open source project you use.

Basically yes - unless you also keep enough metadata around somewhere for a scanner to know what version of nginx is installed. This can be done out-of-band with an SBOM, or in-band by using package manager metadata.

This is basically the definition we used. It's practically important because scanners really do miss software copied in via other mechanisms, and most of them give zero indication about it. For a few basic examples, try running your favorite scanner on the wordpress, node, or busybox images on DockerHub and see what the scanner finds.

For Wordpress, most scanners will miss that PHP or Wordpress are even installed in the image. The scanners spit out lots of data, but it's only about what they can find, offering the illusion of completeness or transparency.

I'm not going to argue that the NSA report is amazing or terribly well-written, but re-reading it with the principle of charity nullifys many of these rebuttals.

For one example, from the rebuttal:

> If there is concern that their user credentials will beget malefaction and mistakes, then why discourage service accounts2, which are inherently decoupled from specific user identities?

But then looking at the text from the document itself:

> Minimize and regularly audit service accounts,

> The use of service accounts, like non-human privileged accounts used to run automated processes, should be minimized and carefully audited. Every service account login should be logged. These logs should include date and time and the origin of login. Service accounts should follow the “least privileged” policy. All service accounts should be regularly reviewed to assure they are still needed, and unnecessary accounts removed.

I don't think the document is saying to avoid service accounts in favor of something silly like shared passwords. It's saying to use the fewest you can get away with, delete unused ones, and regularly audit access to them.

Shameless plug for the gitsign project in sigstore: https://github.com/sigstore/gitsign

This isn't supported by GitHub yet but we're hopefully working towards that too.

A common gotcha is ca-certs and tzdata.

It's less about first-party software and more for third-party off-the-shelf stuff you might run. For first-party stuff SBOMs can definitely feel useless.

And I hear this is improving to allow short-lived publication tokens and federation to prevent them from being leaked :)

I agree it's nonsense. The argument appears to dodge 2FA itself and the benefits to ecosystem by instead focusing on fairness, which is subjective at best.

It's not "fair" that the author has to accept the burden of 2FA, because they created a package that turned out to be critical through no fault of their own.

It would seemingly satisfy the author's "fairness" goal if everyone had to use 2FA whether their packages are critical or not.

It's also ironically not "fair" that the volunteer maintainers of PyPI are subjected to complaints like this for their hard and valuable work to improve the security of the entire ecosystem, which has become critical infrastructure itself through no fault of their own.