Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sign miner HIP #12

Merged
merged 3 commits into from
Mar 23, 2020
Merged

sign miner HIP #12

merged 3 commits into from
Mar 23, 2020

Conversation

fvasquez
Copy link
Contributor

@fvasquez fvasquez commented Feb 19, 2020

@fvasquez fvasquez changed the title Add sign miner HIP sign miner HIP Feb 19, 2020
Copy link
Contributor

@lthiery lthiery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

0000-sign-miner.md Outdated Show resolved Hide resolved
0000-sign-miner.md Outdated Show resolved Hide resolved
0000-sign-miner.md Outdated Show resolved Hide resolved
@fvasquez
Copy link
Contributor Author

fvasquez commented Feb 20, 2020

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.

  1. 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.

  1. 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.

@fvasquez fvasquez merged commit d67a6df into master Mar 23, 2020
@fvasquez fvasquez deleted the sign-miner branch March 23, 2020 17:32
@fvasquez fvasquez mentioned this pull request Mar 23, 2020
fvasquez pushed a commit that referenced this pull request Mar 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants