Skip to content

feat(lang, cli): re-added legacy idl support under legacy-idl feature flag#4455

Open
tiago18c wants to merge 6 commits into
otter-sec:masterfrom
tiago18c:legacy-idl-support
Open

feat(lang, cli): re-added legacy idl support under legacy-idl feature flag#4455
tiago18c wants to merge 6 commits into
otter-sec:masterfrom
tiago18c:legacy-idl-support

Conversation

@tiago18c
Copy link
Copy Markdown
Collaborator

Summary

Added legacy IDL code generation under legacy-idl feature flag.
Added support to the above on the CLI via the anchor legacy-idl ... command (all previous command except Build and Convert).

@vercel
Copy link
Copy Markdown

vercel Bot commented Apr 23, 2026

@tiago18c is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

@tiago18c
Copy link
Copy Markdown
Collaborator Author

@jamie-osec On the lang side should anything be done re the recent zero discriminator issues?

@jamie-osec jamie-osec self-assigned this May 1, 2026
tiago18c added 2 commits May 7, 2026 20:34
…ncheckedAccount, overall cleanup and better deprecation messaging on usage. Remmoved stale feature from tests.
@tiago18c tiago18c force-pushed the legacy-idl-support branch from 8c9473a to 82d33ef Compare May 7, 2026 19:37
@tiago18c tiago18c marked this pull request as ready for review May 7, 2026 19:38
@tiago18c tiago18c requested a review from jamie-osec May 7, 2026 19:38
Comment thread cli/Cargo.toml Outdated
Comment thread lang/syn/src/codegen/program/idl.rs Outdated
@tiago18c tiago18c requested a review from jamie-osec May 8, 2026 20:23
@jamie-osec
Copy link
Copy Markdown
Collaborator

Hmm, not necessarily a blocker, but I notice that idl_accounts_and_functions and __idl_dispatch (in generate_legacy_idl_mod) are basically constants, which don't use any user types or data. Maybe we can define these as regular functions in lang and just call into them?
This means they can be shown in rustdoc and are easier to work on from a dev perspective.

@tiago18c
Copy link
Copy Markdown
Collaborator Author

The #[derive(Accounts)] macro is dependent on the program ID crate::ID here which is user defined.

Is there a workaround this?
I do agree this would be better, unsure how to

@jamie-osec
Copy link
Copy Markdown
Collaborator

Hmm, true. Any idea about the context for

// Hacky workaround because of some internals to how account attribute
        // works. Namespaces are the root of most of the problem.

Maybe we can fix that?
Again not necessarily a blocker so we could go ahead and merge as is if there's no immediate ideas

@tiago18c
Copy link
Copy Markdown
Collaborator Author

Goes all the way back to the file creation and was never changed until it was later removed in #4252

@jamie-osec
Copy link
Copy Markdown
Collaborator

On the lang side should anything be done re the recent zero discriminator issues?

I think if we require buffer to be a signer we should be able to close the buffer takeover attack path. The other issue wrt hijacking IdlCreateAccount is, I think, lower impact.

@tiago18c
Copy link
Copy Markdown
Collaborator Author

Trivial and shouldn't affect anyone. CreateAccount and CreateBuffer were already done in a single transaction.

@jamie-osec
Copy link
Copy Markdown
Collaborator

This looks basically ready, would you mind adding some brief tests that exercise each CLI option/instruction variant, and one to test that the account takeover is closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants