Can't update metadata from a different signed key

[lucasvo]

I used to create my own chain metadata to load to my signer but am now using a different metadata portal to load it onto signer. Why is there no way to change the signer and load new metadata? Wiping the entire device seems completely unnecessary and will require me to end countless derivation paths and chain metadata from many different sources again.

I understand why you want to prevent people from loading random metadata and overwriting something they shouldn't, but there are many many reasons why this should not be limited to one signer:

1. The metadata portal can go offline (for example because the original dev team does not maintain the chain anymore)
2. The key used to sign can get lost and needs to be replaced
3. I decide that I no longer want to trust the metadata portal I was previously using and want to generate and load my own metadata

[lucasvo]

For reference this is the error I'm hitting: https://github.com/paritytech/parity-signer/blob/224d3dc034993106c8eafd333cabb4057725f38b/rust/definitions/src/error.rs#L1232

[Slesarew]

There is no need to wipe device in this particular case, as here you only need to load network specs signed with the same verifier certificate as the metadata you are trying to download. The metadata portal should always provide add_specs payload along with load_metadata updates for this scenario. Metadata portal maintained by Parity has this under "add to Signer" button on the bottom to the right from QR video, I think other portals could be expected to update to this state soon.

@goldsteinsveta @prybalko please see here real example of add_specs usage.

Limiting verifier for a network (although different networks could have different verifiers at the same time) to one is a temporary solution (there would be no verifiers as soon as #898 gets done) that is sufficiently safe and foolproof and at the same time is not too confusing. For all scenarios you mention, it makes sense to wipe the whole Signer as it is generally simpler then analyzing how and when the certificate stopped being trustworthy/usable. Hopefully these events would be rare. We are working on making wipe and restore even simpler now by adding derivation export and import and bananasplit integration. Bulk derivation import already works in v5.0.0, import payload could be made with generate_message crate.

[lucasvo]

I linked to the wrong error message. The scenario I was in is that I first updated the metadata with a local version of the metadata portal on my own host. I then while traveling had to update metadata.

For all scenarios you mention, it makes sense to wipe the whole Signer as it is generally simpler then analyzing how and when the certificate stopped being trustworthy/usable. Hopefully these events would be rare.

Why? In this case I literally had to find a safe and private place in the middle of a business trip to spend an hour sit down, write down every seed phrase on paper, backup all derivation paths, verify all information twice. Wipe it and add it all again. If you use more than one key, several networks etc. this easily takes an hour or two of critical work with no room for errors that is completely unnecessary. If anything had gone wrong during that time, I would have had to take the next flight to a place where I could actually restore a seed phrase and then recover it.

Let's say I use 8 parachains regularly. If just one of the metadata portals changes their keys I will have to go through the above process again.

That said, #898 would solve this problem nicely. I hope this can be implemented soon.

[lucasvo]

It seems like a side effect from this is that you also don't allow people to remove and add networks. I've just heard from a user who removed the network because scanning the multi-part QR code didn't work thinking something was wrong with it only to now be presented with this error message:

I believe these rules are too strict and achieve the opposite of what they should: they teach users that they constantly need to reset their signers and re-enter the seed phrase.

[goldsteinsveta]

more arguments to make signing rules less strict are also here https://github.com/paritytech/parity-signer/issues/904

[Slesarew]

This is safety feature; security has identified an attack that could be performed if removing networks without full seeds wipe is allowed (that, again, would be elegantly fixed by abovementioned feature).

I'm quite sure that after gaining some experience people will stop making these mistakes and/or get subscribed to single trusted general verifier - removing networks signed by general certificate without wipe is allowed.

Getting some practice with recovery (and making sure you have all that is needed for recovery) is quite useful IMO. We still should document all of this nicely, that is true.

[jak-pan]

It seems like a side effect from this is that you also don't allow people to remove and add networks. I've just heard from a user who removed the network because scanning the multi-part QR code didn't work thinking something was wrong with it only to now be presented with this error message:

I believe these rules are too strict and achieve the opposite of what they should: they teach users that they constantly need to reset their signers and re-enter the seed phrase.

We were using metadata portal by nova https://nova-wallet.github.io/metadata-portal/#/basilisk which recently switched their signer certificate (which can happen to anybody and I think should be the case) requiring everybody to wipe the accounts. Which TBH heavily sucks. It's not a matter of security if you present the information that -> the signing certificate doesn't match the original. Yes, I know. I would like to proceed instead of going back to my cold storage and losing money in the process because I have to wait or travel. Imagine a situation parachain is under attack and we need to perform emergency update and this happens.