v1.4.4

One dependency bump. No breaking changes.

Default dockerize bumped 0.13.0 → 0.15.1

dockerize 0.13.0 carries nine HIGH Go stdlib CVEs compiled into the binary (net/http, crypto/tls, encoding/xml, net/url, html/template, golang.org/x/net/idna). Any image built on the crucible default therefore failed rake scan on the dockerize binary alone, even with a completely clean Alpine package set.

Measured on container-keepalived:

                            0.13.0              0.15.1
alpine                      0                   0
usr/local/bin/dockerize     9 HIGH              0
rake scan                   exit 1              exit 0

Templating behaviour is unchanged: verified by rendering a keepalived.conf and passing keepalived --config-test.

Why this is only surfacing now

This is a pre-existing condition, not a regression. Repos with hand-written pipelines frequently omitted rake scan; the generated pipeline from v1.4.3 includes it, so the finding became visible on the first generated build. Images built before this have been carrying these CVEs all along.

tini, catatonit and container-entrypoint were checked at the same time and are already at their latest upstream releases. dockerize was the only stale pin.

Note for consuming repos

Run rake update && rake template and rebuild. A repo pinning dockerize_version in its own metadata.yaml vars: overrides this default and needs bumping separately.

Immediately after a release, releases/latest/download/ can serve the previous asset from some CDN edges for a few minutes. If rake update appears to pull the wrong version, use CRUCIBLE_REF=v1.4.4 rake install.