Ce guide est destiné à servir de référence pour les développeurs qui souhaitent implémenter des builds vérifiés pour leurs programmes sur Solana. Nous aborderons ce que sont les builds vérifiés, comment les utiliser, les considérations particulières et les meilleures pratiques pour assurer l'authenticité de votre programme sur la blockchain.

Que sont les builds vérifiés ?

Les builds vérifiés garantissent que le programme exécutable que vous déployez sur le réseau Solana correspond au code source dans votre dépôt. Grâce à cela, les développeurs et les utilisateurs peuvent avoir confiance que le programme fonctionnant sur la blockchain correspond exactement à la base de code publique, favorisant ainsi la transparence et la sécurité.

Le processus de vérification implique la comparaison du hash du programme sur la blockchain avec le hash du programme construit localement à partir du code source. Cela garantit qu'il n'y a pas de divergences entre les deux versions.

Bien qu'un build vérifié ne doive pas être considéré comme plus sécurisé qu'un build non vérifié, le build permet aux développeurs de vérifier eux-mêmes que le code source correspond à ce qui est déployé sur la blockchain. En utilisant le code source, un développeur peut alors valider ce que le code exécute lors de l'envoi d'une transaction.

Le pipeline de builds vérifiés a été conçu et est maintenu par Ellipsis Labs et OtterSec. Pour plus de détails, suivez le guide dans le dépôt original des builds vérifiés ainsi que le processus de vérification de build directement dans la suite d'outils Anza, une fois pris en charge.

Comment ça fonctionne ?

Le processus de vérification consiste à comparer le hash du programme sur la chaîne avec le hash du programme construit localement à partir du code source. Vous construisez votre programme dans un environnement contrôlé en utilisant le CLI Solana Verify et Docker. Cela garantit que le processus de construction est déterministe et cohérent sur différents systèmes. Une fois que vous avez l'exécutable, vous pouvez le déployer sur le réseau Solana. Pendant le processus de construction, un PDA du programme verify sera créé. Ce PDA contient toutes les données nécessaires pour vérifier le programme. Le PDA contient l'adresse du programme, l'URL git, le hash du commit et les arguments utilisés pour construire le programme.

En utilisant les données du PDA, chacun peut exécuter la commande du programme verify localement et vérifier si le programme a été construit à partir du code source fourni. Ensuite, chacun peut vérifier par lui-même de manière totalement autonome ou peut exécuter sa propre API de vérification maintenue par OtterSec pour fournir un point d'accès facile aux utilisateurs pour vérifier la vérification. Vous pouvez déjà voir ces appels API utilisés dans Solana Explorer et SolanaFM, parmi d'autres endroits.

Pourquoi devrais-je utiliser des builds vérifiés ?

L'utilisation de builds vérifiés offre les avantages suivants :

• Sécurité : garantie que le programme exécuté sur la chaîne correspond au code source, empêchant les modifications malveillantes.

• Transparence : permet aux autres utilisateurs et développeurs de valider que le programme sur la chaîne est digne de confiance en le comparant avec le code source public.

• Confiance : augmente la confiance des utilisateurs, car les builds vérifiés démontrent que le comportement de votre programme sur la chaîne est aligné avec votre code public. Lors de la construction de programmes vérifiables, vous minimisez les risques associés à l'exécution de code non autorisé ou malveillant. Cela garantit également que vous respectez les meilleures pratiques et offrez aux chercheurs en sécurité un moyen facile de vous contacter. De plus, les wallets et autres outils peuvent autoriser plus facilement les transactions de votre programme tant qu'il est vérifié.

• Découvrabilité : lorsque vous fournissez une version vérifiée de votre programme, tout le monde peut trouver votre code source, votre documentation, le SDK ou l'IDL de votre programme, et ils peuvent également facilement vous contacter via GitHub en cas de problème.

Comment créer des builds vérifiés ?

Pour créer des builds vérifiés, vous devrez suivre ces étapes :

Résumé :

• Committer votre code dans un dépôt public
• Construire un build vérifié dans Docker
• Déployer le build vérifié
• Vérifier le programme déployé par rapport à l'API publique

Si vous vérifiez votre programme qui n'est pas construit dans un conteneur Docker, il échouera très probablement car les builds de programmes Solana ne sont pas déterministes sur différents systèmes.

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>

Comment vérifier votre programme lorsqu'il est contrôlé par un multisig comme Squads

Pour que la vérification à distance fonctionne, vous devez écrire les données de vérification dans un PDA signé par l'autorité du programme. Si votre programme est contrôlé par un multisig, vous pouvez exporter cette transaction d'écriture PDA et la soumettre via Squads Protocol ou une autre solution multisig de votre choix.

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

Vérifier à partir d'une image docker

