Skip to content

Commit

Permalink
build framework and lint
Browse files Browse the repository at this point in the history
  • Loading branch information
Vale MacBeaver committed Feb 4, 2025
1 parent ecbfcc7 commit 6781a0e
Show file tree
Hide file tree
Showing 3 changed files with 13 additions and 6 deletions.
3 changes: 3 additions & 0 deletions framework/cached-packages/src/lib.rs
Original file line number Diff line number Diff line change
@@ -1,2 +1,5 @@
// NOTE: Diem generated code does not have
// recent lint rules introduced in 2024
#[allow(clippy::doc_lazy_continuation)]
pub mod libra_framework_sdk_builder;
pub mod libra_stdlib;
16 changes: 10 additions & 6 deletions framework/cached-packages/src/libra_framework_sdk_builder.rs
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@

#![allow(dead_code)]
#![allow(unused_imports)]
#![allow(clippy::too_many_arguments, clippy::doc_lazy_continuation)]
#![allow(clippy::too_many_arguments)]
use diem_types::{
account_address::AccountAddress,
transaction::{EntryFunction, TransactionPayload},
Expand Down Expand Up @@ -94,7 +94,8 @@ pub enum EntryFunctionCall {

/// Generic authentication key rotation function that allows the user to rotate their authentication key from any scheme to any scheme.
/// To authorize the rotation, we need two signatures:
/// - the first signature `cap_rotate_key` refers to the signature by the account owner's current key on a valid `RotationProofChallenge`,demonstrating that the user intends to and has the capability to rotate the authentication key of this account;
/// - the first signature `cap_rotate_key` refers to the signature by the account owner's current key on a valid `RotationProofChallenge`,
/// demonstrating that the user intends to and has the capability to rotate the authentication key of this account;
/// - the second signature `cap_update_table` refers to the signature by the new key (that the account owner wants to rotate to) on a
/// valid `RotationProofChallenge`, demonstrating that the user owns the new private key, and has the authority to update the
/// `OriginatingAddress` map with the new address mapping `<new_address, originating_address>`.
Expand Down Expand Up @@ -539,7 +540,7 @@ pub enum EntryFunctionCall {
friend_account: AccountAddress,
},

/// will only succesfully vouch if the two are not related by ancestry
/// will only successfully vouch if the two are not related by ancestry
/// prevents spending a vouch that would not be counted.
/// to add a vouch and ignore this check use insist_vouch
VouchVouchFor {
Expand Down Expand Up @@ -1032,11 +1033,14 @@ pub fn account_revoke_signer_capability(
/// `OriginatingAddress` map with the new address mapping `<new_address, originating_address>`.
/// To verify these two signatures, we need their corresponding public key and public key scheme: we use `from_scheme` and `from_public_key_bytes`
/// to verify `cap_rotate_key`, and `to_scheme` and `to_public_key_bytes` to verify `cap_update_table`.
/// A scheme of 0 refers to an Ed25519 key and a scheme of 1 refers to Multi-Ed25519 keys. `originating address` refers to an account's original/first address.
/// A scheme of 0 refers to an Ed25519 key and a scheme of 1 refers to Multi-Ed25519 keys.
/// `originating address` refers to an account's original/first address.
///
/// Here is an example attack if we don't ask for the second signature `cap_update_table`:
/// Alice has rotated her account `addr_a` to `new_addr_a`. As a result, the following entry is created, to help Alice when recovering her wallet:
/// `OriginatingAddress[new_addr_a]` -> `addr_a`
/// Alice has had bad day: her laptop blew up and she needs to reset her account on a new one. (Fortunately, she still has her secret key `new_sk_a` associated with her new address `new_addr_a`, so she can do this.)
/// Alice has had bad day: her laptop blew up and she needs to reset her account on a new one.
/// (Fortunately, she still has her secret key `new_sk_a` associated with her new address `new_addr_a`, so she can do this.)
///
/// But Bob likes to mess with Alice.
/// Bob creates an account `addr_b` and maliciously rotates it to Alice's new address `new_addr_a`. Since we are no longer checking a PoK,
Expand Down Expand Up @@ -2353,7 +2357,7 @@ pub fn vouch_revoke(friend_account: AccountAddress) -> TransactionPayload {
))
}

/// will only succesfully vouch if the two are not related by ancestry
/// will only successfully vouch if the two are not related by ancestry
/// prevents spending a vouch that would not be counted.
/// to add a vouch and ignore this check use insist_vouch
pub fn vouch_vouch_for(friend_account: AccountAddress) -> TransactionPayload {
Expand Down
Binary file modified framework/releases/head.mrb
Binary file not shown.

0 comments on commit 6781a0e

Please sign in to comment.