-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
"solana program set-upgrade-authority" uses SetAuthorityChecked instruction by default #29190
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just a few nits
@@ -288,6 +293,13 @@ impl ProgramSubCommands for App<'_, '_> { | |||
.conflicts_with("new_upgrade_authority") | |||
.help("The program will not be upgradeable") | |||
) | |||
.arg( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new_upgrade_authority
arg above (can't comment directly) should be updated to match how the upgrade_authority
arg is defined
cli/src/program.rs
Outdated
.arg( | ||
Arg::with_name("no_sign_with_new_authority") | ||
.long("no-sign-with-new-authority") | ||
.conflicts_with("final") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
final
already conflicts with new_upgrade_authority
so I think it's more clear to define this as requiring new_upgrade_authority
to be present.
.long("no-sign-with-new-authority") | ||
.conflicts_with("final") | ||
.takes_value(false) | ||
.help("Set this flag if you don't want the new authority to sign the set-upgrade-authority transaction."), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain more that the default behavior requires the new authority to sign to prevent mistakes in setting the upgrade authority? You can also warn that by opting out of this default behavior, users must be confident that they are setting the correct authority. Furthermore, if they intentionally are setting a new authority that can never sign, they should be instructed to use final
instead.
cli/src/program.rs
Outdated
@@ -288,6 +293,13 @@ impl ProgramSubCommands for App<'_, '_> { | |||
.conflicts_with("new_upgrade_authority") | |||
.help("The program will not be upgradeable") | |||
) | |||
.arg( | |||
Arg::with_name("no_sign_with_new_authority") | |||
.long("no-sign-with-new-authority") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about skip-new-upgrade-authority-signer-check
?
cli/src/program.rs
Outdated
program_pubkey, | ||
upgrade_authority_index: signer_info | ||
.index_of(upgrade_authority_pubkey) | ||
.unwrap(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use expect
here and say "upgrade authority is missing from signers" or something to that effect? Ditto for new_upgrade_authority
unwrap
below
cli/src/program.rs
Outdated
&tx, | ||
config.commitment, | ||
RpcSendTransactionConfig { | ||
skip_preflight: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that other bpf loader transactions use true
here but I don't see any reason for that. It'd be better to fail the transaction in preflight if the action isn't authorized or valid for some reason.
automerge label removed due to a CI failure |
@jstarry build failure seems unrelated to my PR? unclear.
|
@0xripleys please merge master into your branch, the fix is in master already |
Pull request has been modified.
done |
automerge label removed due to a CI failure |
seemed like another flake to me so i just updated the branch. lmk if there's something else i should do |
Thanks, but most times there's no need to update the branch because most of the CI failures just require retrying an individual job. @yihau do you mind helping make sure this PR gets through CI? I don't have buildkite access at the moment |
sure. will keep my eyes on this 👁️ |
…uction by default (solana-labs#29190) * set-upgrade-authority uses checked instruction by default * remove print statements * PR fixes
Problem
Accompanying CLI change for #28424
(Original issue: #27932)
Summary of Changes
--no-sign-with-new-authority
Added a basic unit test and also did some manual testing, note that the feature gate for SetAuthorityChecked doesn't seem to have been enabled yet.