Questa guida è pensata come riferimento per gli sviluppatori che vogliono implementare build verificate per i loro programmi su Solana. Tratteremo cosa sono le build verificate, come utilizzarle, considerazioni speciali e best practice per garantire l'autenticità del tuo programma sulla blockchain.

Cosa sono le build verificate?

Le build verificate assicurano che il programma eseguibile che distribuisci sulla rete di Solana corrisponda al codice sorgente nel tuo repository. Grazie a questo, sviluppatori e utenti possono avere la certezza che il programma in esecuzione sulla blockchain corrisponda esattamente alla base di codice pubblica, promuovendo trasparenza e sicurezza.

Il processo di verifica prevede il confronto dell'hash del programma sulla blockchain con l'hash del programma compilato localmente dal codice sorgente. Questo garantisce che non ci siano discrepanze tra le due versioni.

Sebbene una build verificata non debba essere considerata più sicura di una build non verificata, la build permette agli sviluppatori di verificare autonomamente che il codice sorgente corrisponda a ciò che è distribuito sulla blockchain. Utilizzando il codice sorgente, uno sviluppatore può quindi validare cosa esegue il codice quando invia una transazione.

La pipeline di build verificate è stata ideata e viene mantenuta da Ellipsis Labs e OtterSec. Per maggiori dettagli, segui la guida nel repository originale delle build verificate e il processo di verifica della build direttamente nella suite di strumenti Anza, una volta supportato.

Come funziona?

Il processo di verifica viene effettuato confrontando l'hash del programma onchain con l'hash del programma compilato localmente dal codice sorgente. Compili il tuo programma in un ambiente controllato utilizzando Solana Verify CLI e Docker. Questo garantisce che il processo di compilazione sia deterministico e coerente su diversi sistemi. Una volta ottenuto l'eseguibile, puoi distribuirlo sulla rete Solana. Durante il processo di compilazione verrà creato un PDA del programma verify. Questo PDA contiene tutti i dati necessari per verificare il programma. Il PDA contiene l'indirizzo del programma, l'URL git, l'hash del commit e gli argomenti utilizzati per compilare il programma.

Utilizzando i dati nel PDA, chiunque può eseguire localmente il comando del programma verify e controllare se il programma è stato compilato dal codice sorgente fornito. Quindi tutti possono verificare autonomamente in modo completamente trustless o possono eseguire la propria API di verifica mantenuta da OtterSec per fornire un punto di accesso facile agli utenti per controllare la verifica. Puoi già vedere queste chiamate API utilizzate in Solana Explorer e SolanaFM, tra gli altri.

Perché dovrei usare build verificate?

L'utilizzo di build verificate offre i seguenti vantaggi:

• Sicurezza: garantisce che il programma in esecuzione onchain corrisponda al codice sorgente, prevenendo alterazioni dannose.

• Trasparenza: permette ad altri utenti e sviluppatori di convalidare che il programma onchain sia affidabile confrontandolo con il codebase pubblico.

• Fiducia: aumenta la fiducia degli utenti, poiché le build verificate dimostrano che il comportamento onchain del tuo programma è allineato con il tuo codice pubblico. Quando costruisci programmi verificabili, riduci al minimo i rischi associati all'esecuzione di codice non autorizzato o dannoso. Garantisce inoltre che tu rispetti le migliori pratiche e offri ai ricercatori di sicurezza un modo semplice per contattarti. Anche i wallet e altri strumenti possono consentire più facilmente le transazioni dal tuo programma finché è verificato.

• Individuabilità: quando fornisci una build verificata del tuo programma, tutti possono trovare il tuo codice sorgente, la documentazione, l'SDK o l'IDL del programma e possono anche contattarti facilmente tramite GitHub in caso di problemi.

Come creo build verificate?

Per creare build verificate, dovrai seguire questi passaggi:

Riepilogo:

• Effettua il commit del tuo codice in un repository pubblico
• Crea una build verificata in Docker
• Distribuisci la build verificata
• Verifica il programma distribuito tramite API pubblica

Se verifichi il tuo programma che non è stato compilato in un container Docker, molto probabilmente fallirà perché le build dei programmi Solana non sono deterministiche su sistemi diversi.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

cargo install solana-verify

cargo install solana-verify --version $VERSION

cargo install solana-verify --git https://github.com/Ellipsis-Labs/solana-verifiable-build --rev 13a1db2

[workspace]
members = ["program/programs/*"]
resolver = "2"

