Le programme d’installation Windows d’ImageMagick ne sera plus signé
(github.com/ImageMagick)- ImageMagick a annoncé que son certificat de signature de code actuel expirerait le 28 octobre 2023, et qu’il ne recevrait plus le certificat jusque-là sponsorisé par LeaderSSL
- Depuis juin 2023, le CA/B Forum exige que les clés privées de signature de code OV soient stockées sur un dispositif certifié FIPS 140-2 Level 2 ou Common Criteria Level EAL4+, ce qui empêche d’exporter la clé privée pour l’utiliser dans GitHub Actions
- L’impact ne se limite pas aux programmes d’installation
.exe, mais concerne tous les binaires qui étaient signés avec le certificat de signature de code - Dans la discussion, plusieurs alternatives ont été évoquées : le certificat annuel à 629 dollars de Digicert, SignPath, Azure Key Vault avec AzureSignTool, Azure Code Signing ou encore l’auto-signature, avec pour certaines des contraintes comme l’intégration à GitHub Actions ou l’obligation d’utiliser AppVeyor
- Le 6 novembre 2023, ImageMagick a décidé d’utiliser Azure Code Signing, ce qui lui a permis de signer à nouveau ses binaires
Expiration du certificat et arrêt de la signature
- Le mainteneur d’ImageMagick a annoncé que le certificat de signature de code actuellement utilisé expirait le 28 octobre 2023
- Pendant plusieurs années, LeaderSSL a sponsorisé le certificat de signature de code, mais ne peut plus le faire
- Depuis juin 2023, les exigences du CA/B Forum ont changé : les clés privées de signature de code OV doivent être stockées sur l’un des dispositifs suivants
- un dispositif certifié FIPS 140-2 Level 2
- un dispositif certifié Common Criteria Level EAL4+
- À cause de cette exigence, ImageMagick ne peut plus continuer à utiliser son ancienne méthode consistant à exporter le certificat de signature de code et la clé privée pour les utiliser dans GitHub Actions
Alternatives nécessaires et coûts
- Le mainteneur a présenté deux options avec la nouvelle méthode
- utiliser un agent GitHub auto-hébergé avec un jeton matériel
- utiliser une solution de signature cloud intégrée à GitHub
- L’option préférée est une solution cloud intégrée à GitHub
- À l’époque, le mainteneur indiquait que Digicert semblait être le seul choix, et précisait qu’un certificat de signature de code Digicert coûtait 629 dollars pour un an, hors taxes
- Il a demandé que les organisations ayant besoin de programmes d’installation signés sponsorisent un certificat de signature de code
Portée de l’impact
- Un participant a demandé si l’impact concernait uniquement les programmes d’installation
.exe, ou si tous les binaires Win32 commemagick.exedans les archives zip portables ne seraient plus signés eux non plus - Le mainteneur a répondu que tous les binaires qui étaient signés avec le certificat de signature de code étaient concernés
Alternatives discutées
-
SignPath
- Un participant a proposé SignPath ; le mainteneur a répondu qu’il ne connaissait pas cette société, mais que cela pouvait être une option
- Un autre participant a partagé son expérience en indiquant qu’il utilisait SignPath depuis plus de deux ans sur un projet OSS, et qu’il avait toujours reçu de bonnes réponses à ses questions
- Ce participant a ajouté que, d’après sa compréhension du mode de vérification des sources de SignPath, AppVeyor était nécessaire pour produire des binaires ou des programmes d’installation signés, et que ces derniers devaient être au format
.MSI - Un participant de SignPath a expliqué que le certificat gratuit avait certaines contraintes
- le certificat gratuit délivré à la « SignPath Foundation » exige des builds transparents et vérifiables, ce qui signifiait alors AppVeyor
- un connecteur GitHub Actions devait bientôt être proposé
- les formats standard comme MSI, MSIX et AppX ont des avantages, mais d’autres programmes d’installation peuvent aussi être pris en charge
- comme ImageMagick dispose d’une LLC enregistrée, il pourrait obtenir un certificat au nom d’ImageMagick sans ces contraintes, et SignPath a proposé de le sponsoriser la première année
-
Azure Key Vault et AzureSignTool
- Un participant a expliqué qu’il plaçait un certificat EV de signature de code émis par GlobalSign dans Azure Key Vault et signait les fichiers dans GitHub Actions avec AzureSignTool
- Le mainteneur a répondu que cette approche semblait être une option moins coûteuse, et a indiqué qu’on lui avait aussi recommandé la veille dotnet/sign, qui utilise
AzureSignTool - Un autre participant a partagé un article sur la signature de programmes d’installation Windows avec un certificat EV en combinant GlobalSign et Azure Key Vault
- Un participant a indiqué qu’Azure Key Vault le permettait et que, même en signant des builds plusieurs fois par jour, le coût se comptait en centimes
- Plus tard, un autre participant a ajouté qu’après l’expiration de son certificat en janvier 2024, il avait rencontré le même problème : le nouveau certificat devait être émis sur un dispositif et ne pouvait pas être transféré vers Azure Key Vault
-
Azure Code Signing
- Un participant a indiqué qu’il était passé à Azure Code Signing et a dit qu’il allait essayer de contacter Microsoft et l’équipe concernée
- Le mainteneur a répondu qu’il avait directement envoyé un e-mail à AzureCodeSigningTAP
- Un participant se présentant comme ingénieur Azure Code Signing a indiqué que GitHub Actions était pris en charge et a proposé d’être contacté si nécessaire
-
Auto-signature
- Un participant a demandé si la possibilité d’auto-signer les binaires puis de faire installer le certificat public aux utilisateurs avait été envisagée
- Le mainteneur a répondu qu’il ne l’avait pas encore envisagée et qu’il examinait les options proposées dans la discussion
Décision finale
- Le 6 novembre 2023, le mainteneur a remercié les participants pour les différentes options proposées et a indiqué avoir décidé d’utiliser Azure Code Signing
- Grâce à cette décision, ImageMagick a pu signer à nouveau ses binaires
- Il a précisé que le processus de configuration était documenté dans un billet d’un dépôt séparé : ImageMagick now uses Azure Code Signing
1 commentaires
Avis de Hacker News
J’ai créé gratuitement un lecteur vidéo open source pour coachs d’e-sport, et je comprends la douleur, car je reçois sans cesse des plaintes sur le fait qu’il faut contourner un avertissement lors de la première installation.
Je peux payer le coût du certificat, mais je n’ai pas envie de payer en plus pour un projet que je distribue déjà gratuitement en y consacrant du temps.
Ce serait bien d’avoir un service à la Let's Encrypt pour les logiciels open source, mais du point de vue de Microsoft ou d’Apple, cela risquerait de faire sortir les gens du jardin clos qu’est l’app store, ce qui semble aller à l’encontre de leurs intérêts fondamentaux.
Je crée des logiciels depuis près de 25 ans, et c’est assez amer de voir, au nom de la « sécurité », ma propriété sur mon propre ordinateur se réduire.
https://www.vodon.gg/
La réponse habituelle est que les certificats de signature de code visent à fournir une preuve d’identité légale, afin de permettre soit de sanctionner hors ligne les personnes qui distribuent des malwares, soit d’appliquer des politiques n’autorisant l’installation que de logiciels provenant d’une liste donnée d’éditeurs.
À l’inverse, les certificats de validation de domaine pour HTTPS cherchent à prouver le contrôle d’un nom DNS, ce qui peut être vérifié par des moyens techniques automatisés et n’est pas nécessairement lié à une identité hors ligne.
Un certificat Let's Encrypt confirme qu’une clé semble être contrôlée par la personne qui contrôle un certain nom DNS, tandis qu’un certificat de signature de code cherche à confirmer qu’elle semble être contrôlée par le représentant d’une entité juridique précise dans une juridiction donnée ; le coût d’une vérification utile est donc bien plus élevé.
Un jour, un gouvernement fournira peut-être un moyen d’automatiser cela, mais ce que prouvent ces deux types de certificats et leurs méthodes de vérification sont très différents.
Une discussion liée se poursuit déjà plus longuement ici : https://news.ycombinator.com/item?id=38056024
Si les utilisateurs y tiennent vraiment à ce point, ils devraient être prêts à partager le coût ; sinon, le fait que ce ne soit pas signé ne devrait pas être un problème.
Il semble que cet avertissement disparaisse une fois qu’il y a eu suffisamment de téléchargements.
Avec un Mac, on a moins de soucis de ce genre.
Le coût n’est pas le seul problème.
Je gérais la signature avec un workflow de release automatisé.
https://github.com/technion/rustypwneddownloader/blob/main/....
Avec les nouvelles règles, ce workflow n’est plus utilisable, et j’ai du mal à accepter l’idée que déplacer le build sur mon poste de bureau pour utiliser une clé de signature matérielle, puis uploader le tout d’une manière ni automatisée ni transparente, constitue une amélioration de la sécurité.
Premièrement, une clé privée stockée dans un fichier peut être exfiltrée discrètement, et dans ce cas la seule option restante est la révocation.
C’est la principale raison de l’exigence d’un HSM ; les auteurs de malwares font cela depuis un moment, et la révocation est difficile et coûteuse pour plusieurs raisons.
Un HSM peut aussi être volé, mais il faut alors s’introduire dans un bureau ou un domicile et emporter un objet, ce qui a plus de chances d’être remarqué.
Les identifiants permettant d’utiliser le HSM peuvent aussi être volés, mais ils peuvent être changés facilement et rapidement : si vous apprenez que votre PIN a été keyloggé, il suffit, après récupération de la compromission, de changer le PIN, sans révoquer le certificat.
Deuxièmement, signer automatiquement dans la CI peut réellement être dangereux.
Toute personne capable de pousser du code dans le système de CI peut obtenir une signature de code à votre nom, sans que vous vous en rendiez forcément compte.
Comme la clé est toujours en ligne, si le système de CI est piraté, c’est fini ; et même sans cela, la CI exécute beaucoup de code arbitraire sans être surveillée de près, donc toute personne capable d’y injecter du code devient un point faible.
En signant localement, vous pouvez garder la clé littéralement hors ligne jusqu’au moment de la release, et mettre en place une authentification à deux facteurs assez sûre, avec un facteur de possession — la clé — et un facteur de connaissance — les identifiants.
Pour les builds de développement nocturnes, les outils internes et les binaires temporaires qui ne doivent pas sortir, il suffit de les auto-signer gratuitement.
Je stocke un certificat OV .pfx dans les secrets de GitHub Actions et je l’utilise de la même manière.
Mon certificat expire en novembre 2024 et je n’ai pas encore décidé quoi faire.
Obtenir un certificat en tant que développeur individuel, et non comme entreprise, a déjà été suffisamment difficile.
Malgré tout, cela devrait au final être une question d’argent.
Le HSM hébergé dans le cloud à 629 $ par an mentionné dans l’article devrait faire l’affaire, et en payant ce coût on peut le faire fonctionner dans GitHub Actions avec les commandes que l’on utilise déjà, comme signtool ou Set-AuthenticodeSignature : https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
Il suffirait de brancher la clé matérielle sur un petit PC SFF/Atom à une centaine de dollars.
Le seul changement serait que l’étape de signature passerait du cloud à un runner local.
Je ne sais pas vraiment s’il faut y voir ou non une amélioration du point de vue de la sécurité.
Il est surprenant qu’un projet aussi important et largement utilisé qu’ImageMagick ne puisse même pas réunir 629 $ pour un élément essentiel comme la signature logicielle.
C’est un exemple frappant de l’incapacité de l’industrie tech à soutenir correctement, financièrement, les projets open source dont elle dépend fortement.
Même lorsqu’ils apportent une valeur immense, ces projets ne parviennent souvent pas à en récupérer assez pour être durables.
C’est un rappel brutal qu’un changement majeur est nécessaire dans la façon dont nous traitons et valorisons les contributions open source.
La vraie question est de savoir s’il s’agit d’un problème de sécurité, ou bien d’un marché où il faut payer pour participer que l’on impose en brandissant la « sécurité ».
J’aurais même tendance à penser que ce devrait être l’inverse.
629 $, ce n’est pas une somme négligeable.
C’est une situation que Microsoft a elle-même créée dans l’écosystème Windows.
Pas de payer un loyer à Microsoft ou à ses partenaires.
Mon éditeur de texte de bureau KeenWrite signe les binaires Windows avec Wine, rcedit-x64.exe, osslsigncode et des scripts shell.
D’abord, rcedit-x64.exe ajoute les informations d’identification au binaire.
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/installe...
Ensuite, osslsigncode applique le certificat.
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/scripts/...
Comme dit plus haut, le fait qu’un projet open source qui génère 0 dollar de revenus doive payer pour être distribué sur Windows réduit la propriété que j’ai sur mon ordinateur.
Désormais, il faut que ce soit basé sur un HSM.
J’ai vécu l’enfer de la signature d’applications à la fois sur Windows et sur macOS, et cela ne fait qu’empirer.
D’abord, tout cela donne envie de tout fournir sous forme de web app.
Les navigateurs offrent à bien des égards une expérience nettement meilleure, avec une sécurité bien intégrée, tandis que des systèmes d’exploitation vieux de 25 ans donnent l’impression de rajouter la sécurité après coup.
Chez Apple, personne ne s’en souciera sans doute, mais ce serait assez drôle si cela devenait une fissure dans leur monopole matériel et logiciel.
Ensuite, je me demande pourquoi un tiers ne pourrait pas proposer ce type de signature comme service.
Techniquement, il n’y a pas de limite au nombre d’apps que je peux signer, non ?
Du point de vue de l’utilisateur, je ne vois pas non plus en quoi ce serait un problème si le certificat était signé au nom d’ABC Corp, approuvée par le système d’exploitation, plutôt qu’à mon nom.
On pourrait révoquer un maillon de la chaîne, mais cela semble techniquement possible, et je me demande aussi si un passage d’un EULA que j’ai accepté distraitement l’interdit explicitement.
Malgré tout, je suis vraiment satisfait du résultat, et les utilisateurs semblent l’être aussi.
Fait amusant, quelqu’un m’a récemment recommandé de l’essayer, et il a été assez surpris d’apprendre que j’en étais l’auteur principal.
Dans ce scénario, signe-t-on n’importe quoi les yeux fermés ? Si oui, ce n’est clairement pas une bonne idée.
L’alternative, c’est un long processus de revue et d’audit, mais si quelque chose passe entre les mailles du filet, c’est tout de même le signataire qui en prend un coup.
Si ce n’est pas un pilote de périphérique, on approche du point où l’on peut le recompiler pour une utilisation côté client dans le navigateur.
Dans mon entreprise, nous avons récemment rencontré le même problème, et nous n’avons découvert le changement d’exigences que lorsque notre fournisseur actuel n’a pas pu renouveler le certificat.
Il existe maintenant étonnamment peu d’informations sur la façon de signer du code Windows.
Nous ne voulions pas utiliser d’appareil physique, et ce n’est pas réaliste pour une équipe entièrement à distance.
Nous avons finalement décidé d’utiliser Azure KeyVault avec Digicert.
Comodo, c’est-à-dire Sectigo, ne me plaît pas.
Il y a vraiment très peu d’informations pour faire fonctionner concrètement cette combinaison, et il faut dépenser environ 600 $ avant même de pouvoir tester si cela marche.
Une fois la configuration terminée, cela fonctionne bien.
Le nouveau dispositif de signature via Azure est plus sûr que de stocker une clé privée dans le système de CI.
Mais je n’aurais jamais pensé que la signature d’applications Windows serait plus difficile que la signature sur macOS ou iOS.
Mission accomplie.
Comme vous le dites, l’information manque, et cela serait utile à beaucoup de monde, moi compris.
Je me demande si quelqu’un a essayé SignPath (https://signpath.org), mentionné dans l’une des réponses.
Le site indique : “SignPath Foundation provides reliable code signing for Open Source projects.”
Si c’est un service légitime, cela pourrait être une option utile.
Pour l’instant, la « fondation » est gérée par l’entreprise SignPath, mais ils disent espérer qu’un jour la fondation s’étendra pour devenir indépendante et gérée par la communauté.
Je me demande où est passé le « Developers, developers, developers! »
Ce qu’on voit souvent chez les grandes entreprises tech, c’est qu’au début elles ont l’air bien, puis quelques années plus tard la corruption s’infiltre, et si elles tiennent assez longtemps, elles finissent par devenir des entités parasitaires.
Une entreprise de la taille de Microsoft devrait être capable de trouver un moyen pour que le monde du libre et de l’open source qu’elle dit tant soutenir puisse distribuer sur sa plateforme sans contraintes ni coûts.
Ce genre de friction au nom de la sécurité finit toujours, comme par hasard, par aider les revenus.
J’aimerais que le coût des certificats de signature baisse globalement.
10 dollars maximum suffiraient.
Pour des logiciels spécialisés utilisés par très peu de personnes, le coût actuel ne se justifie pas.
La seule raison qui me vient à l’esprit pour justifier un tel prix, c’est qu’il faudrait un montant assez élevé pour que le propriétaire légitime d’une carte volée s’en rende compte.
Cela pourrait donc, en soi, servir de forme de vérification de l’auteur.
Dans ce cas, on pourrait peut-être rembourser une partie ou la totalité au bout de trois mois.
Même à des fins de vérification, il ne semble guère nécessaire de facturer cette vérification chaque année ; au final, ça ressemble à de la recherche de rente.
Le Store coûte, de mémoire, 19 $ en une seule fois, sans frais récurrents ni annuels.
Ce problème ne concerne donc que la distribution en dehors du Store.
Si les certificats sont chers, c’est parce que les administrations ne sont pas numérisées et ne gèrent pas correctement la cryptographie, ce qui impose beaucoup de travail manuel pour relier la possession d’une clé privée à une identité légale.
Les autorités de certification doivent rechercher les informations d’enregistrement sur des sites web nationaux, souvent sans API, passer des appels téléphoniques, examiner des scans de passeports, etc.
Tout cela demande beaucoup de main-d’œuvre, donc coûte cher.
Ce serait bien moins coûteux si les États exploitaient leur propre infrastructure à clé publique et émettaient une clé privée lors de l’enregistrement d’une entreprise, ou si les passeports contenaient une clé privée destinée à la signature de documents.
Malheureusement, il n’y a pas eu de progrès depuis longtemps, et la plupart des quelques pays qui ont expérimenté une infrastructure nationale à clé publique ont fini par abandonner.
Les États-Unis n’ont jamais tenté de déployer une infrastructure gouvernementale à clé publique à grande échelle en dehors du département de la Défense ; les éditeurs de logiciels américains n’ont donc pas vraiment ressenti le besoin de bien prendre en charge les cartes à puce.
Les systèmes d’exploitation grand public ne disposent pas d’un support solide et les standards manquent.
À cela s’ajoute la lourde charge opérationnelle imposée aux autorités de certification par Microsoft, en tant que consommateur de certificats, et par le CA/Browser Forum.
Cela aussi a un coût.
Les frais annuels servent à étaler les coûts dans le temps.
Lorsqu’une autorité de certification émet le certificat initial, cela lui coûte plus qu’une année de frais, mais si elle suppose que l’utilisateur le gardera plusieurs années, elle peut atteindre le seuil de rentabilité et dégager un petit bénéfice.
https://www.gnu.org/philosophy/right-to-read.en.html
Plus je vieillis, plus je réalise que RMS était la Cassandre des temps modernes.