Version: v0.3.0 (API), Linux release install via get.hypeman.sh, ubuntu-latest (GitHub-hosted runner). Still present on main (eed540f: cmd/api/config/config.go defaults Registry.Insecure: false).
Symptom
With the builder image prepared and the base image mirrored, a build reaches its final step and fails:
#8 ERROR: failed to push 10.100.0.1:4973/builds/wimkkr6qogszrvqqsgv38qyi:
failed to do request: Head "https://10.100.0.1:4973/v2/builds/…/blobs/sha256:…":
http: server gave HTTP response to HTTPS client
Cause
The built-in registry rides the API's own listener, which serves plain HTTP. But registry.insecure defaults to false, and that flag is what the build manager hands the builder VM (lib/builds/manager.go → BuildConfig.RegistryInsecure), where it decides BuildKit's scheme (builder_agent/main.go: isHTTPS := !config.RegistryInsecure). The example config has no registry: section at all, so a default install ships the contradiction: an HTTP registry that instructs its only client to speak HTTPS.
Notably the API-side mirror pushes over HTTP regardless of the flag, which is why base-image mirroring works while the builder's push fails — two clients of the same registry with two TLS opinions.
Workaround
# /etc/hypeman/config.yaml
registry:
insecure: true
Suggested fix
Either derive the flag from what the listener actually is (the API knows whether it terminates TLS), or default registry.insecure: true to match the shipped listener, or at minimum document the required config line. Refusing to start a registry whose advertised scheme is known-wrong would also surface this at install time instead of at the first build's last step.
Found while building barista on hypeman — full journal evidence in our findings doc, §10.
Version: v0.3.0 (API), Linux release install via
get.hypeman.sh, ubuntu-latest (GitHub-hosted runner). Still present onmain(eed540f:cmd/api/config/config.godefaultsRegistry.Insecure: false).Symptom
With the builder image prepared and the base image mirrored, a build reaches its final step and fails:
Cause
The built-in registry rides the API's own listener, which serves plain HTTP. But
registry.insecuredefaults tofalse, and that flag is what the build manager hands the builder VM (lib/builds/manager.go→BuildConfig.RegistryInsecure), where it decides BuildKit's scheme (builder_agent/main.go:isHTTPS := !config.RegistryInsecure). The example config has noregistry:section at all, so a default install ships the contradiction: an HTTP registry that instructs its only client to speak HTTPS.Notably the API-side mirror pushes over HTTP regardless of the flag, which is why base-image mirroring works while the builder's push fails — two clients of the same registry with two TLS opinions.
Workaround
Suggested fix
Either derive the flag from what the listener actually is (the API knows whether it terminates TLS), or default
registry.insecure: trueto match the shipped listener, or at minimum document the required config line. Refusing to start a registry whose advertised scheme is known-wrong would also surface this at install time instead of at the first build's last step.Found while building barista on hypeman — full journal evidence in our findings doc, §10.