[profile.release]
overflow-checks = true
lto = "fat"
codegen-units = 1

[profile.release.build-override]
opt-level = 3
incremental = false
codegen-units = 1

[package]
name = "waffle"
version = "0.1.0"
edition = "2021"

[lib]
name = "waffle"
crate-type = ["cdylib", "lib"]

[dependencies]
solana-program = "2.1.0"

solana-verify build

solana-verify build --library-name $PROGRAM_LIB_NAME

solana-verify get-executable-hash target/deploy/$PROGRAM_LIB_NAME.so

solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID --with-compute-unit-price 50000 --max-sign-attempts 100 --use-rpc

solana-verify get-program-hash -u $NETWORK_URL $PROGRAM_ID

solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH --commit-hash $COMMIT_HASH --library-name $PROGRAM_LIB_NAME --mount-path $MOUNT_PATH

solana-verify verify-from-repo --remote -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

solana-verify remote submit-job --program-id <program-id> --uploader <address>

solana-verify remote get-job-status --job-id <job-id>

Come verificare il tuo programma quando è controllato da un Multisig come Squads

Affinché la verifica remota funzioni, devi scrivere i dati di verifica in un PDA firmato dall'autorità del programma. Se il tuo programma è controllato da un multisig, puoi esportare questa transazione di scrittura PDA e inviarla tramite Squads Protocol o un'altra soluzione multisig di tua scelta.

solana-verify build

solana config set --url "PayedMainnetRPCAddress" // the public endpoint will be rate limited too much
solana program deploy target/deploy/verify_squads.so

solana-verify verify-from-repo https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader <your program authority> --encoding base58 --compute-unit-price 0

P6vBfcPaaXb8fZoT3NBAYEcdtEj7tubA1k2gBxmFKZ3UWF5YyrmDMFTvLKALCJoUuRsPAjMckudYruCu3eeWQtuDrFbEMLxLFutnKXac974fnkMivcwUdY66VLjbxQT6ATmcy7F4hBtz1G4P1h6iBJLhb8WtrtgY3i4qq45MUEb7RjuMEfUFXKrNgPdGxkz5xvMHq3dxKRcpmEK5k2DkeW6SUQYBVe19Ga3B9GyhTX8k3CMt9JCEah13WyRnQd8GjoK6sTEvGJym6xDNvmd8yiJYSNcaYwEJsjHEUf4Yh6kAC7ki2KRvVAr3NVe1gjqK9McrwSQjtUatvydTG8Zovcr7PPUEMf3yPMgKXjZLB2QpkH63yTTYdNAnWFuv9E6b6nYRqye5XcNi436yKw5U14fXh65yK34bgYLi9328UT1huJELsJU9BRGnGUmb6GWp6c2WL5BhnzgNTSnt9TXFfEgUMzhvKzpVBxLP44hwqqBdyUhHFysCF37531PnmiESq8x1xou23xJ6FcQbc199754MkqQd7tX9CUznGzAEqHGkzn3VBoJnojsKtgYmiTYbdRsT1CU18MbYEE7WvGAvXyxxbpNzbAcc94HrnM6cqRGmwhEBroPfFghTdmzg9D

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD
--uploader <your program authority>

solana-verify build
solana program write-buffer target/deploy/verify_squads.so --with-compute-unit-price 50000 --max-sign-attempts 50

solana program set-buffer-authority Fu3k79g53ZozAj47uq1tXrFy4QbQYh7y745DDsxjtyLR --new-buffer-authority 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify export-pda-tx https://github.com/solana-developers/verify-squads --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

solana-verify remote submit-job --program-id 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD --uploader 3JG6ULvZVCrkKtSSskKNJGe8RNZGFe8Ruev9KUhxzK5K

Verification request sent with request id: b63339d2-163e-49ac-b55d-3454c1c2b5b3
Verification in progress... ⏳ [00:18:02] ✅ Process completed. (Done in 18
minutes) Program 6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD has been verified.
✅ The provided GitHub build matches the on-chain hash. On Chain Hash:
96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Executable
Hash: 96f8c3d9400258f7759408d1f6f8435b4a24d9b52f5a0340d97907e567cb8773 Repo URL:
https://github.com/Woody4618/verify-squads/tree/0fb0a2e30c15c51732c0ad5e837975a6f7bbc7ed
Check the verification status at:
https://verify.osec.io/status/6XBGfP17P3KQAKoJb2s5M5fR4aFTXzPeuC1af2GYkvhD Job
url: https://verify.osec.io/job/b63339d2-163e-49ac-b55d-3454c1c2b5b3