Vous pouvez également vérifier votre programme par rapport à une image docker en exécutant la commande suivante :

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

Cette commande charge l'image stockée à l'emplacement ellipsislabs/hello_world_verifiable_build:latest, et vérifie que le hash du chemin de l'exécutable dans le conteneur est identique au hash du programme on-chain fourni à la commande. Étant donné que la compilation a déjà été téléchargée vers une image, il n'est pas nécessaire de reconstruire entièrement l'exécutable, ce qui peut prendre beaucoup de temps.

Le Dockerfile qui crée l'image ellipsislabs/hello_world_verifiable_build:latest se trouve dans le dépôt ellipsis labs /examples/hello_world.

Voici la sortie attendue :

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 ✅

Exemple de build vérifié

Voici un exemple de vérification d'un programme exemple avec l'ID FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv en utilisant le code source de ce dépôt :

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

Par défaut, la commande verify-from-repo prend le dernier commit sur la branche main. Vous pouvez également définir un commit spécifique au cas où vous souhaiteriez continuer à travailler sur le dépôt en utilisant le paramètre commit-hash : --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Enfin, vous pouvez également vérifier directement le programme via l'API 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

La commande --remote envoie une demande de compilation à l'API OtterSec, qui déclenche une compilation à distance de votre programme. Une fois la compilation terminée, le système vérifie que le hash on-chain de votre programme correspond au hash de l'artefact de compilation généré à partir de votre dépôt.

Programmes populaires déjà vérifiés

Phoenix

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

Résultat final :

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

Notez que nous avons dû spécifier le library-name car le dépôt Squads inclut plusieurs programmes. Nous utilisons le flag --bpf car squads_mpl a été précédemment vérifié avec Anchor.

Résultat final :

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

Résultat final :

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

Résultat final :

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

Foire aux questions

Ma vérification échoue. Que dois-je faire ?

Vérifiez ces problèmes courants :

• Mauvais signataire : Confirmez que votre signataire est l'autorité de mise à niveau du programme en exécutant solana program show YourProgramId
• Aucun PDA on-chain : Exécutez solana-verify verify-from-repo -um et sélectionnez OUI lorsque vous y êtes invité. Sans télécharger le PDA, l'API ne peut pas récupérer vos métadonnées de vérification.
• Incompatibilité des données PDA : Mettez à jour votre PDA si vous avez redéployé votre programme. Les données de votre PDA doivent correspondre à votre programme déployé.
• Hash de commit incorrect : Créez votre PDA en utilisant le hash de commit exact que vous avez déployé
• Différences d'environnement de build : Utilisez Docker avec solana-verify lors de la création de votre PDA

Le hash de mon build local ne correspond pas au hash on-chain. Pourquoi ?

Cela signifie généralement que :

• Vous utilisez des versions différentes de la chaîne d'outils Rust/Solana
• Vos dépendances ont été mises à jour entre les builds
• Vous n'avez pas effectué le build dans un conteneur Docker
• Vous avez extrait le mauvais commit

Corrigez cela en effectuant le build avec solana-verify build dans Docker en utilisant le commit exact que vous avez déployé.

Combien de temps prendra ma vérification ?

Attendez-vous à ces délais en fonction de la taille de votre programme :

• Programmes simples : 1 à 5 minutes
• Programmes complexes : 5 à 15 minutes
• Très grands programmes : Jusqu'à 30 minutes

Suivez votre progression en utilisant le point de terminaison de statut de tâche.

Mon programme est immuable (aucune autorité de mise à niveau). Comment puis-je le vérifier ?

Si votre programme n'a pas d'autorité de mise à niveau ou a été rendu immuable avant que vous puissiez créer un PDA, nous avons une adresse autorisée pour cette situation. Contactez-nous à contact@osec.io, et nous vous aiderons à faire vérifier votre programme.

Qu'est-ce que le PDA et pourquoi est-ce important ?

Votre PDA (Program Derived Account) permet une vérification sans confiance :

• Stockage On-Chain : Stockez vos métadonnées de vérification (URL du dépôt, hash du commit, paramètres de build) on-chain dans un PDA détenu par le programme Otter Verify (verifycLy8mB96wd9wqq3WDXQwM4oU6r42Th37Db9fC)
• Lien Cryptographique : Votre PDA est dérivé de l'adresse de votre programme, créant un lien immuable vers vos données de vérification
• Confiance Décentralisée : Quiconque peut lire votre PDA et vérifier indépendamment votre programme

Pourquoi dois-je créer le PDA avant d'utiliser l'API ?

L'API fonctionne uniquement avec des PDA on-chain car :

