Connexion Abonnez-vous

LineageOS subit les changements de Google dans la politique de sécurité d’Android

Cent fois sur le métier

LineageOS subit les changements de Google dans la politique de sécurité d’Android

Crédits : LineageOS

En septembre, on apprenait que Google avait revu sa manière de distribuer les correctifs pour les failles de sécurité sur Android. Ce changement a un impact important sur LineageOS, une ROM personnalisée pour les smartphones. L’équipe de développement explique le problème et assure qu’elle s’adapte.

Le 17 octobre à 09h37

Le 16 septembre, nous expliquions que Google avait – assez silencieusement – modifié sa manière de distribuer ses bulletins de sécurité mensuels. Les fameux ASB (Android Security Bulletins) étaient depuis des années distribués une fois par mois, avec à leur bord des informations sur les failles de sécurité corrigées. Il appartenait ensuite à chaque vendeur (OEM) d’appliquer ces changements. Quand le travail est fait, les utilisateurs reçoivent ainsi une mise à jour de sécurité par mois, les paramètres d’Android donnant le mois et l’année de la plus récente.

Avec le changement, ils sont toujours publiés mensuellement, mais leur contenu évolue de manière drastique. Seules sont renseignées les failles présentant un haut risque, notamment les vulnérabilités critiques qui présentent un fort risque d'être exploitées ou qui le sont déjà. Tout le reste est rassemblé dans un bulletin publié tous les trois mois.

Ce calendrier est désormais synchronisé avec les QPR (Quarterly Platform Releases), ces mises à jour fournies par Google pour améliorer et enrichir Android. Ce qui n’est pas sans causer des problèmes pour les ROM personnalisées, comme l’a expliqué LineageOS dans une publication du 11 octobre.

Un fonctionnement plus opaque

L’équipe de développement commence par une bonne nouvelle : pour une fois, elle est en avance. Elle indique que bon nombre des améliorations d’Android 16 sont en fait périphériques et ne touchent pas profondément le cœur du système. Le gros travail d’adaptation fait avant a payé et LineageOS 23.0 a donc été publié.

Pour prévenir les réactions sur cette numérotation, l’équipe prend les devants : pourquoi 23.0 et pas 23.1, puisque la QPR1 d’Android est sortie ?

C’est justement là qu’est le problème. L'équipe réexplique le fonctionnement des bulletins de sécurité et de leur changement de rythme, et note l’alignement des gros bulletins trimestriels avec les QPR. Or, la QPR1 d’Android 16 a beau avoir été distribuée (diffusée immédiatement aux Pixel et envoyée aux constructeurs pour intégration), son contenu n’a pas été reversé à AOSP (Android Open Source Project), la branche open source sur laquelle le système de Google est basé et dans laquelle puisent les ROM personnalisées.

L’équipe pointe ainsi un bulletin de juillet vide, pour la toute première fois. Le bulletin d’aout ne contenait qu’un seul correctif, tandis que celui de septembre « a omis des correctifs pour plusieurs vulnérabilités, avec des correctifs partagés en privé avec des partenaires sous embargo ». C’était effectivement ce qu’annonçait Android Authority le mois dernier. L’équipe précise d’ailleurs que c’est la raison pour laquelle LineageOS 22.2 affichait un niveau de sécurité d’aout 2025 jusque tard en septembre.

LineageOS « s’adapte »

L’équipe affirme que l’adaptation est nécessaire et qu’elle n’a pas le choix.

Dans un premier temps, elle a pris la décision de lancer LineageOS 23.0, correspondant donc à la version initiale d’Android 16, ce qu’elle nomme « QPR0 ». Pour le reste, le développement de la ROM devra suivre le nouveau rythme de publication des bulletins de sécurité. Pas le choix, il faudra prendre son mal en patience et subir un décalage entre la publication des correctifs et leur arrivée effective dans AOSP.

