Compile time warning whenever AccountInfo or UncheckedAccount is used

[armaniferrante]

We should emit warnings from anchor build whenever these types are used. To suppress the warnings, a special comment can be added. For example, SAFETY: or CHECK: , as is commonly done with unsafe code in rust.

[armaniferrante]

Might even be worth making this an error.

[acamill]

What's the best practice for account passed for CPI to non anchor program?

• UncheckedAccount
• AccountInfo
• Account with wrappers, although checked at the final destination... ?

[armaniferrante]

Account with wrappers is my preferred solution. See how we do this for the spl token program and others here https://github.com/project-serum/anchor/blob/master/spl/src/token.rs.

[Flaque]

If not AccountInfo, what's the best way to refer to a PDA?

ie, is this bad?

#[account(
  init,
  payer=user,
  token::mint = mint,
  token::authority = escrow_authority,
)]
pub escrow: Account<'info, TokenAccount>,

#[account(
  seeds=[b"authority", escrow.key().as_ref()],
  bump=escrow_authority_bump,
)]
pub escrow_authority: AccountInfo<'info>,

[armaniferrante]

You can use SystemAccount<'info> to refer to an account owned by the system program, though if it's just a PDA used for nothing but signing, then a simple // CHECK: comment would be sufficient with UncheckedAccount. Since the seeds constraint will assert it is the correct address.

[Flaque]

then a simple // CHECK: comment would be sufficient with UncheckedAccount. Since the seeds constraint will assert it is the correct address.

I might be confused here. What's the difference between an UncheckedAccount and an AccountInfo? Why would be using either be bad? (other than not having the underlying data?)

[armaniferrante]

UncheckedAccount is a more accurate alias of AccountInfo. Other types, e.g., Account<T> have additional checks on them, for example, the owner and the type of data, which make them a safer alternative. If you use UncheckedAccount, you need to manually do such account checks on your own.

[Flaque]

Ah, then can I make a request that UncheckedAccount doesn't error or warn? If it does, it might discourage folks from creating composable programs.

For example, if SPL Token's owner field was required to be a SystemAccount, then most programs wouldn't be feasible to be built, because you couldn't make the owner a program.

But also, I dunno anything and I might be thinking about this wrong.

[tomlinton]

I can take this one.

Ah, then can I make a request that UncheckedAccount doesn't error or warn? If it does, it might discourage folks from creating composable programs.

I think we just want people to pause and think about what they are doing, and hopefully enumerate the possible security issues if there is no restrictions on the account. It'll be easy to get around with the comment.