• Sans Confiance : L'API rejette les données arbitraires - elle n'utilise que ce que votre autorité de mise à niveau a stocké on-chain
• Plus Simple : Fournissez simplement le signataire + program_id ; l'API obtient tout le reste depuis votre PDA
• Inviolable : Votre PDA crée un enregistrement immuable que quiconque peut vérifier indépendamment
• Preuve de Propriété : Votre signataire doit être l'autorité de mise à niveau, prouvant cryptographiquement que vous contrôlez le programme

À quelle fréquence dois-je vérifier mon programme ?

Vérifiez votre programme :

• Après chaque déploiement ou mise à niveau
• Lorsque vous mettez à jour votre dépôt source
• Ne vous inquiétez pas de revérifier autrement - l'API revérifie automatiquement tous les programmes toutes les 24 heures

Que se passe-t-il lorsque je mets à niveau mon programme ?

Suivez ces étapes après la mise à niveau :

1. L'API détecte votre mise à niveau et dévérifie votre programme.
2. Mettez à jour votre PDA avec les nouvelles métadonnées de vérification :

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

3. Soumettez une nouvelle demande de vérification en utilisant votre autorité de mise à niveau
4. L'API vérifiera votre nouvelle version par rapport au PDA mis à jour

Important : Mettez toujours à jour votre PDA en utilisant votre autorité de mise à niveau avec le nouveau hash du commit pour le programme mis à niveau.

Puis-je faire confiance aux résultats de vérification ?

Oui - le système est conçu pour être sans confiance et vérifiable de manière indépendante :

Ce qui le rend fiable :

• PDA On-Chain : Vos métadonnées de vérification sont stockées on-chain, non contrôlées par une autorité centrale
• Preuve d'autorité de mise à niveau : Seule l'autorité de mise à niveau de votre programme peut créer/mettre à jour le PDA
• Vérification indépendante : Tout le monde peut vérifier en lisant votre PDA et en exécutant solana-verify localement
• Re-vérification continue : L'API re-vérifie automatiquement tous les programmes toutes les 24 heures

Comprendre ces limitations :

• La vérification confirme que le code source correspond au déploiement - PAS que votre code est sécurisé
• Examinez toujours le code avant d'interagir avec des programmes
• Vérifié ≠ audité, ou sûr
• Vérifiez le dépôt et le commit dans le PDA pour confirmer qu'il provient d'une source fiable

Comment puis-je vérifier un programme de manière indépendante ?

Vérifiez n'importe quel programme vous-même en lisant son PDA on-chain et en exécutant la vérification localement :

Étape 1 : Lire le 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...

Étape 2 : Vérifier localement

# 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

Cela prouve :

1. Les métadonnées du PDA sont authentiques (stockées on-chain)
2. Le code source dans le dépôt du PDA correspond au programme déployé
3. Vous n'avez pas besoin de faire confiance à l'API - vérifiez tout vous-même on-chain

Quelqu'un d'autre peut-il vérifier mon programme sans permission ?

Oui, c'est la raison pour laquelle nous exigeons que le signataire soit l'autorité de mise à niveau. Nous ne considérons la vérification comme valide que si le signataire est l'autorité de mise à niveau.

De quoi ai-je besoin pour créer des builds vérifiables ?

Installez ces outils :

• Docker (pour des builds déterministes)
• Cargo (gestionnaire de paquets Rust)
• Solana Verify CLI : cargo install solana-verify
• Un dépôt Git public avec votre code source

Puis-je vérifier des dépôts privés ?

Non - la vérification nécessite un code source public :

• Votre PDA stocke une URL de dépôt public accessible à tous
• La vérification sans confiance dépend de l'accès au code public
• Les utilisateurs doivent pouvoir lire votre code source pour comprendre ce que fait votre programme
• L'objectif principal est de permettre aux utilisateurs de vérifier de manière indépendante que la source correspond au déploiement

Les dépôts privés brisent le modèle de confiance fondamental du système de vérification.

Comment vérifier un programme contrôlé par Squads Multisig ?

Suivez ces étapes pour les programmes contrôlés par 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...

Critique : Vérifiez toujours localement (étape 2) pour confirmer que le hash de build correspond avant d'exporter la transaction PDA.

Conclusion

L'utilisation de builds vérifiés sur Solana garantit l'intégrité et la fiabilité de vos programmes sur le réseau et permet aux développeurs de trouver vos SDK directement depuis un explorateur Solana. En exploitant des outils comme Solana Verify CLI et Docker, vous pouvez maintenir des builds vérifiables et sécurisés qui correspondent à votre code source. Prenez toujours les précautions nécessaires pour utiliser des environnements cohérents et envisagez des solutions de gouvernance pour des mises à niveau et déploiements sécurisés.

Sécurité + Avertissement

