11–20 of 45 posts
Earlier quoted context omitted.
Its easy to miss that you need to duplicate your .gitignore into your .dockerignore
To not have to remember that one can not use a .dockerignore at all and instead explicitly pick the files and directories from the build context that need to be in the image.
For a Go service? Sure, that's easy and makes a ton of sense.
I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
Earlier quoted context omitted.
To not have to remember that one can not use a .dockerignore at all and instead explicitly pick the files and directories from the build context that need to be in the image.
This is annoying and error prone if you use an interpreted language that relies on loading source files at runtime. For a Go service? Sure, that's easy and makes a ton of sense.
The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)? When I see things like those, they look so wrong to me. But sadly it's apparently uncommon nowadays: not only random bloggers, even my coworkers see nothing wrong with putting passwords or tokens into general config or source code f…
I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
It's because dockerignore file does not take this into consideration.
naive question: Doesn't github secret scan kind of thing wont catch this?
The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)? When I see things like those, they look so wrong to me. But sadly it's apparently uncommon nowadays: not only random bloggers, even my coworkers see nothing wrong with putting passwords or tokens into general config or source code f…
People & organisations tend to follow the path of least resistance. If it's easier to put passwords into a plaintext config file than not, passwords will invariably end up in plaintext config files in some projects. `PASSWORD = open("/home/user/.config/mypass.txt").read().strip()` will work right up until a colleague without `"/home/user/.config/mypass.txt"` attempts to run the project - at which point it'll be replaced with `PASSWORD = "the_password123"`.
The only pragmatic solution is to make it easier to handle passwords securely than to handle them insecurely.
> Pushing Malicious Changes to the Pipeline
mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.
Am I missing something, or does the step in > Pushing Malicious Changes to the Pipeline mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.