Hello,
En novembre dernier, Let's Encrypt a annoncé que ~ 33,4% utilisateurs d'Android (ceux dont la version Android est plus vieille que la 7.1.1) ne pourront plus se connecter aux sites webs et ressources Internet certifiées par leurs certificats.
En effet, ils ont noté à juste titre que le certificat racine DST Root X3 d'IdenTrust va expirer en septembre 2021.
Or, c'est ce certificat racine qui est utilisé pour signer le certificat intermédiaire Let's Encrypt Authority X3 de Let's Encrypt et permettre d'avoir la chaîne complètement validée sur les anciens systèmes d'exploitations.
En effet, ces anciens systèmes ne reçoivent plus de mises à jour et ils n'ont pas intégré le nouveau certificat racine ISRG Root X1 de Let's Encrypt. La chaîne de confiance ne pourra donc théoriquement plus être confirmée après septembre 2021.
Vous noterez que Let's Encrypt proposait 3 solutions à ce problème pour les propriétaires de sites web:
1. Faire installer Firefox aux utilisateurs d'anciennes versions d'Android
2. Basculer en HTTP sans TLS
3. Ne plus utiliser Let's Encrypt pour créer ses certificats, mais un des CA disponible dans ces cersions
Malheureusement, Firefox ne résoudrait le problème que pour le web et uniquement pour Android version 5.0 ou supérieur.
Le 21 décembre dernier, Let's Encrypt remercie l'innovation de sa communauté et la confiance d'IdenTrust. En effet, ils ont trouvé ensemble un moyen de conserver encore 3 ans la sécurité pour les utilisateurs d'Android < 7.1.1.
La communauté a remarqué qu'Android fait confiance inconditionnellement aux certificats racines installés sur le système (1). Donc, même si le certificat racine DST Root X3 d'IdenTrust ne devrait plus être valide à partir de septembre 2021, Android continue de lui faire confiance.
IdenTrust a accepté de cross-signer le certificat racine ISRG Root X1 de Let's Encrypt pour une durée de 3 ans. Oui, cette fois, c'est bien le certificat racine de Let's Encrypt qui est directement cross-signé et non pas le certificat intermédiaire.
Cette solution permet à Let's Encrypt de passer à leur nouvelle chaîne de certificat tout en restant compatible avec les anciennes versions d'Android, comme montré dans leur schéma:
Comme vous pouvez le voir sur ce schéma, la nouvelle chaîne livrée par défaut aux clients de Let's Encrypt va contenir 4 certificats. D'un côté, ça va ralentir un peu l'initialisation de la connexion TLS, mais d'un autre, ça donne 3 ans de compatibilité Android en plus.
Le client pourra demander expressément d'utiliser la nouvelle chaîne avec uniquement 3 certificats, mais il perdra alors la compatibilité avec les anciennes versions d'Android. Dans ce cas, le client Let's Encrypt doit permettre de trouver les chaînes alternatives. C'est déjà le cas pour certbot et j'ai décidé de ne pas l'implémenter pour acme-dns-tiny.
Bref, les utilisateurs d'Android ont eu chaud, mais ils ont plus de répit 😅
1: J'ai appris dans cet article, que le standard précise que pour valider les trust anchors (certificats racines de confiances du système), le client TLS (le système d'exploitation, le navigateur…) peut choisir ou non de suivre les indications des différents champs présents. Android a décidé de ne pas utiliser le champ notAfter dans leur implémentation et ça aide bien Let's Encrypt pour cette fois. Il se peut que d'autres systèmes fassent de même.
# ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Utilisant encore de vieilles versions (5.1 et 4.4) je suis ravi savoir que mes périphériques ne vont pas devenir rapidement des presses-papiers.
Ceci dit,
…je préfèrerais quand même qu'il y ait un support plus long (et non une course à la dernière qui ressemble à une obsolescence presque programmée) plutôt que d'avoir trop d'entorses de ce genre (ça me rassure pas, je sais pas pourquoi.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ouf.
Posté par Maclag . Évalué à 7.
Par curiosité, quels appareils qui vont sur le web sont sur de vieilles versions d'Android sans possibilité de mise à jour?
Outre les certificats, je m'inquièterais pour le support côté sécurité.
[^] # Re: ouf.
Posté par Anonyme . Évalué à 3.
Pour ce qui est des utilisateurs avancés, Replicant est encore en version 6.
Le travail sur les versions 9, 10 et 11 est en cours mais loin d'être abouti.
Néanmoins la modification des certificats validés par le système ne devraient pas poser de problème à ses utilisateurs.
[^] # Re: ouf.
Posté par Psychofox (Mastodon) . Évalué à 2.
Je suis aussi étonné, j'avais un vieux smartphone en android 2.6 et une vieille tablette en version 5 de android et après une bonne vieille réinitialisation des familles je me suis retrouvé avec deux merdes pour lesquelles il était de toute manière impossible d'installer quoique ce soit car la version du playstore était obsolète et il ne pouvait pas se mettre lui-même à jour. Après je n'ai pas testé d'installer un apk directement, f-droid ou aptoide mais l'intérêt de ces appareils s'était tout d'un coup rendu plus limité.
[^] # Re: ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
La vache, 2.6
:oLe plus vieux que j'ai, c'est 3.quelquechose pour une tablette qui prend la poussière.Si tu as la possibilité de transférer des fichiers (carte SD ou câble USB) sur ton vieux smartphone, tu devrais pouvoir mettre à jour le PlayStore (sous réserve de retrouver un APK qui va bien pour cette version du système, et c'est pas gagné de retrouver les anciennes versions) ou une autre forge/boutique (même combat, et pour F-Droid je crois qu'il faut avoir au moins le système 4.0+)
Une fois ton playstore à jour, le problème suivant auquel tu vas être confronté est la disponibilité d'applications pour cette version du système : je ne sais pas si c'est Google qui les retire ou si ce sont les développeur qui les suppriment, mais certains vieux trucs ne sont plus présents (et pour les nouveaux bah ce sera pas compatible.)
À voir comment on peut recycler ces anciens flagships autrement qu'en foutant à la benne.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ouf.
Posté par barmic 🦦 . Évalué à 5.
C'est ton fabricant qui a arrêté les mises à jour qu'il faut blâmer. Let's encrypt fait de l'obsolescence programmée de certificat, mais ça ne devrait pas poser de problème (et là ce n'est pas l'obsolescence de leur certificat dont il est question d'ailleurs). Après si ton Android est rooté, tu peux probablement juste ajouter le nouveau certificat.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ouf.
Posté par karteum59 . Évalué à 8. Dernière modification le 24 décembre 2020 à 12:45.
Notre système ne permet hélas pas vraiment de valoriser économiquement le support à long terme (i.e. en dehors d'une minorité d'utilisateurs qui y est sensible et qui va par exemple acheter chez Fairphone, la majorité fera toujours le choix du meilleur prix ou du meilleur rapport puissance/prix sans vraiment prendre en compte la durée de support du produit…).
Donc à moins d'arriver à exiger réglementairement une durée de support de X années (par exemple pour avoir le marquage CE, avec pénalités en cas de non-respect), au moins faudrait-il exiger des bootloaders déverrouillables (la tendance est plutôt à l'inverse). Ensuite il existe des solutions pour augmenter (un peu) la durée de vie logicielle, cela dit même avec ça ce n'est pas suffisant car même LineageOS abandonne les anciens smartphones (durée par exemple limitée par le support Qualcomm). Je n'aime pas tellement UEFI (et apparemment je ne suis pas seul) mais il faut reconnaitre qu'on a quand même moins de problème qu'avec ce bazar chez ARM… (et si risc-v venait à se développer pour des machines desktop et pas seulement du µC j'espère qu'ils définiront et généraliseront à un moment le nécessaire pour avoir "one kernel to rule them all" histoire de ne pas refaire la même erreur)
[^] # Re: ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Voilà, c'est ça mon souci : on nous force à courir après la supposé nouveauté et le système tourne ainsi. Sauf que je ne change pas de matos tant que celui que j'ai fonctionne toujours. Du coup je vois d'un mauvais œil quand c'est par le logiciel qu'on veut me faire jeter un truc qui tourne encore bien.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Je ne blâmais point Let's Encrypt et mon fabricant avait bien poussé la version 5.1.1 (pas les majeurs suivantes et tant mieux parce-que je ne recherche pas les nouvelles fonctionnalités du système) Je notais juste qu'avec la sortie de Android M/6.0 je n'ai pas vu passer de correctif de sécurité potentiel.
Je ne dirai pas non plus que LE fait de l'obsolescence de leur certificat ; je crois que le détail a été explicité dans un journal ici.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ouf.
Posté par barmic 🦦 . Évalué à 3.
Encore une fois ce n'est pas la faute des autorités de certifications. Des certificats ça vie et ça doit évoluer. Ça ne fais que révéler ce que ton constructeur ne fait pas.
C'est ce qu'il fait. Ça n'est ni un avis, ni un reproche de ma part. Les certificats émit par LE sont valables 3 mois. Ils le font pour de bonnes raisons, même si je ne doute pas que ça puisse être débattu.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pourquoi cette obsession à vouloir me faire dire tout le contraire de ce que j'écris ? Je m'exprime probablement en marsien ?
Encore une fois, je n'accuse pas les AdC ; ce ne sont pas eux les éditeurs des logiciels (par exemple le navigateur si c'est en cause, mais surtout le système du robot vert dont il est question ici.)
Les certificats LE pourraient même être valides une semaine ou un seul jour que ce ne serait pas de l'obsolescence programmée. Mais le point soulevé ici par ce journal concerne l'expiration de leur autorité racine (et pour l'instant c'est repoussé de trois ans.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ouf.
Posté par barmic 🦦 . Évalué à 0.
Quand je lis :
J'entends que tu reproche à celui qui est responsable de la partie logicielle qui ne marchera plus et c'est IdentCA qui a décidé de rendre son certificat invalide. Encore une fois je ne te reproche rien, car le logiciel ici c'est 4 acteurs : Google via android ou aosp, ton constructeur via sa surcouche, LE via ses certificats et IdentCA avec son certificat racine. Il me semble intéressant de préciser la chaine de responsabilité vu que tu la voie d'un mauvais œil.
Donc non je ne dirais pas que c'est du "marsien", juste que ça me semblait manquer cruellement de précision.
La loi française décrit l'obsolescence programmée ainsi :
À moins de chercher à expliquer qu'un certificat n'est pas un produit ou qu'il n'y a pas de marché de certificat ça me paraît correspondre. Ça n'est pas pour autant un reproche.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ouf.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
OK, pour le logiciel les autres et moi en étions à Android (Google et constructeurs) en version pré-7.1 (et j'ai précisé que je ne blâmais pas LE, ce qui sous-entend que j'étais d'accord que c'est mon fabriquant qui est fautif) Et je n'apprécie point le fait d'être obligé de passer à une version majeure sans besoin (mais bon, je n'avais qu'à pas utiliser ce système, ou passer à Lineage ou Replicant) ; Mais comme disait justement karteum59, le système (la chaîne) n'est pas pensée en terme de durabilité du matériel.
Oui, un certificat est un produit. Je ne voyais pas sous l'angle "réduction délibérée de la durée de vie" parce-qu'ils sont arrivés initialement pour proposer un certificat pour des besoins courts (quand je vois comment les machines ne sont pas décommissionnées ou ces éléments sensibles trainer dans les archives et les mails en entreprise, je trouve que c'est une bonne chose qu'un certificat pour un test ou un POC ne soit pas réutilisé par n'importe-qui pour des attaques de type personne intermédiaire) et sans concurrencer les acteurs payants. Tiens, on pourrait parler d'obsolescence pour ceux-là aussi parce-que pourquoi limiter à un an au lieu de laisser courir ?
Maintenant, pour ceux qui veulent utiliser LE pour plus de trois mois, ils offrent la possibilité d'automatiser le renouvellement (ce qui fait cruellement défaut avec la majorité des acteurs payants que j'ai connu.) Enfin, ne faisant pas payer, ils ont fait le choix de ne pas être sur le marché (ou est-ce un marché du don ?) Bref, ces trois points me font hésiter à appliquer la définition (et je n'y a pas plus réfléchi vu que le souci ici me semble plutôt être IdenTrust)
Pour en revenir aux périphériques avec un système obsolète, il est possible depuis la version 5, d'importer des certificats racines (même pas besoin de rooter l'appareil)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Titre qui fait peur?
Posté par Zenitram (site web personnel) . Évalué à 5.
Et ensuite tu expliques que non. Le titre est donc trompeur, laissant les gens imaginer qu'il y aura un problème alors que non en pratique (depuis que IdenTrust a accepté de signer pour 3 ans).
Mais sinon, ça montre quand même bien un soucis sur la notion de temps avec cette impossibilité pratique de mettre à jour les certificats racine des vielles machines… Alors que ce n'est que quelques milliers d'octets de données à envoyer. A quand une obligation de mise à jour de ces certificats (et patches de sécurité!) pendant au moins 10 ans, à défaut d'upgrade possible de la version d'OS?
[^] # Re: Titre qui fait peur?
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
Techniquement c'est correct si je comprends bien : dans 3 ans Android < 7.1 va refuser les connections TLS certifiées par Let's Encrypt.
Enfin, si c'est comme le brexit y'aura une autre solution (la même ?) dans 3 ans.
[^] # Re: Titre qui fait peur?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
C'est ça, ça va arriver, mais pas aussi vite que prévu.
Pour 2024, si j'étais à la place d'IdenTrust, je ferai la moue d'utiliser encore un certificat racine expiré (il est valide jusqu'en septembre 2021 théoriquement) pour créer de nouvelles signatures. En plus, ça pourrait réduire la confiance des systèmes dans leur gestion des certificats.
Par contre, je pense que le parc de téléphone Android aura déjà largement migrer vers des versions olus récentes que la 7.1.
Il y a un graphe sur Wikipedia si je me souviens bien qui montre l'évolution du parc, c'est assez intéressant.
C'est impressionnant comment le parc évolue vite. Je me dis qu'il doit y avoir beaucoup de gâchis de matériel à cause des techniques de ventes des constructeurs et de l'irrationalité des clients…
[^] # Re: Titre qui fait peur?
Posté par Zenitram (site web personnel) . Évalué à 7.
Ou pas.
Il y a quand même 1/3 des Android pré-7.1, alors qu'il est sorti il y a 4 ans.
Mais Apple a montré qu'il est possible de faire largement mieux (iOS 12 a que 2 ans et moins de 10% ont un truc inférieur) car l'upgrade est géré (et le nombre de terminaux n'est pas une excuse, chaque constructeur pour Android peut faire le taf… si il en a envie).
Le problème est surtout le tiraillement entre ceux qui changent tous les ans et ceux qui récupèrent de 3ème main et ne peuvent upgrader.
La référence actuelle est Android 4.0+, pour 99.5% du marché Android. Et elle a 8 ans.
Si on imagine le même remplacement, ça donnera plutôt Android 5.0+. Grosse maille Android 7.1+ fera sans doute 95% du marché, est-ce que ce sera acceptable de se couper de 5%? J'ose espérer qu'IdenTrust renouvellera pour 3 ans de plus; et je ne vois pas de problème de confiance, c'est un choix et surtout Google et compagnie peuvent décider de refuser sur machine plus moderne si ils ont peur, bref tout est faisable.
Les terminaux sont en réalité de nos jour suffisamment puissants pour durer hors obsolescence programmée par un manque d'upgrade des version d'OS, Apple fait son taf mais Google non (il essaye de faire croire qu'il s'y met mais non). Il faudra tôt ou tard imposer aux constructeurs de faire des upgrades de version allez soyons fou mini les versions qui sortent 4 ans plus tard et les MAJ de sécurité (et de certificat?) pendant 6 ou 8 ans…
Un téléphone GSM de 1998 peut toujours se connecter sur le réseau de 2020 (avec les fonctionnalités de 1998 certes mais ça va), pourquoi pas demander aux fabricants de smartphones 10, 15 ou 20 ans de support? Si ils ne veulent pas maintenir de vieilles version d'OS, ils n'ont qu'à migrer la version d'OS.
Bref, il va falloir sérieusement discuter (car les constructeurs seuls ne feront rien) développement durable si on veut éviter tous ces déchets…
[^] # Re: Titre qui fait peur?
Posté par KiKouN . Évalué à 4.
Je propose d'imposer N années après la fin de commercialisation de l'objet, des MAJ de sécurités et de fonctionnalités ( les certificats rentrant dans le cadre d'assurance de fonctionnalités ). Si pas de MAJ, le fabricant devra mettre à disposition toute la documentation nécessaire ou toutes ces sources et ressources pour faire tourner l'appareil.
[^] # Re: Titre qui fait peur?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Ça me fait vraiment rire de comparer Apple qui a un parc déterminé et fini de SoC ARM et de firmware sur le marché et Google qui n'a aucune maîtrise des SoC et firmware et qui en a potentiellement un nombre de combinaison infini.
Si tu comparais Apple à Samsung, là j'aurai déjà mieux compris, mais ça ne va pas aussi: Samsung ne maîtrise pas du tout ce qu'il y aura dans les prochaines versions d'Android.
Si ARM standardise le démarrage du matériel et la découverte du matériel, ça aidera déjà beaucoup : il n'y aurai plus besoin de build un noyau custom juste pour son matériel… Ça marche très bien avec les "compatible PC".
Ensuite, Google devrait avoir un développement ouvert du projet AOSP et ne pas travailler en cachette pendant 1 an puis balancer les sources d'un coup. Ça doit être un travail de fou de reprendre leur OS complet chaque année et de tout tester sur son matériel. Bravo d'ailleurs aux contributeurs bde LineageOS pour ce travail !
Bref, Apple mène bien ses mises à jour, mais il maîtrise toute la chaîne du matériel à l'OS. Ils doivent juste faire attention à ne pas créer d'incompatibilités entre tout ça (jusqu'au jour où ils décident que les clients doivent repasser à la caisse, en rendant l'OS moins performant artificiellement sur les vieux périphériques).
[^] # Re: Titre qui fait peur?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 24 décembre 2020 à 17:04.
Ri si ça te chante… Et oui, si tu préfères l'idée est plus un constructeur que le fournisseur d'OS.
Qui veut peut. La, tu ne fais que déresponsabiliser et permet tout et n'importe quoi. La loi serait la, charge aux constructeurs de gérer (au passage, ça les motiverait peut-être à rationaliser…) en ayant les contrats qui vont avec leur sous-traitant.
"Ce n'est pas possible" est toujours l'excuse des gens qui se plaignent d'une nouvelle loi, et bizarrement quand la loi passe ils peuvent.
et la suggestion de KiKouN est compatible : tu as le contrat avec ton sous-traitant (SoC etc) avec engagement de N année de maintenance et tu arrêtes de vendre quand tu sais que ce n'est plus compatible avec la loi. Rien de compliqué si tu le veux.
Moi je ri des gens qui excusent les constructeurs.
[^] # Re: Titre qui fait peur?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
C'est la comparaison qui me fait rire, elle n'est pas honnête.
Je n'excuse ni les constructeurs, ni Google, ni ARM. Je relève les points qui font que ta comparaison me semble ridicule.
Tout à fait, les lois peuvent faire avancer les choses, mais en même temps, la loi a imposer la recharge par USB et Apple n'en avait rien à faire…
[^] # Re: Titre qui fait peur?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 24 décembre 2020 à 18:00.
Google a un contrat avec les constructeurs pour pouvoir utiliser Android non AOSP.
Il pourrait même avoir des MAJ par le biais de Google Play (tiens, miracle, il s'y met).
Il pourrait faire des annonces de maintenance avec le constructeur de SoC validé (tiens, miracle, il s'y met, trop peu certes mais il pourrait faire plus si il était prêt à perdre le fabriquant qui ne veut pas le suivre).
Donc Google peut. Si il veut. Il ne veut pas (il priorise avoir plus de constructeurs).
Mais surtout, j'ai certes parlé de Google mais en ayant en tête les constructeurs qui vendent, certes peut trop implicite mais bien responsabilité partagée.
Apple respecte la loi (connecteur USB à l'autre bout). Il a certes mis la pression pour. Pareil, le peuple peut mais ne veut pas, l'espoir est que ça change (des choses changent petit à petit).
Bon, il y a d'autres choses à faire ce soir (en très petit nombre hein! Ou pas du tout, en fait ce n'est pas obligatoire non plus de faire d'autres choses, bref faites ce que vous voulez) qu'une embrouille sur un détail qui n'existe même pas en réalité.
[^] # Re: Titre qui fait peur?
Posté par claudex . Évalué à 4.
Sauf qu'aucun ne veut suivre. Ils sont suffisamment peu (il n'y a quasimment que Qualcomm sur le marché (même Samsung n'utilise pas tout le ses SoC)).
Ça fait quand même des années qu'ils poussent et essaye de trouver des solutions pour ça, mais ils ne peuvent pas attirer les gros et n'auront aucune part de marché avec les petits. Surtout qu'ils risquent une attaque pour abus de position dominante s'ils imposent trop de trucs. J'ai un doute qu'ils peuvent tant que ça. C'est plutôt Apple qui a le pouvoir de pousser les concurrents à suivre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre qui fait peur?
Posté par claudex . Évalué à 3.
Non. Ce qui a été fait, c’est que le parlement européen voulait la même prise partout, et ce qu’il a fait pour ça, c’est donner les pleins pouvoir à la commission européenne sur le sujet. La commission a dit « Ce serait bien d’avoir de l’usb, mais rien d’imposé ».
Sur le coup, j’ai trouvé que c’était une mauvaise idée, rétrospectivement, je pense que c’était mieux, sinon, le micro-usb aurait été imposé et on n’aurait pas une convergence des pc portable et des smartphones vers l’usb-c (vu la vitesse pour la prise de décision).
Au début de l’année, le parlement européen est revenu à la charge et a demandé à la commission une étude pour une méthode unifiée de chargement (pour limiter les déchets). Il n’y a encore rien de décidé à ma connaissance, notamment, il est possible que la méthode obligatoire soit du sans-fil, cela éviterait des problèmes de connecteur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre qui fait peur?
Posté par aiolos . Évalué à 5.
Une méthode unifiée qui passe par le sans fil au nom de l'écologie, on marche dur la tête !
[^] # Re: Titre qui fait peur?
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 25 décembre 2020 à 11:16.
Euh… au cas où tu ne saurais pas, la recharge sans-fil n'est pas universelle, il y a des protocoles et détails techniques qui font que c'est comme le avec fil en terme d'interopérabilité.
Donc le sans fil n'éviterait rien du tout, juste un autre problème de connecteur (qu'il soit caché derrière une plaque plate ne change rien au principe).
Et sinon la recharge sans-fil est loin d'avoir montré une bonne efficacité énergétique, je ne suis pas convaincu que ce soit l'avenir. Certes on en parle même pour les voitures pour une recharge en roulant, mais comme les routes solaires la "bonne idée" semble faire pshit quand mise en pratique. Certes les gens vont se foutre de la perte énergétique d'un smartphone mais peut-être que le peuple lui verra plus de problème en volume. On verra.
[^] # Re: Titre qui fait peur?
Posté par claudex . Évalué à 3. Dernière modification le 25 décembre 2020 à 11:40.
Oui, c'est pour ça que le but, si c'est choisi, c'est de définir une méthode unique (comme pour le fil en fait) minimale (qui n'empêcherait pas d'autres).
Je pense que c'est un peu le but du rapport. De savoir si c'est pertinent ou pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Titre qui fait peur?
Posté par Tonton Th (Mastodon) . Évalué à 0. Dernière modification le 25 décembre 2020 à 15:23.
Sans-fil ? Ils sont débiles à ce point ?
[^] # Re: Titre qui fait peur?
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 25 décembre 2020 à 18:59.
Que des non connaisseurs puissent se poser des questions avant une études ça ne me paraît pas choquant. C'est en se basant sur des études qui, j'espère, s'appuient sur des connaisseurs plutôt que sur des aprioris de béotiens qu'il est possible de prendre des décisions éclairées. Je ne pense pas qu'insulter l'intelligence de quelqu'un qui demande à en savoir plus soit pertinent. Oui ça demande de l'argent de s'informer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre qui fait peur?
Posté par Maclag . Évalué à 6.
1.Ce serait plutôt aux constructeurs de faire savoir à Google qu'ils veulent supporter leurs gammes plus longtemps. Et si Google ne suit pas, soyons fous et rêvons qu'une alliance se forme autour des grands (Samsung, Huawei, etc.) pour un Android "LTS". Je suis sûr que rien que l'annonce suffirait à bouger le c.l de Google.
2.Il n'en tient aussi qu'aux constructeurs de se mettre d'accord pour le démarrage sur ARM. Apparemment ça n'intéresse pas grand monde.
3.Tout ce beau petit monde serait sûrement plus réceptif si une bonne régulation publique leur forçait un peu la main: obligation de suivre les appareils sur 5ans minimum, et pourquoi pas contrats publics avec matériel+support sur 5ans? Tout ça pourrait créer un marché pour un Lineage commercial. En tout cas les fabricants plus petits auraient alors tout intérêt à partager et standardiser le plus possible.
[^] # Re: Titre qui fait peur?
Posté par groumly . Évalué à 4.
ça veut pas dire grand chose, chaque constructeur a un parc déterminé et fini de soc arm sur le marché.
Apple supporte quelques chose comme 35 à 40 devices différent sur iOS. Rajoute la pomme montre et la pomme télé. C’est probablement plus que ce que la plupart des constructeurs android font. L’iPhone 5s de 2013 a recu une mise à jour y’a 10 jours (l’api de contact tracing Covid). Ça fait 7 ans de support quand même.
Surtout que bon, dans l’ensemble, on parle pas de back porter les dernières fritures et de patcher le kernel, mais juste de mettre à jour une douzaine de certificats qui assurent un point central de la sécurité de base du système. En gros, 10Mo de clés publiques.
De ce que j’en vois, Apple maintient largement plus de devices que Samsung ou n’importe quel autre constructeur.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Titre qui fait peur?
Posté par barmic 🦦 . Évalué à 3.
Je trouve au contraire qu'ils ont montré que c'était compliqué. Pour faire ça ils font des optimisations qui demandent à maitriser toute l'intégration OS/matériel (comme le fait de brider pour sauver la batterie). C'est évidement empiré par le fait que chaque constructeur va plus ou moins avoir sa couche pour se dissocier de google ou se démarquer des autres.
Je trouve plutôt qu'android devrait être fait pour durer. Des mises à jour de sécurité distribuées sur play et un support de sécurité de plusieurs années. Je ne suis pas l'actualité mais de ce que je suis entrain de regarder une grande partie des nouveautés de chaque version n'est que des mises à jours logiciels.
Je ne vois pas plus de problème au fait que les gens utilisent KitKat qu'au que d'autres utilisent RHEL 6 sorti en 2011.
La solidité de SHA1, des clefs RSA 2048bits et d'autres algos ça n'est pas une question de choix. C'est pas comme si ça faisait 15 ans qu'on parle des problèmes de SHA1… DST Root CA X3 a était édité en 2000 avec les méthodes des années 2000. Il n'est pas acceptable de continuer à l'utiliser indéfiniment.
Ça signifie créer une exception pour accepter directement ISRG root X1 sans valider son signataire, c'est sans doute possible mais si on arriver à minimiser les exceptions de ce genre (il y en a déjà en cours pour des certificats sortis des trustores, mais qui sont utilisés par des services considérés comme trop importants pour être inaccessibles). Ça participe à réduire le niveau de sécurité et les attaques sont généralement de cet ordre : on utilise différentes choses qui chacune réduit pas suffisamment le niveau, mais qui bout à bout finissent par rendre le tout fragile.
Ah on va pas te proposer des téléphones au même prix s'il faut maintenir une équipe de développeurs quelques années dessus même si elle n'est pas dédiée au téléphone en question. Il faut multiplier ce genre de situations :) Jusqu'à ce qu'une solution émerge pour de bon.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Titre qui fait peur?
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 24 décembre 2020 à 16:48.
C'est fait en accord avec les auditeurs, je pense pas qu'il y ai de problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Certificat racine cross-signé
Posté par goeb . Évalué à 2. Dernière modification le 25 décembre 2020 à 20:52.
Comment fait-on un certificat racine cross-signé ? (par exemple ISRG Root X1 dans le schéma)
A-t-il sa propre signature (self-signed) et un champ d'extension avec la signature d'une autre autorité ?
[^] # Re: Certificat racine cross-signé
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Pour ceux qui voudraient voir les différents certificats (avec un navigateur ou openssl ou …) :
[^] # Re: Certificat racine cross-signé
Posté par gouttegd . Évalué à 5. Dernière modification le 25 décembre 2020 à 23:39.
Non. En fait, ce qu’on appelle un certificat cross-signé est en réalité deux certificats distincts, chacun signé avec deux clefs différentes.
Dans le cas du certificat ISRG Root X1, il y a une version signée par la clef privée correspondant à la clef publique du certificat (c’est-à-dire, auto-signée), et une version signée par la clef privée du certificat racine d’IdenTrust.
La raison pour laquelle ça marche est qu’un certificat contient, entre autres informations, l’empreinte de la clef qui l’a signé (c’est le champ X509v3 Authority Key Identifier). C’est cette empreinte que le navigateur utilise pour trouver le certificat « parent » et ainsi remonter la chaîne des certificats intermédiaires jusqu’à un certificat racine de confiance. Or cette empreinte ne dépend que de la clef elle-même et pas du certificat qui la contient.
Par exemple, le certificat intermédiaire de Let’s Encrypt (
Let’s Encrypt R3) contient l’identifiant de la clefISRG Root X1. À partir de cet identifiant, le navigateur peut remonter à n’importe lequel des deux certificatsISRG Root X1(celui auto-signé et celui signé par IdenTrust), parce que les deux ont la même clef publique (ils ne diffèrent que par leur signature, qui n’a aucune incidence sur l’empreinte de la clef publique).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.