Ce décalage sera également fonctionnel. Dans la QPR1 par exemple, Google a déployé son langage graphique Material 3 Expressive. Comme l’indique l’équipe dans son annonce, il faudra donc patienter pour le voir dans LineageOS. Il ne s’agit que d’un exemple, mais ce décalage se répercutera à l’ensemble des nouveautés dans les QPR et – sans doute plus grave – dans les bulletins de sécurité. Car comme nous l’indiquions dans notre précédente actualité, plus l’attente est grande entre la découverte d’une faille et sa correction, plus les risques d’exploitation sont grands.

L’équipe se veut quand même rassurante : le travail va continuer. LineageOS 23.0 comporte une longue série de mises à jour de ses composants, ainsi que plusieurs évolutions importantes dans les applications, répercutées sur les versions plus anciennes du système. Aperture, dédiée à la prise de photos, a ainsi été intégralement réécrite. La maintenance en sera beaucoup plus simple selon l’équipe, et plusieurs fonctions ont été ajoutées, dont le support du JPEG Ultra HDR, du RAW et de la capture RAW+JPEG.

Le lecteur musical Twelve gagne plusieurs nouveautés lui aussi, dont un bouton pour lancer directement des musiques aléatoires, l’ajout d’informations supplémentaires sur l’écran de lecture, le support du MIDI (oui oui) ou encore la possibilité de relancer l’analyse de la base, pour détecter des titres ajoutés récemment.

Commentaires (25)

votre avatar
C'est moche de voir les dernières actions de Google pénaliser AOSP et les OS qui se basent dessus :-/

Du côté de GrapheneOS, ils ont accès aux patchs grâce à un partenariat avec un OEM encore mystérieux et peuvent donc les publier en avance mais ce qui est dommage, c'est qu'ils ne peuvent le faire que sous forme binaire donc l'OS n'est plus entièrement open-source si on accepte de recevoir ces preview releases.
https://discuss.grapheneos.org/d/27068-grapheneos-security-preview-releases
Sans compter le fait que l'augmentation de l'early access avant publication officielle des failles facilite le travail des pirates...
https://bsky.app/profile/grapheneos.org/post/3lyb7jg4yn22r
votre avatar
Oui, ça ressemble à une action délibéré me de Google pour pousser Android au détriment de AOSP.

C'est pas bon du tout sur le long terme, car on risque d'avoir une impossibilité technique sur le long terme d'avoir un OS mobile sécurisé.

Y'a pas à dire : l'avenir s'annonce brillant...
votre avatar
il peut peut-être encore y avoir du bon.

https://librephone.fsf.org/
https://goodtech.info/librephone-fsf-smartphone-libre/
votre avatar
Oui, le problème c’est qu’il va falloir être patient, trop patient.
votre avatar
Et quid des applications ? La force d'Apple et Google est le magasin d'application.
votre avatar
Moi j'imaginais une solution à base de waydroid, où chaque appli est lancée dans un container spécifique. Nul doute que Google détesterais ça (car impossible de créer un profil utilisateur).

Evidamment les notifications dans ce cas ne pourraient pas marcher - dans certains cas c'est pas plus mal
votre avatar
La force d'Apple et de Google est de nous forcer à utiliser leur magasin d'application. Sur Windows ou Linux, on installe ce qu'on veut. Pourquoi il n'en serait pas de même sur mobile ?
votre avatar
Je pense qu'il veut dire que la force de ces OS est la quantité d'applications disponibles.

Il n'y a qu'à voir l'échec de Microsoft arrivé après eux sur mobile malgré sa force de frappe et ses moyens : les développeurs d'applications dans leur grande majorité n'ont pas développé leur appli pour un troisième système.
votre avatar
Oui, merci, c'est ce que je voulais dire, mon propos n'était pas clair.
votre avatar
On ne peut pas trop en vouloir à Google non plus. C'est plus simple et moins cher de gerer seulement la branche interne, et de publier une version "nettoyée" tous les 3 mois.

Devoir gérer et synchroniser deux branches (interne et AOSP) mensuellement, c'est un effort que personne ne veut payer.
votre avatar
Devoir gérer et synchroniser deux branches (interne et AOSP) mensuellement, c'est un effort que personne ne veut payer.
Bref, autant le close-source :p
votre avatar
Ca sera p-e la stratégie pour Google Fuchsia.
votre avatar
C'est ridicule de parler "d'effort" quand c'est/c'était un argument marketing pour Google de proposer de l'open source, ce à quoi certains développeurs et certains utilisateurs finaux pouvaient prêter une oreille attentive, ce qui a pu jouer à certains moments clés pour qu'Android devienne l'OS mobile le plus utilisé.