Bien que les builds vérifiés soient un outil puissant pour garantir l'intégrité de vos programmes Solana, ils ne sont pas complètement sans confiance dans la configuration par défaut. Les images Docker sont construites et hébergées par la Fondation Solana.

Soyez conscient que vous construisez votre projet dans une image Docker téléchargée et que toute votre configuration est copiée dans cette image Docker pour la compilation, y compris des informations potentiellement sensibles.

Si vous souhaitez avoir une configuration complètement sans confiance, vous pouvez construire les images Docker vous-même et les héberger sur votre propre infrastructure. De cette façon, vous pouvez être sûr que les images Docker ne sont pas altérées. Vous pouvez trouver les scripts pour créer vos propres images Docker dans le dépôt Verified builds et vous pouvez le forker et exécuter les actions GitHub vous-même ou valider qu'elles sont correctes.

De plus, pour la vérification à distance, vous faites confiance dans une certaine mesure à l'API OtterSec et à l'Explorateur Solana.

L'API ou l'Explorateur Solana peuvent potentiellement afficher des informations incorrectes s'ils sont compromis.

Si vous souhaitez disposer d'une configuration entièrement sans confiance, vous pouvez exécuter l'API de vérification vous-même ou effectuer la vérification du programme localement en utilisant la commande verify-from-repo en vous servant des données de vérification en chaîne qui sont enregistrées dans un PDA dérivé de l'autorité de déploiement du programme et du programme de vérification.

Le programme de vérification est déployé par l'équipe OtterSec et n'est pas encore gelé, il peut donc être mis à jour à tout moment.

La Fondation Solana, OtterSec et l'équipe d'Ellipsis Labs ne sont pas responsables des pertes ou dommages qui pourraient survenir lors de l'utilisation du pipeline de builds vérifiés.

Security.txt pour les programmes Solana

En plus des builds vérifiés, vous pouvez également ajouter un fichier security.txt à votre programme. À l'avenir, une fois implémenté, le fichier security.txt contiendra la clé publique du vérificateur pour un accès facile aux données de vérification stockées dans le PDA de vérification. Le PDA contenant toutes les informations nécessaires pour construire et vérifier un programme est dérivé de l'adresse du programme et de la pubkey du vérificateur. Par défaut, il s'agit de la même pubkey qui a construit et déployé le programme. Mais il peut également s'agir d'une autre pubkey qui peut être spécifiée dans le fichier security.txt.

La fonctionnalité security.txt permet aux développeurs d'intégrer directement des informations de contact et de sécurité au sein de leurs smart contracts Solana. Inspirée de securitytxt.org, cette approche offre un moyen standardisé pour les chercheurs en sécurité de contacter les mainteneurs de projets, même s'ils ne connaissent que l'adresse du contrat.

Pourquoi utiliser security.txt ?

Pour de nombreux projets, en particulier les plus petits ou privés, identifier les développeurs à partir de la seule adresse du contrat peut être difficile et chronophage. L'intégration d'un fichier security.txt dans le programme garantit que les chercheurs en sécurité peuvent facilement contacter les bonnes personnes, ce qui permet potentiellement d'éviter les exploits et d'assurer des rapports de bugs en temps opportun.

Comment implémenter security.txt

Pour ajouter un security.txt à votre programme Solana, suivez les étapes suivantes :

Ajoutez la dépendance solana-security-txt à votre Cargo.toml :

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

Utilisez la macro security_txt! dans votre contrat pour définir vos informations de sécurité. Vous pouvez inclure des coordonnées, des URL de projet, et même une politique de sécurité. Voici un exemple :

#[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!"
}

Une fois les informations security.txt intégrées dans votre programme, elles peuvent être facilement consultées via des outils tels que Solana Explorer, garantissant ainsi que vos coordonnées et détails de sécurité sont disponibles pour toute personne souhaitant signaler des problèmes potentiels.

Bonnes pratiques

• Utiliser des liens : Pour les informations susceptibles de changer (par exemple, les coordonnées), il est recommandé de créer un lien vers une page web plutôt que de les coder en dur dans le contrat. Cela évite la nécessité de mises à niveau fréquentes du programme.

• Vérification : Avant le déploiement, vérifiez le format et le contenu à l'aide de l'outil query-security-txt, qui peut valider à la fois les programmes onchain et les binaires locaux :

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

En intégrant les informations de contact de sécurité directement dans votre contrat, vous facilitez la prise de contact des chercheurs avec vous, favorisant ainsi une meilleure sécurité et communication au sein de l'écosystème Solana.

Voici un exemple de l'apparence de security.txt dans Solana Explorer

Le projet security.txt est maintenu par Neodyme Labs

Vous pouvez vérifier le statut de vérification et parcourir les programmes vérifiés sur verify.osec.io.