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