Guide for parachain teams

[jak-pan]

We're working on implementing parity signer for HydraDX and Basilisk but I am struggling with finding information about either getting the chains to the signer itself, or getting a verifier certificate in, to be able to show that the chain info and the metadata that you are getting in are indeed secure and saving steps for the users to overcome.

I've got a small draft of semi-automated process where we are storing signing keys in a secure organization / repo that will be able to prompt for signature once a draft release of any of our parachains is made. It's simplified for the sake of starting a conversation. Is this something that would allow us to be approved for parity signer + metadata portal?

P.S. really nice job with the parity signer. I'd love to see it adopted more!

[vas3k]

Hey!

On the Signer's side:

• I invite Alex @Slesarew to tell us more details below
• As I see it right now, no special action on the Signer side is required, most of the work will be on the Metadata Portal. There is an option to make a button "Add this network to Signer" - it generates a QR code and your users can add you into their signers without any hassle

On the Metadata Portal side:

• We are still working on normal documentation, so you will be our pioneers :) This means that your release team will probably have to have a lot of close contact with @prybalko, who is maintaining the portal right now. Feel free to send your questions to him or write then below.
• Here's roughly how metadata portal works:
  1. If you want to sign and host metadata updates yourself, fork this repo into your organization https://github.com/paritytech/metadata-portal/
  2. If you have any internal arrangements with Parity that I am not aware of, we can also sign your metadata with your keys and put it on our portal. I'm not a fan of this approach, but I heard someone wanted to do this.
  3. Configure your deployment. We simply use Github Pages + Cloudflare for a custom domain. Example.
  4. Configure your verifier and network in config.toml. In the simplest case, you simply specify the RPC endpoint. If you use a Polkadot-like release cycle on Github, then the Metadata Portal can parse metadata from release binaries.
  5. The main magic happens in update.yml job. It's a cronjob which runs every 2 hours and checks the RPC or releases for updates. If it sees new metadata, it opens a new PR in your repo with pre-generated and UNsigned QR codes, which you need to sign and commit (PR description will tell you how).
  6. After that the new metadata portal is redeployed

[Slesarew]

On top of this, I just have to add a few things.

• I was informed by legal team that we are not allowed to develop security protocols for 3rd parties, so please read all this as suggestions and use at your own risk
• Putting certificate key in CI is IMO a very hazardous thing, as CI secrets get lost occasionally and there is no sane revocation protocol for Signer certificates. Instead, the key could be stored on a special dedicated Signer device (as one of its keys; please remember to never use it for any other purposes but update signing - apparently there are attacks that could exploit it). The idea of protocol to use those keys is:
  1. Add network update to special Signer device (unsigned or signed by weak key)
  2. Go to Settings>Networks>select network>select update>Sign this metadata>select key
  3. Scan resulting QR into PC and then follow metadata portal instructions
• Signing metadata updates with general certificate is going to be available soon; roughly speaking, all you need to do for that is maintain your official metadata portal and inform Parity releasing team of its address, then things should go mostly automatically. I'll post separate process description later when I get infosec and legal approvals.

[Slesarew]

Also please be aware of #1050 and if it is related to your network - please join discussion.

[Slesarew]

Also if you are willing to get into slightly more complicated management, metadata could be fetched from network through RPC calls or extracted from wasm binary before it is deployed. The latter allows preparing metadata to publishing before network is upgraded, so that the delay is minimal. Consider if you need/want to do that with understanding, that recalling signed update will probably be seen as bad thing by community, but at the same time publishing timely updates would look cool.

[pgolovkin]

Hi! @jak-pan You raised a great topic! I have some experience with the Metadata portal in terms of Omni application development. The Metadata portal was forked and now it's hosted on my personal account. A few parachains were successfully added and we're using Parity Signer mobile application for signing transactions in Acala, Statemine and other parachains while developing the Omni application. We're trying to solve the following issues:

1. How to make the metadata updates at the time. So that users won't wait until the metadata update on the Metadata portal.
2. How to make the signing automatically.

For the 1st point the update job may be run more frequent (every 1 hour) with option to be started manually. For the 2nd point the github CI may be used but seems that it's not a really good idea.

@Slesarew could you please explain in details how the metadata may be updated from the WASM file before the runtime upgrade?

[Slesarew]

If you have a valid runtime binary, metadata could be extracted from it by many tools, some of which do not require to run this metadata. We've added this function to generate_message tool some time ago. Provided you have wasm file you are certain about (not sure who except network maintainers/releasers could have that), you can feed it to generate_message in a manner similar to this:

cd rust/generate_message
cargo run unwasm -payload westend_runtime-v9150.compact.compressed.wasm

where westend_runtime-v9150.compact.compressed.wasm is path to binary, and get metadata file similar to one that could be fetched from running network. With this, you proceed with signing and publishing normally. This flow is about to be added to metadata portal, IIUC, but could already be used in this less automatic manner.

Edit: for this to work, you need to populate database in generate_message with specs of this network, so that you'll have genesis hash that is not stored in runtime file.

[jak-pan]

Closing as no longer relevant :)