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 remote submit-job --program-id <program-id> --uploader <address>

solana-verify remote get-job --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 onchain 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 à ellipsislabs/hello_world_verifiable_build:latest, et vérifie que le hachage du chemin de l'exécutable dans le conteneur est identique au hachage du programme on-chain fourni à la commande. Étant donné que la compilation a déjà été téléversée dans une image, il n'est pas nécessaire de recompiler 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 le résultat attendu :

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 onchain 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 principale. Vous pouvez également définir un commit spécifique si vous souhaitez continuer à travailler sur le dépôt en utilisant le paramètre commit-hash : --commit-hash 5b82b86f02afbde330dff3e1847bed2d42069f4e

Lorsque vous y êtes invité, répondez oui pour publier votre PDA de vérification onchain. Ensuite, soumettez une tâche de vérification à distance via l'API OtterSec :

solana-verify remote submit-job --program-id FWEYpBAf9WsemQiNbAewhyESfR38GBBHLrCaU3MpEKWv --uploader <your-upgrade-authority>

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
Onchain 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 library-name car le dépôt Squads inclut plusieurs programmes. Nous utilisons le drapeau --bpf car squads_mpl a été précédemment vérifié avec Anchor.

Résultat final :

Executable Program Hash from repo: 72da599d9ee14b2a03a23ccfa6f06d53eea4a00825ad2191929cbd78fb69205c
Onchain 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
Onchain 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
Onchain Program Hash: 890d68f48f96991016222b1fcbc2cc81b8ef2dcbf280c44fe378c523c108fad5
Program hash matches ✅

Questions fréquemment posées

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

Vérifiez ces problèmes courants :

• Signataire incorrect : Confirmez que votre signataire est l'autorité de mise à niveau du programme en exécutant solana program show YourProgramId
• Pas de PDA on-chain : Exécutez solana-verify verify-from-repo -um et sélectionnez OUI lorsque vous y êtes invité. Sans importation du PDA, l'API ne peut pas récupérer vos métadonnées de vérification.
• Incohérence des données du 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

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

Cela signifie généralement :

• 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

Résolvez ce problème 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 ?

Prévoyez ces délais selon la taille de votre programme :

• Programmes simples : 1 à 5 minutes
• Programmes complexes : 5 à 15 minutes
• Programmes très volumineux : jusqu'à 30 minutes

Suivez votre progression via l'endpoint 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 disposons d'une adresse en liste blanche 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 de commit, paramètres de build) on-chain dans un PDA appartenant au 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 : N'importe qui 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 PDAs on-chain car :

• Sans Confiance : L'API rejette les données arbitraires - elle utilise uniquement ce que votre autorité de mise à niveau a stocké on-chain
• Plus Simple : Fournissez simplement le signataire + program_id ; l'API récupère tout le reste depuis votre PDA
• Inviolable : Votre PDA crée un enregistrement immuable que chacun 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 re-vérifier autrement - l'API re-vé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 annule la vérification de 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 de 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 indépendamment vérifiable :

Ce qui le rend fiable :

• PDA on-chain : Vos métadonnées de vérification résident on-chain, sans être contrôlées par aucune autorité centrale
• Preuve d'autorité de mise à jour : Seule l'autorité de mise à jour 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

Tenez compte de ces limites :

• La vérification confirme que la source correspond au déploiement - PAS que votre code est sécurisé
• Vérifiez toujours le code avant d'interagir avec des programmes
• Vérifié ≠ audité, ni sûr
• Consultez le dépôt et le commit dans le PDA pour confirmer qu'ils proviennent d'une source de confiance

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

Vérifiez vous-même n'importe quel programme 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 onchain 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 autorisation ?

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

Que faut-il 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 par tous
• La vérification sans tiers de 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 même est de permettre aux utilisateurs de vérifier indépendamment que le code 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...

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

Conclusion

L'utilisation des 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 Solana Explorer. En tirant parti d'outils tels que le 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 à jour et des déploiements en toute sécurité.

Sécurité + Avertissement

Bien que les builds vérifiés soient un outil puissant pour garantir l'intégrité de vos programmes Solana, la configuration par défaut n'est pas entièrement sans tiers de confiance. Les images Docker sont construites et hébergées par la Solana Foundation.

Sachez que vous construisez votre projet dans une image Docker téléchargée et que l'intégralité de votre configuration, y compris des informations potentiellement sensibles, est copiée dans cette image Docker lors de la construction.

Si vous souhaitez une configuration entièrement sans tiers de confiance, vous pouvez construire les images Docker vous-même et les héberger sur votre propre infrastructure. Vous aurez ainsi la certitude que les images Docker n'ont pas été altérées. Vous trouverez les scripts pour créer vos propres images Docker dans le dépôt Verified builds. Vous pouvez le forker et exécuter les actions GitHub vous-même, ou vérifier 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 peut potentiellement afficher des informations incorrectes en cas de compromission.

Si vous souhaitez une configuration entièrement sans confiance, vous pouvez exécuter vous-même l'API de vérification ou effectuer la vérification du programme localement à l'aide de la commande verify-from-repo, en utilisant les données de vérification on-chain 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 figé, il peut donc être mis à jour à tout moment.

La Solana Foundation, OtterSec et l'équipe Ellipsis Labs ne sont pas responsables des pertes ou dommages pouvant survenir 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 à la construction et à la vérification d'un programme est dérivé de l'adresse du programme et du pubkey du vérificateur. Par défaut, il s'agit du même pubkey qui a compilé et déployé le programme. Mais il peut également s'agir d'un autre pubkey qui peut être spécifié dans le fichier security.txt.

La fonctionnalité security.txt permet aux développeurs d'intégrer des informations de contact et de sécurité directement dans leurs contrats intelligents Solana. Inspirée de securitytxt.org, cette approche fournit un moyen standardisé pour les chercheurs en sécurité de contacter les responsables du projet, 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 les projets privés, identifier les développeurs à partir de la seule adresse du contrat peut s'avérer 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, permettant ainsi de prévenir les exploits et d'assurer un signalement rapide des bugs.

Comment implémenter security.txt

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

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 interrogées via des outils tels que Solana Explorer, garantissant que vos coordonnées et informations de sécurité sont accessibles à toute personne souhaitant signaler des problèmes potentiels.

Bonnes pratiques

• Utilisez des liens : Pour les informations susceptibles de changer (par ex., les coordonnées), il est recommandé de renvoyer vers une page web plutôt que de les intégrer en dur dans le contrat. Cela évite la nécessité de mises à jour 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 permet de valider aussi bien les programmes onchain que 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 rendu de security.txt dans Solana Explorer

Le projet security.txt est maintenu par Neodyme Labs

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