The Deletion of Docker.io/Bitnami

I don't want to discount the work they are doing, and that it has no value, but a little bit shocking that they expect to go all commercial with this, in the Oracle way, while just "packaging" and so relying on open source software that they will not contribute to.

Also, I'm a little bit wondering at how much all of this is really copyrightable in the end. Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".

And it might be each the single and obvious way to package the thing anyway.

And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...

"Makefile" they have written and copyrighting is very non trivial and there are many man-months of effort. Configuring all sorts of software just with env vars and make it usable is not an easy feat.

Have a look at https://github.com/bitnami/containers/tree/main/bitnami/post... as example.

It might be worth a commercial license for some of their current user-base, no doubt.

What probably carries more value is the helm charts that they provide which are also on their way out.

The images themselves have official replacements (for example, looking at https://hub.docker.com/u/bitnami why wouldn’t I use Node or Postgres images from the official sources instead).

I have no idea how many people actually used their helm charts though.

Some other open source projects have also shipped Bitnami software in their own helm charts, i.e. APISIX's etcd instance is the Bitnami chart pulled in as a dependency.

Not that it ever worked well, we had to scale it to 1 because the quorum would constantly break into unrecoverable states.

This has to be a joke, right? Months of effort for a makefile? In which world do people live these days

You seriously underestimate this in general case. Build system may be made in weeks, but is polished in months or even years, to account for all the different usage and environment scenarios. Otherwise, it's typically very fragile.

They do keep some of them more up to date, for example the bitnami python image had system packages patched faster than the official one. But if you are willing to pay then chainguard is a better solution.

It would only take you a weekend!

Tell me you haven't ever written even a moderately complex Makefile without telling me you haven't ever written even a moderately complex Makefile.

ChainGuard is $$$$$$$

We talked to them a couple years ago. A lot of what they are doing besides Wolfi is using Alpine which removes alot of findings by default

I don't even see any tests in the bitnami repo?

It is a lot of work but it is work that for the most part should not have been done. I took a quick look at the code (since I know PG very well) and I would not recommend anyone to use that mess off Bash code which configures PostgreSQL in an annoying and incorrect way and exposed some arbitrarily select settings in the environment (some very rarely used) while you have to do most in the config file. Better to just write your own Docker image for scratch, or use the official PG image of your needs are simple.

This is what happens if you merge every feature request you get and do not have a clear plan or architecture. After reading the code I am happy they are deleting the images, at least if this one is typical.

As a PostgreSQL expert I can write a much better image which suits my needs in one day, which I have also done several times. It would be harder for a non-expery but I do not think a non-expert should use this image due to some footguns I spotted. This kind of generic image is a bad idea and very hard to build.

Which is why I think you should not try to build generic images like this. I looked at the source and it seems like s lot of work had been put into creating a fragile mess.

After having been burned several times by images I prefer writing my docker images from scratch (based on the Debian or Alpine images) for production systems. I only use ready-made images for quickly getting something running locally to evaluate it.

> but I do not think a non-expert should use this image due to some footguns I spotted

Could you elaborate on your findings?

Alpine helps but it's not perfect. Plenty of outdated packages with known CVEs there for long time.

Often they are not exploitable but it's easier to pay chainguard to have a constant zero on our vuln scanner than to deal with distroless builds ourselves.

The GPU images are indeed very expensive though.

I get it but the likelihood those vulns are exploitable in your environment is dubious. It’s a lot of compliance theater. Defense in depth

In the world where "developers" cannot even wipe their buttocks without AI.

I agree, but I'm not spending my time arguing with PCI auditors.

Also it's safer from supply chain attacks. Malware inserted via compromised docker hub tokens is a growing threat.

Right, I deal with NIST 800-53 based things where we have heavy albeit manual auditing. We pull from Iron Bank mostly but also employ Nexus Firewall. People can’t pull direct Docker Hub.

Constantly updating to the latest version of innumerable software projects is safer from supply chain attacks? :)

My experience has been that the cost of “patching” is often bugs and instability, having gained nothing security-wise.

Wasn't the point of the post you replied to that it isn't just a simple makefile ? That repo contains quite a lot carefully assembled scripts for each image that handles a lot of corner cases.

Hindsight is 2020, there’s now helm/kubernetes operator under the cloud native umbrella. I’m sure they took in all the mistakes from here. This helm chart is getting long in the tooth, but is still monumental. Imo running psql on kube is a mistake to begin with but here we are.

For what it's worth, their pricing has decreased substantially over the last year. Their most recent quote to us was about 25% of the one we received a year or so ago.

For some more transparency, we pay ~$9k/year per image (all versions/variants) for some basic images (think python, golang etc). The ones with cuda drivers are more expensive but I don't have the exact prices on hand.

Not everything that's authored and published is eligible for copyright. Copyright applies to only the creative elements of a work that are unique. Things that are facts, or are necessary for function are not copyrightable.

They likely hold a copyright on the exact expression of their documentation, but the facts and information in that documentation, and necessary configuration such as port numbers, and dependency selection are not subject to copyright.

The effort you put into a work doesn't determine copyright. You can own the copyright to a photograph that took seconds to take. And you can spend every hour of the day keeping a meticulous log of room temperature, and not have a copyright, because a table of facts isn't copyrightable.

Surely some of this complexity is self-inflicted, like an SSL cert renewal tool built with InstallBuilder: https://github.com/bitnami/bncert

Yes, if you need someone else to work on securing your Docker base images for free, you can get more info about the US Air Force Platform One IronBank at https://docs-ironbank.dso.mil/faq

> Currently there is no cost to contributors or users for Iron Bank. It is a service currently funded by the US Department of Defense.

You can poke around for their public Dockerfile's to build yourself at https://repo1.dso.mil/explore (for example: https://repo1.dso.mil/dsop/opensource/debian/debian12.x/debi...) but to do much useful you'll need an account.

Another organization in Platform One, Big Bang uses IronBank containers to implement a reference DevSecOps CI/CD architecture; I mention them because they maintain a mirror at https://github.com/DoD-Platform-One/bigbang