Comment fournir un fichier Asc garantit-il que je télécharge le code source prévu ?

J'installe cmake à partir du site Web cmake.org et ils fournissent deux fichiers qui, je pense, sont destinés à vérifier le téléchargement du code source cmake-3.11.0-rc3.tar.gz

Sur la même page, ils ont des liens pour télécharger un cmake-3.11.0-rc3-SHA-256.txt fichier et un cmake-3.11.0-rc3-SHA-256.txt.asc fichier

Ce que je ne comprends pas, c'est :

Comment un fichier asc provenant de la même source (cmake.org) garantit-il l'intégrité du code source ? Si le code source proposé par le site était compromis, l'attaquant ne pourrait-il pas également compromettre le fichier asc ?
N'ai-je pas besoin d'une clé publique pour vraiment vérifier le téléchargement du code source ? Et je pensais que le fichier asc était censé être la clé publique. Cependant, lorsque j'essaie d'importer le fichier asc avec
```
gpg --import cmake-3.11.0-rc3-SHA-256.txt.asc
```
J'obtiens une erreur indiquant "aucune donnée OpenPGP valide trouvée"

Réponse acceptée :

Jetez un oeil à l'intérieur du .asc fichier, vous verrez qu'il commence par :

 -----BEGIN PGP SIGNATURE-----

Il s'agit donc d'une signature PGP . Cela signifie qu'il signe du contenu avec une clé PGP spécifique.

1) Le contenu

Basé sur le nom, le contenu est le fichier .txt , c'est la liste des fichiers correspondant au logiciel à télécharger et chaque fichier a son hash correspondant.

2) La signature

Si vous lancez gpg sur les deux fichiers, voici le résultat :

$ gpg --verify cmake-3.11.0-rc3-SHA-256.txt.asc cmake-3.11.0-rc3-SHA-256.txt
gpg: Signature made Fri Mar  9 10:29:10 2018 EST
gpg:                using RSA key 2D2CEF1034921684
gpg: Can't check signature: No public key

Alors, comment tout cela fonctionne-t-il ? Vous êtes censé avoir la clé 2D2CEF1034921684 dans votre trousseau local. Comment l'obtenez-vous, et plus important encore, assurez-vous d'obtenir le bon? (l'identifiant en lui-même ne suffit pas). C'est là que le modèle de réseau de confiance d'OpenPGP prend place. Ce serait trop long de détailler ici mais bref, idéalement, vous avez accès aux clés hors bande et vous avez les moyens de l'authentifier... ou d'authentifier une autre clé de quelqu'un que vous connaissez qui a lui-même authentifié l'autre clé. Et/ou vous le trouvez en ligne à un ou plusieurs endroits, sécurisé par HTTPS (avec un certificat et une autorité de certification de confiance), et idéalement avec DNSSEC.

Si vous avez la clé publique et que vous pensez qu'elle est bonne et non falsifiée (et que cela correspond généralement aux développeurs de logiciels de l'outil que vous essayez de télécharger), la commande ci-dessus vous montre que le .txt les fichiers n'ont pas été altérés. Et à son tour, cela vous donne le hachage de tous les fichiers d'archives, vous pouvez donc le télécharger et réexécuter l'algorithme de hachage (SHA256 comme écrit dans le nom du fichier) et le comparer avec la valeur stockée dans le fichier.

En relation :Quel est l'intérêt d'ajouter une nouvelle ligne à la fin d'un fichier ?

Si quelqu'un avait compromis le serveur et modifié certaines archives, il aurait pu, comme vous le dites vous-même, tout aussi bien modifier le .txt fichier avec les nouveaux hachages afin que vous puissiez croire que les fichiers correspondent.
Cependant, ce tiers ne serait pas en mesure de générer le bon .asc fichier avec la signature PGP (sur gpg --verify vous obtiendriez une erreur de signature invalide), car pour ce faire, il aurait besoin d'avoir accès à la clé privée qui est censée être correctement sécurisée et non stockée sur le serveur Web de toute façon.
Et s'il la génère avec une autre clé vous le verrez car vous ne ferez pas confiance à cette clé inconnue.

Mais bien sûr, tout le modèle s'effondre si la clé elle-même est compromise.