concourse: Certificate Propagation Breaks Alpine OpenJDK Images

@vito This doesn’t seem like a viable solution for the reasons that @elgohr mentions. Effectively, you’re deleting a part of the container image that that image depends on. Forcing the resource to work around this abnormal (at least in my experience) in that it requires the resource to assume that the image it’s based on is fundamentally broken.

Where I think the feature has gone wrong is the replacement of existing certificates rather than the addition of new ones. Using the BOSH trusted certificates feature, you’ll see that they are additive in nature, not substitutive. The root cause of the issue with Alpine OpenJDK is that you’ve deleted a set of certificates that already existed. I believe that a strategy that adds certificates rather than mounting a replacement filesystem is a better solution to this issue.

@elgohr Of course this feature doesn’t work for Windows. It doesn’t need to; resources don’t run on Windows, and we don’t perform rootfs isolation on Windows. The issue you linked was a regression that we fixed prior to even releasing the feature. No one was impacted.

I know you don’t like the feature right now and it broke a few Java-implemented resources, but I really don’t appreciate how this is being blown out of proportion to suggest that the whole feature is fundamentally unsound. It’s not going to get us anywhere useful. For a ton of people this feature has added a ton of value already. We launched it to collect feedback, see what breaks, and iterate. With this feature being in such a complicated domain, we didn’t expect to nail it the first time, but it can at least be turned off so any breakage can be mitigated.

If we actually want to move forward with this, I could see an avenue where we mount the certs to a more explicit location, and expect the resource to pull them in somehow, though that will involve work for every resource author to adopt. Perhaps we could synchronize it with the new resource interface, to further incentivize resource authors to adopt it? In any case, I absolutely don’t want each resource author to implement explicit cert/SSL settings in the user-visible source config as it’s a UX consistency nightmare, and one of the big reasons this issue was opened in the first place.

Re: configuring it via BOSH, the BOSH-y way to manage trusted certs (at least for all the folks that really wanted this feature) is to use the director’s CA certificate propagation feature, wherein a given set of certs will automatically be added to each VM’s trust store. This is especially common for adding your company’s (or PCF’s) own CA. This is the type of automation (which is also commonly done with Chef and other tools) that this feature is designed to work with natively.