14 ms·

I don't see how that's a compelling argument at all. All that's keeping you from committing your credentials is a .gitignore file. They have the file, it works

I don't see how that's a compelling argument at all. All that's keeping you from committing your credentials is a .gitignore file. They have the file, it works reliably, don't worry about it.

deleted 11y ago
[deleted]
hinkley 11y ago
You should know there was a pretty big bug fixed in .dockerignore in just the last release. [edit] That bug was in the logic for white-listing files, which is generally the safest way to keep from accidentally publishing things (that is, if it works). And it's possible a similar issue still exists in docker-compose but it's still open. .gitignore keeps me from checking my files into git, but it doesn't keep me from publishing them in a docker image. So now I have a second way to screw up.
- colemickens 11y ago
  Can you link to this bug? I thought .dockerignore specifically didn't allow whitelisting and only allowed for blacklisting files that weren't to be included. Are you saying that docker would include files that should have been excluded by .dockerignore? I'd be interested to learn more. Thanks in advance.
  - Estragon 11y ago
    You could probably whitelist with a .dockerignore like * # exclude everything !README.md # include the README. !run.sh # include the initiation script You would want to check exactly what the globbing rules are for the .dockerignore file, though. I don't know whether '*' will catch .dotfiles, for instance. https://docs.docker.com/engine/reference/builder/#dockerignore-file https://golang.org/pkg/path/filepath/#Match
    - hinkley 11y ago
      That's it, thanks for following up in my absence. There are a couple of frameworks where all of the production files end up in, for instance /dist and one other directory. Rather than having to constantly blacklist everything you just say "ignore everything except X and Y"
  - hinkley 11y ago
    I'm sorry, things got hectic and I bailed on the discussion. I thought I had a handy link to the bug I was thinking of, but I couldn't find a back-link from the issue I'm watching to the one in docker/docker. I think but am not 100% certain this is the issue I was thinking of, but it seems the most likely, and it was just fixed in 1.10: https://github.com/docker/docker/issues/17911 https://github.com/docker/docker/issues/17911 Some day I'm sure .dockerignore will be solid, but my confidence level isn't high enough yet (it's getting there) to base my trust on. My point was that there are other ways that directory structures and what is visible to COPY could have played out where vigilance is less of a problem. It's usually immediately obvious if a file you actually needed is missing from a build, but less obvious that a file that you categorically did NOT want to be there is absent. Because the system runs in one of those scenarios and dies conspicuously in the other.

I don't see how that's a compelling argument at all. All that's keeping you from committing your credentials is a .gitignore file. They have the file, it works reliably, don't worry about it.

deleted 11y ago

[deleted]

hinkley 11y ago

You should know there was a pretty big bug fixed in .dockerignore in just the last release. [edit] That bug was in the logic for white-listing files, which is generally the safest way to keep from accidentally publishing things (that is, if it works). And it's possible a similar issue still exists in docker-compose but it's still open. .gitignore keeps me from checking my files into git, but it doesn't keep me from publishing them in a docker image. So now I have a second way to screw up.

colemickens 11y ago
Can you link to this bug? I thought .dockerignore specifically didn't allow whitelisting and only allowed for blacklisting files that weren't to be included. Are you saying that docker would include files that should have been excluded by .dockerignore? I'd be interested to learn more. Thanks in advance.
- Estragon 11y ago
  You could probably whitelist with a .dockerignore like * # exclude everything !README.md # include the README. !run.sh # include the initiation script You would want to check exactly what the globbing rules are for the .dockerignore file, though. I don't know whether '*' will catch .dotfiles, for instance. https://docs.docker.com/engine/reference/builder/#dockerignore-file https://golang.org/pkg/path/filepath/#Match
  - hinkley 11y ago
    That's it, thanks for following up in my absence. There are a couple of frameworks where all of the production files end up in, for instance /dist and one other directory. Rather than having to constantly blacklist everything you just say "ignore everything except X and Y"
- hinkley 11y ago
  I'm sorry, things got hectic and I bailed on the discussion. I thought I had a handy link to the bug I was thinking of, but I couldn't find a back-link from the issue I'm watching to the one in docker/docker. I think but am not 100% certain this is the issue I was thinking of, but it seems the most likely, and it was just fixed in 1.10: https://github.com/docker/docker/issues/17911 https://github.com/docker/docker/issues/17911 Some day I'm sure .dockerignore will be solid, but my confidence level isn't high enough yet (it's getting there) to base my trust on. My point was that there are other ways that directory structures and what is visible to COPY could have played out where vigilance is less of a problem. It's usually immediately obvious if a file you actually needed is missing from a build, but less obvious that a file that you categorically did NOT want to be there is absent. Because the system runs in one of those scenarios and dies conspicuously in the other.