Of course. In my opinion, what Docker is used for on Hub is a different model than it was originally supposed to solve. It was designed as a solution for enterprise where the development team had no easy control over the production environment, so the solution was to bundle the platform with the software. However, your production team is usually trustworthy, so leaking secrets via the container isn’t an issue (or actually sometimes you wanted the image to include secrets).
The fact that Hub exists is a problem in itself in my opinion. Even things like the AUR - which comes with its own set of problems - is a better solution.
nixprovides a solution to build clean Docker images. But then again it only works for packages that are either in nixpkgs already or you have written a derivation for, the latter being probably more effort than a quick and dirty dockerfile.I’m sure plenty of the offenders are legitimate, but it’s completely safe to check private key pairs into code, or to bake them in to images. It entirely depends on what the key pairs are used for. Very common to include key pairs for development/test environments, for example. If it’s a production secret, of course you don’t do this.
You’re right in one sense but when you get to the last sentence your argument breaks down.
The same type of secret should be treated the same way. The problem with treating environments different is that it builds bad habits especially for new devs who come in and see it being done in a certain way. But also, humans screw up and it’s better to just build the habit of not committing anything private outside of prod-like credential stores even if it’s not the prod instance.
