Toujours pareil, l'engineering a certains besoins (debug, automatisation) qui vont à l'encontre des règles de sécurité. Donc l'engineering va développer des backdoor là ou ça l'intéresse.
Si c'est une équipe différente (orientée produit) qui est en charge de récupérer le boulot de l'engineering pour le packager (éventuellement l'adapter) et le livrer au client, il y aura toujours des soucis de communication possible.
"On croyait que vous alliez nettoyer", "on croyait que vous nous aviez pas livré de la merde".
De plus, les tests (automatisé souvent) de qualité sont particulièrement orientés fonctionnalités (ça marche ou ça marche pas ?), souvent orienté performance (conso elec, perfos globales), mais rarement sécurité. Et ça se comprend aussi, parce que sécurité... que tester ? Comment automatiser un mec ingénu qui est capable de passer des semaines/mois à contourner des barrières qu'on a mis en place ? Donc il y a 2-3 sanity checks qui sont effectués (par exemple SELinux activé ? les bonnes partitions read-only ?), mais globalement on teste pas d'aller farfouiller partout pour voir si une backdoor traîne pas.
Le soucis principal est réellement de la communication (documenter, écrire une méthode de nettoyage, se mettre d'accord sur des #ifdef etc), mais comme souvent ce sont des équipes différentes, voire des entités (département) différentes... bin ça peut foirer... oui :(
(vous noterez mon expertise dans le sujet... je suis le co-auteur d'une faille bien involontaire qui a permis quelques root de tablettes... pas la peine de demander plus de précision, vous ne saurez rien de plus :) )
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Code source
Posté par gUI (Mastodon) . En réponse au journal Allwinner, p'tit trou dans le noyau.. Évalué à 10.
Et oui c'est possible...
Toujours pareil, l'engineering a certains besoins (debug, automatisation) qui vont à l'encontre des règles de sécurité. Donc l'engineering va développer des backdoor là ou ça l'intéresse.
Si c'est une équipe différente (orientée produit) qui est en charge de récupérer le boulot de l'engineering pour le packager (éventuellement l'adapter) et le livrer au client, il y aura toujours des soucis de communication possible.
"On croyait que vous alliez nettoyer", "on croyait que vous nous aviez pas livré de la merde".
De plus, les tests (automatisé souvent) de qualité sont particulièrement orientés fonctionnalités (ça marche ou ça marche pas ?), souvent orienté performance (conso elec, perfos globales), mais rarement sécurité. Et ça se comprend aussi, parce que sécurité... que tester ? Comment automatiser un mec ingénu qui est capable de passer des semaines/mois à contourner des barrières qu'on a mis en place ? Donc il y a 2-3 sanity checks qui sont effectués (par exemple SELinux activé ? les bonnes partitions read-only ?), mais globalement on teste pas d'aller farfouiller partout pour voir si une backdoor traîne pas.
Le soucis principal est réellement de la communication (documenter, écrire une méthode de nettoyage, se mettre d'accord sur des #ifdef etc), mais comme souvent ce sont des équipes différentes, voire des entités (département) différentes... bin ça peut foirer... oui :(
(vous noterez mon expertise dans le sujet... je suis le co-auteur d'une faille bien involontaire qui a permis quelques root de tablettes... pas la peine de demander plus de précision, vous ne saurez rien de plus :) )
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.