• Laser@feddit.de
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    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.

    nix provides 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.

  • corytheboyd@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    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.

    • andrew@lemmy.stuart.fun
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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.