Sorry for my many edits as usual.
That one is true, was filed since users reported the issue, while I’m still not comfortable removing the counter increase, as documented here upstream: HOTP : do not increment counter when HOTP USB Security dongle is not connected ? · Issue #1266 · linuxboot/heads · GitHub
I have not yet myself validated threshold in upstream hotp-verification code to verify for sure if it’s a 5 or 10 counter difference that is tolerated but consider it a opsec issue in itself from end user. Who would want to boot without validating HOTP (firmware integrity attestation) more than 5 or 10 times is still unknown to me. What is the use of a security measure if its bypassed willingly over and over??
For the rest of the misinformation regarding Heads in current thread, i’m currently refraining putting the effort to clarify once again, since those concerns were addressed upstream and in other posts, even here in this forum.
I see different perspectives on trust, trustworthiness, what is considered secure in direct opposition with the concepts of ownership and auditability of what is trusted vs supply chain issues and actual security fiasco (the real security theater being at play). All of which relates to threat modeling and risk assessment.
Delegating trust seems to be the issue to debate here, outside of microcode/blobs openness and EOL issues which lead people to delegate trust into blobs for lack of better/affordable/available options. Mixing all of those concepts is dangerous, at best. Facilitating ownership should be the place for collaboration here. Pushing upstream for compiled binaries signature should be the solution here, accompanied with reproducible builds which voids the need for trust delegation once again. Ease auditability should be the focus, not delegating trust. Trust should be minimized, and peer review should replace faith.
Some previous posts and discussions:
Difference between measurements and sealing: https://github.com/osresearch/heads-wiki/issues/116
Explanation about Heads security mechanisms: Is Heads necessarily more secure? - #6 by Insurgo
Why secure boot is not necessary better: Frequently asked questions (FAQ) | Qubes OS
Legacy boot vs UEFI only and plan of deprecation dismissed: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal) - devel - Fedora Mailing-Lists