Comment dotnetup vérifie les téléchargements

Note

dotnetup est disponible en préversion publique. Ses fonctionnalités et son comportement peuvent changer avant la disponibilité générale.

dotnetupvérifie les kits de développement logiciel (SDK) .NET et les runtimes qu’il télécharge avant de les extraire. Le type de vérification dépend de l’origine de la build.

Versions publiées

Pour les builds publiés, dotnetup utilise une chaîne de confiance qui commence par un manifeste de mise en production signé :

  1. dotnetup télécharge les manifestes de version .NET. Ces manifestes sont l’index des versions et le fichier releases.json pour chaque canal.
  2. dotnetup vérifie la signature de code détachée (fichier .p7s) de chaque fichier manifeste. Si la signature est manquante ou n’est pas valide, la commande échoue.
  3. Le manifeste vérifié contient le hachage SHA-512 de chaque archive.
  4. dotnetup télécharge l’archive et compare son hachage SHA-512 au hachage dans le manifeste. Si les hachages ne correspondent pas, la commande échoue et dotnetup n’extrait pas l’archive.

Comme le manifeste signé fixe le hachage de chaque archive, dotnetup ne vérifie pas de signature distincte pour chaque archive.

La vérification de signature vérifie également en ligne l’état de révocation des certificats. Autoriser l’accès aux points de terminaison de révocation de certificats requis. Si le réseau bloque ces vérifications, la vérification échoue et dotnetup arrête l’installation, même lorsque la signature est valide.

Expiration du manifeste

Les manifestes de version présentent une heure d'expiration. dotnetup vérifie que le manifeste n’a pas expiré, même si ses hachages de signature et d’archivage sont valides. Il vérifie également que le manifeste a été signé avant son heure d’expiration.

Une horloge système incorrecte ou un manifeste expiré peut entraîner l’échec de la vérification. Pour obtenir des conseils de récupération, consultez Un manifeste de version a expiré.

Certificats approuvés

Pour les signatures de manifeste et leurs horodatages, dotnetup utilise des certificats racines approuvés regroupés avec l’outil. Il n’ajoute pas de certificats du magasin de certificats de confiance du système d’exploitation à ces racines de confiance.

L'ajout d'un certificat au magasin de certificats de confiance du système d'exploitation ne permet pas à dotnetup de faire confiance à une signature de manifeste de version issue de la chaîne de certificats de ce certificat. La signature doit respecter la stratégie de vérification de dotnetup et remonter jusqu'à une autorité racine de confiance intégrée.

Builds de préversion quotidiennes et non répertoriées

Les builds quotidiennes et les versions préliminaires qui ne sont pas dans le manifeste de version signée proviennent d’un autre flux. Ces builds ont un fichier de hachage SHA-512, mais aucune signature de code. Pour ces builds, dotnetup vérifie uniquement le hachage SHA-512.

dotnetup utilise ce chemin d’accès lorsque vous installez :

  • Un canal quotidien, tel que daily ou 10.0-daily.
  • Version préliminaire entièrement spécifiée, telle que 10.0.100-preview.4.25216.37, qui n’est pas dans le manifeste de mise en production.

Avant le démarrage de l’installation, dotnetup affiche cet avertissement :

⚠ Daily builds are not code-signed. Only the SHA-512 hash is verified.

Pour plus d’informations sur les builds quotidiens, consultez Utiliser la préversion et les builds quotidiens.

Bloquer les téléchargements non signés

Les administrateurs peuvent bloquer l’installation des builds qui ne sont pas signés numériquement. Lorsque cette stratégie est appliquée, dotnetup continue d'installer les builds publiées, mais l'installation des builds quotidiennes et des builds préliminaires non répertoriées échoue.

Windows

Créez la valeur de Registre BlockUnsignedDownloads comme REG_DWORD, avec une valeur non nulle sous HKLM\SOFTWARE\Policies\Microsoft\dotnet\Dotnetup. Par exemple, exécutez ces commandes dans une session PowerShell avec élévation de privilèges :

$key = 'HKLM:\SOFTWARE\Policies\Microsoft\dotnet\Dotnetup'
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name 'BlockUnsignedDownloads' -PropertyType DWord -Value 1 -Force | Out-Null

Pour effacer la politique, supprimez la valeur ou définissez-la sur 0.

Linux et macOS

Créez le fichier /etc/dotnet/dnup-block-unsigned-downloads. Le contenu du fichier n’a pas d’importance. Par exemple:

sudo mkdir -p /etc/dotnet
sudo touch /etc/dotnet/dnup-block-unsigned-downloads

Pour désactiver cette stratégie, supprimez le fichier.

Installations bloquées

Lorsque la stratégie bloque une installation, dotnetup affiche une erreur similaire au message suivant :

An IT policy on this machine requires code-signed downloads. Installing daily or unsigned prerelease builds of SDK <version> is blocked. Choose a released version, or have an administrator clear the policy ...

Pour continuer, installez une version publiée ou demandez à votre administrateur de désactiver la stratégie.

L’exécutable dotnetup

Les scripts de téléchargement get-dotnetup vérifient le fichier exécutable dotnetup téléchargé à l'aide de son fichier de somme de contrôle SHA-512. Pour plus d’informations, consultez Prise en main de dotnetup.

dotnetup self update vérifie également la somme de contrôle SHA-512 de l’exécutable téléchargé. Sur Windows, si l’exécutable installé est signé Authenticode, le remplacement doit avoir une signature Authenticode avec une autorité racine approuvée par Microsoft. D’autres plateformes et installations Windows non signées reposent sur la somme de contrôle.

La mise à jour automatique utilise actuellement le flux d’objets blob non signé, et non les manifestes de publication de .NET signés décrits précédemment. La stratégie des téléchargements non signés bloque également la mise à jour automatique à partir de ce flux.

Après le remplacement, dotnetup exécute le nouvel exécutable avec --version et vérifie que sa version correspond à la version résolue. Si cette vérification échoue, dotnetup tente de restaurer l’exécutable précédent. Cette vérification de démarrage ne vérifie pas l’authenticité du téléchargement.

Voir aussi

  • Dernière mise à jour :