Mais une fois qu'on a capté tout le monde dans son écosystème, et qu'il n'y a plus besoin de convaincre, on voit une fois de plus qu'on ne peut pas vraiment faire confiance à ces entreprises.
votre avatar
C'est ridicule de parler "d'effort" quand c'est/c'était un argument marketing pour Google de proposer de l'open source, ce à quoi certains développeurs et certains utilisateurs finaux pouvaient prêter une oreille attentive, ce qui a pu jouer à certains moments clés pour qu'Android devienne l'OS mobile le plus utilisé.
AOSP est toujours open-source que je sache, d'où son nom.
Rien n'a changé sur ce point.

Y a juste un délai de 3 mois au lieu d'1 mois dans la publication du code. A part pour les accros au codage/flashage de ROMs expérimentales, je ne vois pas de raison d'être outré de cet allongement de 2 mois.
votre avatar
Ben comme le dit l'article, c'est surtout pour les vulnérabilités que ça pose problème. Le reste on est d'accord, y'a pas urgence.
votre avatar
et donc dans quelques mois (années) , tu vas voir que Google va activement dénigrer les Custom ROM en disant qu'elles sont moins sécurisés - ce qui est vrai , elles auront toujours 3 mois de décalage - et justifier ainsi de ne plus maintenir AOSP.

C'est un peu le problème quand une société a des volontés hégémoniques : On ne supporte plus la moindre alternative, fut-elle minime, car c'est perçu non plus comme une source d'inspiration ou d'idée mais comme un risque commercial. Alors que bon, je pense que la proportion de personnes en custom ROM dans le monde, ça doit rester largement sous les 0.1%...
votre avatar
On ne peut pas trop en vouloir à Google non plus. C'est plus simple et moins cher de gerer seulement la branche interne, et de publier une version "nettoyée" tous les 3 mois.
C'est vrai ça. Pauvre Google. La firme a si peu d 'argent que ça doit être impossible pour elle de payer des gens pour gérer ça.
votre avatar
C'est vrai ça. Pauvre Google. La firme a si peu d 'argent que ça doit être impossible pour elle de payer des gens pour gérer ça.
Google n'a pas vocation à dépenser son argent pour faire plaisir à la communauté des libristes, surtout quand on voit leur réaction fasse à ce genre de news.

On devrait se réjouir que AOSP existe... car l'alternative c'est les OS fermés genre IOS.
Ceux qui s'inquiètent pour 2 mois de décalage ont tous le loisir de forker le projet AOSP et de nous montrer de quoi la "communauté" est capable.
votre avatar
Ceux qui s'inquiètent pour 2 mois de décalage ont tous le loisir de forker le projet AOSP et de nous montrer de quoi la "communauté" est capable.
C'est un peu ce qui se passe depuis un moment maintenant.

C'est une très bonne chose qu'AOSP existe, c'est pour ça que c'est triste de voir que Google semble le lâcher petit à petit.
votre avatar
C'est amené à disparaitre. Les futurs téléphones ne permettront plus d'installer un autre OS que celui fourni par le constructeur.
votre avatar
Et e/os n'est pas impacté ?
votre avatar
Si lineageOS est impacté, je ne vois pas comment /e/OS ne le serait pas.
votre avatar
Mince moi qui envisage d'y passer !
votre avatar
Si je ne m'abuse /e/ se base sur lineage donc mécaniquement ils doivent subir la même chose?
votre avatar
Donc si j'ai bien compris : cela ne bloque pas le portage, juste qu'il y aura plus de délai entre la dévouverte d'une faille et sa correction ?
Les weeklies sont concernés ou pas ?

LineageOS subit les changements de Google dans la politique de sécurité d’Android

  • Un fonctionnement plus opaque

  • LineageOS « s’adapte »

Fermer