Hey all, I’m testing out creating an SNS for my local environment. I’m following the SNS Local Doc and I’m stuck on step 3. ( Ask the SNS wasm modules canister to install an SNS)
I’ve asked another dev to try on their machine and they were able to replicate the error below:
(command to add to whitelist) $(dfx cache show)/ic-admin --secret-key-pem ~/.config/dfx/identity/$(dfx identity whoami)/identity.pem --nns-url "http://localhost:$(dfx info replica-port)" propose-to-update-sns-deploy-whitelist --added-principals "$(dfx identity get-wallet)" --proposer "$DEVELOPER_NEURON_ID" --proposal-title "Let me SNS" --summary "I am friendly."
(error) thread 'main' panicked at 'Invalid secret key.: InvalidPem(Custom { kind: InvalidData, error: "PEM file doesn't start with 'BEGIN PRIVATE KEY' block" })', registry/admin/src/main.rs:3196:48 note: run with RUST_BACKTRACE=1environment variable to display a backtrace
ic-admin up until very recently only supported ed25519 keys, whereas dfx now defaults to secp256k1 keys. Support for secp256k1 keys was added to ic-admin already, but I’m not sure if that made it into a dfx release yet. It will at the very least be in the next one.
For now it’s probably easiest to just use an identity generated with a dfx version older than 0.12.0. This should be an ed25519 key.
Side note: Don’t try for too long to generate a key with openssl. There’s some version incompatibilities between curve versions (I have no idea about that, but apparently it’s a thing?).
Thanks for the reply, I tried to revert back to 0.11.2 and ran dfx identity export developer-identity and it matched the pem file I was using with 0.12.1.
Am I misunderstanding the work around you suggested, or perhaps the identity.pem just persisted between changing versions?
I probably wasn’t clear enough in my instructions. It has to be an identity generated (referring to dfx identity new), not exported (referring to dfx identity export) with version <0.12.0.
I would hope that changing versions doesn’t mess up your private keys. Otherwise that would be the biggest possible problem that dfx could cause, probably even worse than randomly deleting canisters.
Using 0.13.1 I’m not able to add my local wallet principal to the whitelist.
How do we accept the proposal for propose-to-update-sns-deploy-whitelist?
Steps taken:
Running $(dfx cache show)/ic-admin --secret-key-pem ~/.config/dfx/identity/$(dfx identity whoami)/identity.pem --nns-url "http://localhost:$(dfx info replica-port)" propose-to-update-sns-deploy-whitelist --added-principals "$(dfx identity get-wallet)" --proposer "$DEVELOPER_NEURON_ID" --proposal-title "Let me SNS!" --summary "I am friendly."
succeeds in proposing: submit_proposal payload: UpdateAllowedPrincipalsRequest { added_principals: [ qvhpv-4qaaa-aaaaa-aaagq-cai, ], removed_principals: [], } submit_proposal for Let me SNS! response: Ok(proposal 5) proposal 5
But no proposal shows up in the local NNS frontend and running $(dfx cache show)/ic-admin --nns-url "http://localhost:$(dfx info replica-port)" get-provisional-whitelist
gives thread 'main' panicked at 'Error getting value from registry: Key not present: provisional_whitelist', rs/registry/admin/src/main.rs:4485:13 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
and dfx sns deploy gives ... Caller is not in allowed principals list. Cannot deploy an sns ...
Running dfx canister call nns-governance get_pending_proposals
shows the pending proposals to add wallet to whitelist
With some serious frontend hacking from @rem.codes we found out that you can only acces the proposal by manually editing the url in the browser to load the proposal for adding the wallet principal to the whitelist!
http://qsgjb-riaaa-aaaaa-aaaga-cai.localhost:8080/#/proposal/3 in case you start from scratch
@peterparker any idea why it is not showing up in the voting tab?
The URL seems incorrect. We switched to query parameters months ago and in last (or one of the recent version) of NNS-dapp we proprosed on mainnet the backwards compatibility for hashbang urls was removed.
e.g. on mainnet https://nns.ic0.app/proposal/?proposal=93763
so yours above link is probably http://qsgjb-riaaa-aaaaa-aaaga-cai.localhost:8080/proposal/?proposal=3.
If it’s the solution to yours issue may I ask: did you compose the link manually or where did you got it?
Ahhhh it’s because dfx nns install probably deploy an old version of NNS-dapp () and therefore you have to manually convert urls.
I know the team couldn’t upgrade to a newer version of II (currently dfx nns install deploys a super old II UI) because of some pipeline issue. I asked about this few weeks ago, maybe it’s the same for the dapp. I’ll ping them again.
Oh I see, we are probably speaking of two different. Screenshot looks good (for an old version of Nnsdapp and beside the fact that the type of the proposal is undefined for some reason)