Pin iPXE to v2.0.0-fog.7 - #1188
Merged
Merged
Conversation
Makes HTTPS netboot work at all against a FOG server whose web
certificate is issued by FOG's own CA -- which is every -S install that
has not supplied a public certificate.
FOG issues its Web CA with a CRITICAL nameConstraints extension, on
purpose: it is what stops a compromised web leaf from being usable to
impersonate anything outside this server's own names. Upstream iPXE has
no parser for that extension, and a critical extension a validator
cannot parse is one it must reject. So the Web CA was rejected before
the leaf was ever considered, and every client died at the first chain
with
Operation not supported (https://ipxe.org/3c16e283)
then reboot-looped. The two available fixes were to stop constraining
the CA, or to teach iPXE the extension. v2.0.0-fog.7 does the second:
permittedSubtrees and excludedSubtrees over dNSName and iPAddress,
enforced across the whole validated path, with constraint types iPXE
cannot evaluate refused at parse time so an unenforceable constraint
fails closed rather than being skipped. Reasoning and the rejected
alternatives: the ADR on working-1.6,
docs/adr/0016-ipxe-enforces-x509-name-constraints.md (this branch keeps no
docs/adr tree).
Servers do not self-heal. /tftpboot is only rewritten when the
installer re-runs. On this branch every https install rebuilds iPXE
locally and unconditionally -- there is no build stamp and no manifest
comparison here -- so a re-run picks the patched sources up by way of
prepareiPXEsource() checking the tree out at $ipxeVer, and overwrites
the old binaries outright.
mastacontrola
force-pushed
the
pin-ipxe-v2.0.0-fog.7-dev
branch
from
August 18, 2026 14:23
dd90633 to
aebbea7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same fix as #1187 on
working-1.6, and this branch has the same bug:_nameConstraints()here writesnameConstraints = criticalinto both intermediates too, so a 1.5 server's Web CA is rejected by stock iPXE for exactly the same reason.Makes HTTPS netboot work at all against a FOG server whose web certificate is issued by FOG's own CA — which is every
-Sinstall that has not supplied a public certificate.The Web CA carries a critical
nameConstraintsextension on purpose: it is what stops a compromised web leaf from being usable to impersonate anything outside this server's own names. Upstream iPXE has no parser for that extension, and a critical extension a validator cannot parse is one it must reject. So the Web CA was rejected before the leaf was ever considered, and every client died at the first chain withthen reboot-looped.
fog-ipxe#6 teaches iPXE the extension rather than weakening the CA —
permittedSubtrees/excludedSubtreesover dNSName and iPAddress, enforced across the whole validated path, with constraint types iPXE cannot evaluate refused at parse time so an unenforceable constraint fails closed rather than being silently skipped. Full reasoning is in ADR 0016 onworking-1.6(#1184); this branch keeps nodocs/adrtree.Verified end to end on a UEFI Secure Boot VM against the 1.6 server: the stock binary fails to parse the Web CA; the patched one validates the chain and reaches the FOG boot menu over HTTPS. The binaries are the same build on both branches.
What a re-run does here
/tftpbootis only rewritten when the installer re-runs. On this branch everyhttpsinstall rebuilds iPXE locally and unconditionally — there is no build stamp and no manifest comparison infetchipxeasset()— so the re-run picks up the patched sources by way ofprepareiPXEsource()checking$buildipxesrcout at$ipxeVer, and overwrites the old binaries outright.working-1.6's stamp-and-manifest layer is not present here, which is why the two PR descriptions differ on this point.🤖 Generated with Claude Code