Verifica da immagine docker

Puoi anche verificare il tuo programma con un'immagine docker eseguendo il seguente comando:

solana-verify verify-from-image -e
examples/hello_world/target/deploy/hello_world.so -i
ellipsislabs/hello_world_verifiable_build:latest -p
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn

Questo comando carica l'immagine memorizzata in ellipsislabs/hello_world_verifiable_build:latest e verifica che l'hash del percorso eseguibile nel container corrisponda all'hash del programma on-chain fornito al comando. Poiché la build è già stata caricata in un'immagine, non è necessaria una ricostruzione completa dell'eseguibile, che può richiedere molto tempo.

Il Dockerfile che crea l'immagine ellipsislabs/hello_world_verifiable_build:latest si trova nel repository di ellipsis labs /examples/hello_world.

Di seguito è riportato l'output previsto:

Verifying image: "ellipsislabs/hello_world_verifiable_build:latest", on network
"https://api.mainnet.solana.com" against program ID
2ZrriTQSVekoj414Ynysd48jyn4AX6ZF4TTJRqHfbJfn Executable path in container:
"examples/hello_world/target/deploy/hello_world.so"

Executable hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Program hash:
08d91368d349c2b56c712422f6d274a1e8f1946ff2ecd1dc3efc3ebace52a760 Executable
matches on-chain program data ✅

Esempio di build verificata

Ecco un esempio di verifica di un programma di esempio con l'ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv utilizzando il codice sorgente da questo repository:

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Per impostazione predefinita, il comando verify-from-repo utilizza l'ultimo commit sul branch principale. Puoi anche definire un commit specifico nel caso in cui voglia continuare a lavorare sul repository utilizzando il parametro commit-hash: --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Infine, puoi anche verificare direttamente il programma tramite l'API di OtterSec:

solana-verify verify-from-repo https://github.com/solana-developers/verified-program --url YOUR-RPC-URL --remote --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --mount-path waffle --library-name waffle --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Il comando --remote invia una richiesta di build all'API di OtterSec, che attiva una build remota del tuo programma. Una volta completata la build, il sistema verifica che l'hash on-chain del tuo programma corrisponda all'hash dell'artefatto di build generato dal tuo repository.

Programmi popolari già verificati

Phoenix

solana-verify verify-from-repo -um --program-id PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY https://github.com/Ellipsis-Labs/phoenix-v1

Output finale:

Executable Program Hash from repo: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
On-chain Program Hash: 6877a5b732b3494b828a324ec846d526d962223959534dbaf4209e0da3b2d6a9
Program hash matches ✅

Squads V3

solana-verify verify-from-repo https://github.com/Squads-Protocol/squads-mpl --commit-hash c95b7673d616c377a349ca424261872dfcf8b19d --program-id SMPLecH534NA9acpos4G6x7uf3LWbCAwZQE9e8ZekMu -um --library-name squads_mpl --bpf

Nota che abbiamo dovuto specificare il library-name perché il repository Squads include più programmi. Utilizziamo il flag --bpf perché squads_mpl era stato precedentemente verificato con Anchor.

Output finale:

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
On-chain Program Hash: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Program hash matches ✅

Drift V2

solana-verify verify-from-repo -um --program-id dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH https://github.com/drift-labs/protocol-v2 --commit-hash 110d3ff4f8ba07c178d69f9bfc7b30194fac56d6 --library-name drift

Output finale:

Executable Program Hash from repo: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
On-chain Program Hash: e31d58edeabc3c30bf6f2aa60bfaa5e492b41ec203e9006404b463e5adee5828
Program hash matches ✅

Marginfi V2

solana-verify verify-from-repo -um --program-id MFv2hWf31Z9kbCa1snEPYctwafyhdvnV7FZnsebVacA https://github.com/mrgnlabs/marginfi-v2 --commit-hash d33e649e415c354cc2a1e3c49131725552d69ba0 --library-name marginfi -- --features mainnet-beta

Output finale:

Executable Program Hash from repo: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
On-chain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Domande frequenti

La mia verifica sta fallendo. Cosa devo fare?

Controlla questi problemi comuni:

• Firmatario errato: Conferma che il tuo firmatario sia l'autorità di aggiornamento del programma eseguendo solana program show YourProgramId
• Nessun PDA on-chain: Esegui solana-verify verify-from-repo -um e seleziona SÌ quando richiesto. Senza caricare il PDA, l'API non può recuperare i tuoi metadati di verifica.
• Discrepanza dati PDA: Aggiorna il tuo PDA se hai ridistribuito il tuo programma. I dati del tuo PDA devono corrispondere al programma distribuito.
• Hash del commit errato: Crea il tuo PDA usando l'hash del commit esatto che hai distribuito
• Differenze nell'ambiente di build: Usa Docker con solana-verify quando crei il tuo PDA

L'hash della mia build locale non corrisponde all'hash on-chain. Perché?

Di solito questo significa:

• Stai usando versioni diverse della toolchain Rust/Solana
• Le tue dipendenze sono state aggiornate tra una build e l'altra
• Non hai compilato in un container Docker
• Hai estratto il commit sbagliato

Risolvi questo problema compilando con solana-verify build in Docker usando l'esatto commit che hai distribuito.

Quanto tempo richiederà la mia verifica?

Aspettati questi tempi in base alle dimensioni del tuo programma:

• Programmi semplici: 1-5 minuti
• Programmi complessi: 5-15 minuti
• Programmi molto grandi: Fino a 30 minuti

Monitora i tuoi progressi utilizzando l'endpoint dello stato del lavoro.

Il mio programma è immutabile (nessuna autorità di aggiornamento). Come posso verificarlo?

Se il tuo programma non ha un'autorità di aggiornamento o è stato reso immutabile prima che potessi creare un PDA, abbiamo un indirizzo inserito nella whitelist per questa situazione. Contattaci all'indirizzo contact@osec.io e ti aiuteremo a far verificare il tuo programma.

Cos'è il PDA e perché è importante?

Il tuo PDA (Program Derived Account) consente la verifica trustless:

• Archiviazione On-Chain: Memorizza i tuoi metadati di verifica (URL del repository, hash del commit, parametri di build) on-chain in un PDA di proprietà del programma Otter Verify (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
• Collegamento Crittografico: Il tuo PDA è derivato dall'indirizzo del tuo programma, creando un collegamento immutabile ai tuoi dati di verifica
• Fiducia Decentralizzata: Chiunque può leggere il tuo PDA e verificare indipendentemente il tuo programma

Perché devo creare il PDA prima di utilizzare l'API?

L'API funziona solo con PDA on-chain perché:

• Trustless: L'API rifiuta dati arbitrari - utilizza solo ciò che la tua autorità di upgrade ha memorizzato on-chain
• Più Semplice: Fornisci solo signer + program_id; l'API ottiene tutto il resto dal tuo PDA
• A Prova di Manomissione: Il tuo PDA crea un registro immutabile che chiunque può verificare in modo indipendente
• Prova di Proprietà: Il tuo signer deve essere l'autorità di upgrade, dimostrando crittograficamente che controlli il programma

Con quale frequenza devo verificare il mio programma?

Verifica il tuo programma:

• Dopo ogni deployment o upgrade
• Quando aggiorni il tuo repository sorgente
• Non preoccuparti di rieffettuare la verifica altrimenti - l'API riverifica automaticamente tutti i programmi ogni 24 ore

Cosa succede quando effettuo l'upgrade del mio programma?

Segui questi passaggi dopo l'upgrade:

1. L'API rileva il tuo upgrade e rimuove la verifica del tuo programma.
2. Aggiorna il tuo PDA con i nuovi metadati di verifica:

solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

3. Invia una nuova richiesta di verifica utilizzando la tua autorità di upgrade
4. L'API verificherà la tua nuova versione confrontandola con il PDA aggiornato

Importante: Aggiorna sempre il tuo PDA utilizzando la tua autorità di upgrade con il nuovo hash del commit per il programma aggiornato.

Posso fidarmi dei risultati della verifica?

Sì - il sistema è progettato per essere trustless e verificabile in modo indipendente:

Cosa lo rende affidabile:

• PDA On-Chain: I metadati della verifica risiedono on-chain, non sono controllati da alcuna autorità centrale
• Prova dell'autorità di aggiornamento: Solo l'autorità di aggiornamento del tuo programma può creare/aggiornare il PDA
• Verifica indipendente: Chiunque può verificare leggendo il tuo PDA ed eseguendo solana-verify localmente
• Ri-verifica continua: L'API ri-verifica automaticamente tutti i programmi ogni 24 ore

Comprendi queste limitazioni:

• La verifica conferma che il sorgente corrisponde al deployment - NON che il tuo codice sia sicuro
• Rivedi sempre il codice prima di interagire con i programmi
• Verificato ≠ sottoposto ad audit o sicuro
• Controlla il repository e il commit nel PDA per confermare che provenga da una fonte attendibile

Come posso verificare un programma in modo indipendente?

Verifica qualsiasi programma da solo leggendo il suo PDA on-chain ed eseguendo la verifica localmente:

Passaggio 1: Leggi il PDA On-Chain

# Install solana-verify if you haven't
cargo install solana-verify

# Get the PDA data
solana-verify list-program-pdas --program-id YourProgramId...

Passaggio 2: Verifica localmente

# Verify using the repository and commit & other arguments from the PDA
solana-verify verify-from-repo \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program
  --commit-hash <commit-hash>
  ... (other arguments from the PDA)
# Confirm the hash output matches the on-chain program hash

Questo dimostra:

1. I metadati del PDA sono autentici (memorizzati on-chain)
2. Il codice sorgente nel repository del PDA corrisponde al programma distribuito
3. Non devi fidarti dell'API - verifica tutto da solo on-chain

Qualcun altro può verificare il mio programma senza permesso?

Sì, è per questo motivo che richiediamo che il firmatario sia l'autorità di aggiornamento. Consideriamo la verifica valida solo se il firmatario è l'autorità di aggiornamento.

Cosa mi serve per creare build verificabili?

Installa questi strumenti:

• Docker (per build deterministiche)
• Cargo (gestore di pacchetti Rust)
• Solana Verify CLI: cargo install solana-verify
• Un repository Git pubblico con il tuo codice sorgente

Posso verificare repository privati?

No - la verifica richiede codice sorgente pubblico:

• Il tuo PDA memorizza un URL di repository pubblico accessibile a tutti
• La verifica trustless dipende dall'accesso pubblico al codice
• Gli utenti devono leggere il tuo codice sorgente per capire cosa fa il tuo programma
• L'intero scopo è permettere agli utenti di verificare in modo indipendente che il sorgente corrisponda al deployment

I repository privati compromettono il modello di fiducia fondamentale del sistema di verifica.

Come posso verificare un programma controllato da Squads Multisig?

Segui questi passaggi per i programmi controllati da multisig:

# 1. Build and deploy normally
solana-verify build
solana program deploy <your-program.so> --program-id YourProgramId...

# 2. Verify locally first - confirm the hash matches
solana-verify verify-from-repo -um \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 3. Export the PDA creation transaction
solana-verify export-pda-tx \
  --program-id YourProgramId... \
  https://github.com/your-org/your-program

# 4. Execute the PDA transaction through your Squads Multisig interface

# 5. After multisig execution, trigger remote verification
solana-verify remote submit-job \
  --program-id YourProgramId... \
  --uploader YourMultisigAddress...

Fondamentale: Verifica sempre localmente (passaggio 2) per confermare che l'hash della build corrisponda prima di esportare la transazione PDA.

Conclusione

Utilizzare build verificate su Solana garantisce l'integrità e l'affidabilità dei tuoi programmi sulla rete e permette agli sviluppatori di trovare i tuoi SDK direttamente da Solana Explorer. Sfruttando strumenti come Solana Verify CLI e Docker, puoi mantenere build verificabili e sicure che si allineano con il tuo codice sorgente. Prendi sempre le precauzioni necessarie per utilizzare ambienti coerenti e considera soluzioni di governance per aggiornamenti e deployment sicuri.

Sicurezza + Disclaimer

Sebbene le build verificate siano uno strumento potente per garantire l'integrità dei tuoi programmi Solana, non sono completamente trustless nella configurazione predefinita. Le immagini docker sono create e ospitate dalla Solana Foundation.

Tieni presente che stai compilando il tuo progetto in un'immagine docker scaricata e che l'intera configurazione viene copiata in quell'immagine docker per la compilazione, incluse potenzialmente informazioni sensibili.

Se desideri avere una configurazione completamente trustless puoi compilare le immagini docker tu stesso e ospitarle sulla tua infrastruttura. In questo modo puoi essere sicuro che le immagini docker non siano state manomesse. Puoi trovare gli script per creare le tue immagini docker nel repository Verified builds e puoi effettuarne il fork ed eseguire le github actions tu stesso oppure validare che siano corrette.

Inoltre, per la verifica remota ti stai affidando in una certa misura all'API di OtterSec e a Solana Explorer.

L'API o Solana Explorer potrebbero potenzialmente visualizzare informazioni errate se compromessi.

Se desideri avere una configurazione completamente trustless puoi eseguire tu stesso la Verify API oppure eseguire la verifica del programma localmente utilizzando il comando verify-from-repo utilizzando i dati di verifica on-chain salvati in un PDA derivato dall'autorità di deploy del programma e dal programma di verifica.

Il programma di verifica è stato distribuito dal team OtterSec e non è ancora congelato, quindi può essere aggiornato in qualsiasi momento.

La Solana Foundation, OtterSec e il team di Ellipsis Labs non sono responsabili per eventuali perdite o danni che potrebbero verificarsi dall'utilizzo della pipeline dei build verificati.

Security.txt per i programmi Solana

Oltre ai build verificati, puoi anche aggiungere un file security.txt al tuo programma. In futuro, una volta implementato, il file security.txt conterrà la chiave pubblica del verificatore per un facile accesso ai dati di verifica archiviati nel PDA di verifica. Il PDA contenente tutte le informazioni necessarie per costruire e verificare un programma è derivato dall'indirizzo del programma e dalla pubkey del verificatore. Per impostazione predefinita, questa è la stessa pubkey che ha costruito e distribuito il programma. Ma può anche essere un'altra pubkey che può essere specificata nel file security.txt.

La funzionalità security.txt consente agli sviluppatori di incorporare informazioni di contatto e sicurezza direttamente all'interno dei loro smart contract Solana. Ispirata a securitytxt.org, questo approccio fornisce un modo standardizzato per i ricercatori di sicurezza di contattare i manutentori dei progetti, anche se conoscono solo l'indirizzo del contratto.

Perché utilizzare security.txt?

Per molti progetti, specialmente quelli più piccoli o privati, identificare gli sviluppatori partendo solo dall'indirizzo del contratto può essere difficile e richiedere molto tempo. Incorporare un file security.txt all'interno del programma garantisce che i ricercatori di sicurezza possano facilmente contattare le persone giuste, prevenendo potenzialmente sfruttamenti e assicurando segnalazioni tempestive di bug.

Come implementare security.txt

Per aggiungere un security.txt al tuo programma Solana, segui questi passaggi:

Aggiungi la dipendenza solana-security-txt al tuo Cargo.toml:

[dependencies]
solana-security-txt = "1.1.1"

Utilizza la macro security_txt! nel tuo contratto per definire le tue informazioni di sicurezza. Puoi includere dettagli di contatto, URL del progetto e persino una policy di sicurezza. Ecco un esempio:

#[cfg(not(feature = "no-entrypoint"))]
use {default_env::default_env, solana_security_txt::security_txt};

#[cfg(not(feature = "no-entrypoint"))]
security_txt! {
    name: "MyProject",
    project_url: "https://myproject.com",
    contacts: "email:security@myproject.com,discord:security#1234",
    policy: "https://myproject.com/security-policy",

    // Optional Fields
    preferred_languages: "en,de",
    source_code: "https://github.com/solana-developers/solana-game-preset",
    source_revision: "5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    source_release: "",
    encryption: "",
    auditors: "Verifier pubkey: 5vJwnLeyjV8uNJSp1zn7VLW8GwiQbcsQbGaVSwRmkE4r",
    acknowledgements: "Thank you to our bug bounty hunters!"
}

Una volta che le informazioni security.txt sono incorporate nel tuo programma, possono essere facilmente interrogate tramite strumenti come Solana Explorer, garantendo che i tuoi dettagli di contatto e sicurezza siano disponibili a chiunque desideri segnalare potenziali problemi.

Best practice

• Usa i link: Per informazioni che potrebbero cambiare (ad es. dettagli di contatto), si consiglia di collegare a una pagina web piuttosto che codificarle direttamente nel contratto. Questo evita la necessità di frequenti aggiornamenti del programma.

• Verifica: Prima di effettuare il deploy, verifica il formato e il contenuto utilizzando lo strumento query-security-txt, che può validare sia programmi onchain che binari locali:

query-security-txt target/bpfel-unknown-unknown/release/my_contract.so

Incorporando le informazioni di contatto per la sicurezza direttamente nel tuo contratto, rendi più facile per i ricercatori raggiungerti, favorendo una migliore sicurezza e comunicazione all'interno dell'ecosistema Solana.

Questo è un esempio di come appare security.txt in Solana Explorer

Il progetto security.txt è mantenuto da Neodyme Labs

Puoi verificare lo stato di verifica e consultare i programmi verificati su verify.osec.io.