8u131 Environment Variables with periods (dots) are removed

[pluttrell]

With 8u121 lower case environment variables worked, but with 8u131 they do not.

Sending lower case environment variables is important because Spring Boot can use them to configure JavaMail, which requires certain lower case properties. For example GMAIL's SMTP server requires spring.mail.properties.mail.smtp.starttls.enable=true. If you convert this to SPRING_MAIL_PROPERTIES_MAIL_SMTP_STARTTLS_ENABLES=true, JavaMail will ignore the value.

I have created a simple project that demonstrates the issue. Build and execution instructions are listed in the README.md. https://github.com/pluttrell/bootvars

[idntfy]

Are you using alpine images? We faced this issue not so long ago, the root cause was Alpine version change from 3.5 to 3.6 - https://bugs.alpinelinux.org/issues/7344 (btw the issue is not in lowercase but in dots in the name - sh just ignores them since it's not POSIX)

For our images we just added bash and used it instead of sh through exec syntax:

FROM openjdk:8-jre-alpine

ENV JVM_OPTIONS ""
ENV WORKDIR_PATH /srv
ENV LOOKUP_PATH ./target
ENV JAR_FILENAME service.jar

RUN apk add --update bash && rm -rf /var/cache/apk/*

WORKDIR $WORKDIR_PATH

ONBUILD ADD $LOOKUP_PATH/$JAR_FILENAME $WORKDIR_PATH

ONBUILD CMD ["/bin/bash", "-c", "java $JVM_OPTIONS -jar $JAR_FILENAME"]

[yosifkit]

Looks like this also happens in the Debian based images with the move from Jessie to Stretch. The cause is an update to the dash package that provides /bin/sh (0.5.7-4 vs 0.5.8-2.4) and I think it comes from this commit in upstream: https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?h=v0.5.8&id=46d3c1a614f11f0d40a7e73376359618ff07abcd.

It looks like the only solution is to use bash rather than sh and is the fix I will propose for docker-library/tomcat#77.

[yosifkit]

I'm leaning toward not installing bash by default in the alpine based images. What do you think? (@pluttrell, @idntfy, @tianon)

Hopefully this issue will help users find the solution to their environment variable problem.

[tianon]

Yeah, adding bash by default seems like a bit too far (since it's really, really trivial to add), but this might be worth documenting in our image description.

[pluttrell]

My vote would be to move to bash in the short term. And if the dash package ends up eventually allowing periods again, then switch back at that time. The reason is that I stumbled upon this issue because I did a routine upgrade of the JRE version and we're using SpringBoot and we're using JavaMail and one of our testers was using Gmail's SMTP server. There's a lot of people using SpringBoot, a huge number using JavaMail and certainly quite a number using Gmails SMTP server - at least in non-production environments. So I think this issue is likely to impact a large number of people and I think we want these images to support a broad number of users.

[idntfy]

@pluttrell

1. Docker uses sh by default so whatever is installed in the container - you'll have changes on your end. The only option not to have changes on your end is to have sh behavior being changed in base image, which means either fixing it (low chance since it follows POSIX this way) or downgrading (which is also not a good option).

2. Isn't the issue in the way you pass those variables into container and propagate them to java processes? It can be done without dots in name while java system properties still will be with dots in the name.

---

That said, since it indeed can have some impact on Java world, I'm not against including it by default in openjdk-specific images - it will simplify one-liners for executing java processes inside docker images and having ability to pass env vars with dots out of the box - this is the only advantage I see. For all other things adding bash into image is a matter of a single line and can be done by whoever needs it.

[pluttrell]

@idntfy I'm not sure what you mean by passing the environment variables into the container without dots and then with dots into the java process. Can you please elaborate.

If you're referring to SpringBoot's automatic conversion whereby spring.mail.host and SPRING_MAIL_HOST are treated as the same thing... This is a nice feature that SpringBoot provides and it works for some things but not everything. And one place it does not work is passing SPRING_MAIL_PROPERTIES_MAIL_SMTP_STARTTLS_ENABLES=true vs spring.mail.properties.mail.smtp.starttls.enable=true. In this case SpringBoot passes the exact value of the environment variable (the uppercase+underscore version) and the JavaMail API requires the lowercase+dot version (reference). The latter of which has worked just fine up until now.

[idntfy]

@pluttrell Something like
docker run -e any_env_var_name=blablabla openjdk:8-jre-alpine java -Dyour.system.property.with.dots=${any_env_var_name} -jar ...

[kdubb]

After spending hours trying to figure out why our images pass IT's on some systems and not on others (cached 8u111 images were working... updated images weren't)... I can say that this is pretty hard to find.

Also, Java promotes the usage of "dotted" variables. So, it seems if bash is required to make them work then it should be the default; regardless of if it's easy to install or not.

[tianon]

Using a shell at all is not a requirement for using this image -- invoking Java directly does not suffer from this, nor does invoking Java from an installed Bash shell, so I'm still inclined to say this definitely is not an issue we can really "solve" in the base image. Just installing bash will not be sufficient for many cases where this bug is currently being hit to actually be "fixed" since their script will also have to be updated to use /bin/bash instead of /bin/sh.

I'd love to see some documentation from upstream Java where they promote the use of environment variables with periods in them, but regardless I just don't see anything actionable here beyond perhaps a small blurb in the documentation for the Alpine image variants which notes that the default /bin/sh will drop environment variables which have periods in their names.

[Aaron2Ti]

might related docker-library/python#331

[liudonghua123]

I spend a whole day to figure out this strange issue, in the end I changed the env variable name without dots. But I did not know the root case. Now I see the whys, thanks.

[keremsahin1]

Thanks for this. I've also spent half a day on this until reading this issue. Then, I printed all the environment variables inside Java application and voila! The ones with dots are gone.