In coordination with the other HIP, I think I'm not understanding the intent here.

I thought decoupling miner signing from full firmware image signing was the goal, but this GPG approach seems to only provide verification at the miner build step? Meanwhile, the intent of the miner update HIP was to enable a distinct miner update from the firmware image update process. Therefore, verification needs to occur at the update not at the build step?

@lthiery this HIP was written to address the following topic of discussion in isolation.

2. How to think about separating consensus/blockchain related firmware signing from Hotspot-specific bits such that a separate entity (like a foundation) could hold signing power for the blockchain part

I purposely wrote it before the other HIP so that topic (see 3) would not overly-constrain the design space and prematurely influence my decisions.

3. How to allow Hotspot owners to specify and deliver their own firmware updates

I wanted to capture what the easiest ways to sign miner software releases are in the absence of alternative OTA firmware updates. After talking to @amirhaleem I now understand that whole point of separating miner for signing is to enable alternative OTA firmware updates.

You are correct in concluding that signing a Git tag (this GPG approach) or signing a gzipped tarball of the source (roughly equivalent) at some Git tag does not work for verifying OTA firmware updates.

You'll also notice that the scope of the alternative OTA firmware updates was reduced to just the miner. The idea to update miner independently of the rest of the Hotspot firmware arose from discussions with the Blockchain Engineering team.