Non, il suffit d'aller voir par exemple son blog pour voir que c'était des considérations plus anciennes. Et de voir aussi que des gens l'ont mis en place par exemple avec une Arch en janvier 2022.
Et les attaques qu'on cherche à éviter date quand même de 2009. Tu peux aussi noter qu'il n'y a pas que lui qui parlent du sujet, par exemple Matthew Garrett a posté plusieurs fois, que ça soit sur les soucis du BYOD ou les rootkits UEFI, ou justement la question des certificats.
But obviously this is all predicated on the idea that an employer needs visibility into what's happening on systems that have access to their systems, or which are used to develop code that they'll be deploying.
Marrant j'ai souvent ce débat au boulot où on se prends la tête pour savoir si le code produit par nos développeurs est vraiment "sûr".
Je fais remarquer que 99% du code (firmware, OS, logiciels systèmes, serveurs web, serveurs applicatifs, les nombreuses bibliothèques…) qui tourne en prod n'est PAS écrit par nos développeurs :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Vu que Matthew Garrett a bossé chez Google qui a notoirement été attaqué en 2009 par la Chine, et par la NSA vers la même époque avait sans doute une vision différente de ton taf.
C'est un principe admis — confier la sécurité au pire truand ; il connaît toutes les ficelles et saura mettre en échec ses congénères — et parfois mis en pratique avec un certain succès même si l'on trouvera plus facilement des contre exemples. Pour une bonne application il faut probablement que la récompense offerte soit supérieure à l'espérance de butin. La domination sans partage des processus de démarrage des PC est peut-être un enjeu de cet ordre ?
En même temps, je ne suis pas sur qu'il y a beaucoup d'alternatives crédibles.
Ça aurait pu être Intel (psa beaucoup mieux que Microsoft).
Ça aurait pu être un état (par exemple, les USA, comme pour le DNS avant 2016 vu que l'ICANN était une agence du département du commerce des USA), ou un groupe d'état (exemple, l'ITU, une agence de l'ONU). Ou ça aurait pu être un consortium d'entreprises (comme la Linux Foundation), ou un groupe de divers groupes (comme l'ICANN après 2016) ou un système plus ou moins distribué avec des états et des entreprises comme le système de PKI sur le web.
Aucune ne semble parfaite, ou rapide en mettre en place. Maintenant, peut être qu'il est temps de transitionner ça vers une autre structure, mais laquelle.
# Autre liens
Posté par cosmocat . Évalué à 4.
où de la
discussionpolémique est en courshttps://www.phoronix.com/news/Lennart-Trusted-Boot-World
https://lwn.net/Articles/912370/
# Follow the money
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Depuis qu'il bosse pour Microsoft, il trouve que Secure Boot est génial?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Follow the money
Posté par Misc (site web personnel) . Évalué à 3.
Non, il suffit d'aller voir par exemple son blog pour voir que c'était des considérations plus anciennes. Et de voir aussi que des gens l'ont mis en place par exemple avec une Arch en janvier 2022.
Et les attaques qu'on cherche à éviter date quand même de 2009. Tu peux aussi noter qu'il n'y a pas que lui qui parlent du sujet, par exemple Matthew Garrett a posté plusieurs fois, que ça soit sur les soucis du BYOD ou les rootkits UEFI, ou justement la question des certificats.
[^] # Re: Follow the money
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Marrant j'ai souvent ce débat au boulot où on se prends la tête pour savoir si le code produit par nos développeurs est vraiment "sûr".
Je fais remarquer que 99% du code (firmware, OS, logiciels systèmes, serveurs web, serveurs applicatifs, les nombreuses bibliothèques…) qui tourne en prod n'est PAS écrit par nos développeurs :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Follow the money
Posté par Misc (site web personnel) . Évalué à 4.
Vu que Matthew Garrett a bossé chez Google qui a notoirement été attaqué en 2009 par la Chine, et par la NSA vers la même époque avait sans doute une vision différente de ton taf.
[^] # Re: Follow the money
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -1.
your trusted brave Lenhard…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Follow the money
Posté par Psychofox (Mastodon) . Évalué à 7.
Secure boot en soit n'est pas une mauvaise idée. Ce qui est nul, c'est que ce soit Microsoft qui est le gardien des clés.
[^] # Re: Follow the money
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
C'est un principe admis — confier la sécurité au pire truand ; il connaît toutes les ficelles et saura mettre en échec ses congénères — et parfois mis en pratique avec un certain succès même si l'on trouvera plus facilement des contre exemples. Pour une bonne application il faut probablement que la récompense offerte soit supérieure à l'espérance de butin. La domination sans partage des processus de démarrage des PC est peut-être un enjeu de cet ordre ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Follow the money
Posté par Misc (site web personnel) . Évalué à 3.
En même temps, je ne suis pas sur qu'il y a beaucoup d'alternatives crédibles.
Ça aurait pu être Intel (psa beaucoup mieux que Microsoft).
Ça aurait pu être un état (par exemple, les USA, comme pour le DNS avant 2016 vu que l'ICANN était une agence du département du commerce des USA), ou un groupe d'état (exemple, l'ITU, une agence de l'ONU). Ou ça aurait pu être un consortium d'entreprises (comme la Linux Foundation), ou un groupe de divers groupes (comme l'ICANN après 2016) ou un système plus ou moins distribué avec des états et des entreprises comme le système de PKI sur le web.
Aucune ne semble parfaite, ou rapide en mettre en place. Maintenant, peut être qu'il est temps de transitionner ça vers une autre structure, mais laquelle.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.