1380

Ah mais si, il faut absolument installer les mises à jour de sécurité au plus vite, même pour les centrales nucléaires (je connais) et autres éléments critiques grin
Comment ça, il n'y a pas de support sécurité pour les machines des années 1970-1980 qui sont en DS1 et DS2 ?

Ma remarque que vous citez, dans la ligne de la phrase précédente, concernait davantage le côté développement du code (où quelles que puissent être leurs qualités, Rust et Go ne pourront avoir aucune chance avec un logiciel de pensée obsolète "mais il ne faut pas que ça bouge pendant des mois" alors qu'il y a une nouvelle release majeure toutes les quelques semaines, et des mises à jour de sécurité plus fréquentes que ça - c'est sûr que mieux vaut rester sur du C/C++, utiliser un compilo antédiluvien, ne jamais mettre à jour les dépendances externes...) que le côté déploiement en production, sans filtre, des mises à jour de sécurité.

Ceci étant dit, on sait que le côté production ne va pas du tout. J'ai tendance à penser que l'impact des régressions dues à des mises à jour de sécurité est sur-estimé (sur des dizaines de machines Linux et des années, la plupart dans des DMZ Internet où il faut donc faire un peu attention, je ne me souviens vraiment pas de grand chose de ce type; si ça a cassé indirectement du code peu sûr qui dépendait d'autre code, c'est une bonne occasion de le corriger), et le coût de ne pas faire les mises à jour de sécurité est sous-estimé - bref, l'étude de risque est mal faite.
En lisant les news, on entend parler des responsables de production qui perdent des jours de production, et des données indispendables, à cause d'un ransomware qui a pu s'installer parce que le réseau n'est pas architecturé (tout à plat, ou presque), et que le parc n'est pas géré, et que des machines vulnérables à EternalBlue, BlueKeep et autres vulnérabilités critiques corrigées depuis des mois à des années n'ont jamais été patchées. L'impact de ce genre d'événements (probabilité plus ou moins élevée * gros dégâts) est élevé. Je ne sais plus la proportion, mais pour les PME, une attaque de ransomware ou une exfiltration de données sont un coup très dur, sinon fatal à la structure. Tout ça a un coût, qui est mal pris en compte et mal géré...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1381

Je suis d'accord qu'il faudrait utiliser des langages plus sûrs (je l'ai déjà dit : je considère par exemple que MISRA C est le parfait exemple que le C n'est pas un bon langage pour faire de l'embarqué critique), mais :

Lionel Debroux (./1380) :
Rust et Go ne pourront avoir aucune chance avec un logiciel de pensée obsolète "mais il ne faut pas que ça bouge pendant des mois" alors qu'il y a une nouvelle release majeure toutes les quelques semaines
Ce n'est pas un modèle de pensée obsolète, c'est une réalité. Quand tu développes un projet sérieux, la phase de réflexion et de planification peut être longue. Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.

Tu m'objecteras probablement le "release early, release often" et autres "move fast and break things", mais les projets qui utilisent ce genre de philosophies peuvent se permettre de sortir des MVP et d'avoir des régressions en production. C'est un critère éliminatoire pour tout projet qui a un minimum de criticité. Si je voulais être mauvaise langue, j'ajouterais que les résultats sont souvent médiocres, aussi bien en matière de qualité logicielle qu'en terme de qualité pour l'utilisateur.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions. Ça ne veut pas dire qu'il ne doit pas y avoir de correction des bugs liés à la sécurité bien sûr, mais qu'il n'est pas question de changer des trucs fondamentaux d'une release à l'autre.

Trop souvent, "on veut garder la liberté de faire des évolutions majeures n'importe quand pour améliorer" est une excuse pour ne pas avouer "on n'a pas réfléchi à la conception, on navigue à vue et on verra ce que ça donne".
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1382

./1380 J'ai l'impression à te lire que si on n'applique pas une politique de sécurité extrême avec des mises à jour aussi souvent que possible, alors c'est qu'on ne fait rien du tout et qu'on court un très gros risque.

Pour ce que je fais en développement, la sécurité est la dernière des préoccupations. Faire un démonstrateur d'un algorithme, une implémentation pour effectuer des mesures ou une modélisation ne présente aucun risque en matière de sécurité. Prendre du temps à tout protéger ou faire des mises à jour serait seulement une perte. Et on ne va certainement pas faire une mise à jour d'un composant la veille d'une démonstration grin
avatar

1383

RHJPP > ce n'est pas pour autant qu'il ne faut pas le faire en sécurité : dans certains domaines de recherche industriels (avec. beaucoup de $$$ derrière), il est envisageable (je pense même que ça s'est déjà vu même si je n'ai pas de preuve) de modifier le code expérimental pour qu'il renvoie des valeurs légèrement fausses.
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1384

Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.
Certes, mais Rust et Go sont tous les deux, depuis des années, dans une phase où l'utilisation d'une nouvelle release ne remet pas tout en chantier. Et c'est heureux. Les grosses casses de compatibilité seraient pour des versions 2 des langages.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions.
Peut-être que des entités prendront, pour ces langages, le rôle qu'ont Redhat, SUSE et quelques autres pour les distributions Linux, ou maintenant même Java pour RedHat puisqu'Oracle veut passer à des mises à jour rapides pour Java, comme le dont déjà la plupart des autres langages: figer une release pour un temps certain, en n'y appliquant qu'un sous-ensemble des mises à jour de sécurité. Ca pourrait être une solution pour contenter à peu près à la fois:
* ceux qui veulent et peuvent développer plus rapidement du code qui aura moins de bugs, quitte à traiter des casses de compatibilité antérieures sur des éléments mal faits de la toolchain, de la lib standard ou de certaines dépendances (l'écosystème Go a des soucis avec les modules, ça n'a pas été bien fait au départ, le passage aux modules est apparemment un mauvais moment à passer mais après, ça va plutôt mieux à long terme), et des obsolescences logicielles au fil de l'eau: ils resteront sur les versions à évolution rapide;
* ceux qui veulent rester sur une base qui n'évolue que rarement, avec des releases rares, une faible mise à jour des dépendances, et donc en général un déploiement en rares big bangs coûteux. Les projets avec un certain niveau de criticité seront en général dans cette catégorie, nous sommes d'accord smile

Sur RHEL 7.5, 7.6 et 7.7, Redhat a fait un travail moins limité que précédemment d'upgrade de packages user-space, pour des raisons à la fois de sécurité et de fonctionnalité. Peu d'upstreams fournissent un support sécurité sur 5 ans, c'est à la fois un principe de réalité (la maintenance des versions anciennes, et le packaging desdites versions, ont un coût, alors que beaucoup de projets et distributions ont déjà du mal à vivre...) et une bonne chose pour inciter à / forcer des upgrades vers des versions développées selon des standards et méthodes plus modernes. Ce travail d'upgrade réduit un peu la dangerosité de l'assemblage RHEL 7.x causée par les toolchains par défaut qui ne changent pas (GCC 4.8, donc absence ou faible diffusion des mitigations un tant soit peu récentes, PIE / relro / bindnow / etc.), les packages qui n'ont pas été mis à jour alors que des versions plus récentes contiennent des mises à jour de sécurité qui ne sont pas toujours clairement labelisées comme telles, la mauvaise car difficile maintenance du fork d'une version vraiment antique du kernel (les travaux de spender indiquent qu'il manque des centaines de patches de sécurité dans tous les kernels LTS, mainline comme vendor), etc..

J'ai l'impression à te lire que si on n'applique pas une politique de sécurité extrême avec des mises à jour aussi souvent que possible, alors c'est qu'on ne fait rien du tout et qu'on court un très gros risque.
Ca dépend sur quoi. Pour certains composants très largement répandus, une surface d'attaque élevée, avec un niveau de privilège élevé, des moyens d'accès à distance et/ou des PoC publics d'attaque, c'est un fait qu'on peut courir de gros risques si on ne fait pas les mises à jour de manière assidue. Pour des packages que presque personne n'utilise, même s'il y a de très gros problèmes, le risque qu'on prend à ne pas faire des mises à jour tout de suite est beaucoup plus faible, bien sûr.

Sur toutes mes machines perso, et la plupart des machines pro que j'administre (la plupart des machines Debian, et encore une fois, en environnement spécial où on est censés faire les mises à jour), unattended-upgrades est installé. Mes machines perso, et une machine pro, utilisent Debian sid, parce que dans les Debian, c'est ça qui permet d'avoir accès à des versions plus récentes qui ont en moyenne moins de vulnérabilités, à davantage de mitigations, etc. Il n'y a pas de support sécurité sur testing, et le support sécurité de stable - comme celui de toutes les distributions stables - laisse à désirer.
Ce n'est pas parce que les diverses équipes sécurité font mal leur travail que les distributions stables ont un support de sécurité loin d'être parfait. C'est parce qu'ils n'ont pas assez de moyens et que les informations dont ces équipes disposent sont très partielles: beaucoup de mises à jour de sécurité, y compris pour des packages largement utilisés, ne sont pas annoncées comme telles, pour quantité de raisons (à une époque, difficulté d'obtenir des assignations de CVE IDs; difficulté de se rendre compte que certains changements sont des mises à jour de sécurité; autre chose à faire que de détailler les problèmes et corrections; volonté de cacher les problèmes de sécurité; j'en passe). Même pour des packages populaires, presque toutes les mises à jour de sécurité issues de mes jobs de fuzzing ont été assez silencieuses, sans CVE IDs, donc elles ont été peu backportées vers les distros stables. Il y avait probablement peu d'ACE dans le lot, c'est vrai, mais énormément de DoS.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1385

RHJPP > Que la sécurité du code de prototypes de recherche ou industriels soit secondaire, je peux le comprendre (même si l'argument de Flan est tout à fait recevable). Par contre, tu as toute la sécurité périphérique : si ton environnement de travail est corrompu (vol de données par quelqu'un qui va breveter ta découverte, destruction des données, corruption du code ou de l'environnement d'exécution...) tu risques d'avoir des problèmes. Ce n'est pas pour rien qu'en 10 ans, l'application des règles de sécurité du CNRS a pris un nouveau tournant (même si mes amis les chercheurs ont les habitudes bien ancrées ^^).
avatar

1386

Ha oui, mais il n'était question que des développements que l'on fait.
On a bien sûr des contraintes de confidentialité et de sécurité pour notre système informatique. Il est déjà arrivé qu'un partenaire vienne faire un audit avant le début d'une étude ou nous demande de mettre en place des mesures particulières comme une isolation des machines utilisées et une restriction de l'accès aux locaux. On a aussi quelques fois des demandes étonnantes comme l'autorisation de diffuser des résultats, mais seulement si on ne donne pas les unités grin

Par contre, on ne mettra pas forcément à jour une librairie utilisée par un démonstrateur uniquement pour combler une faille de sécurité si ça n'a pas la moindre importance.
avatar

1387

Lionel Debroux (./1384) :
Sur toutes mes machines perso, et la plupart des machines pro que j'administre (la plupart des machines Debian, et encore une fois, en environnement spécial où on est censés faire les mises à jour), unattended-upgrades est installé.
Autant c'est important de faire les mises à jour de sécurité régulièrement, autant je suis persuadé que les installer automatiquement est une bombe à retardement (je pense la même chose des mises à jour auto de Windows 10, évidemment).
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1388

Cette configuration ne serait pas adaptée chez nous. Tu n'imagines pas les réactions qu'entrainerait le redémarrage imprévu d'une machine pour faire une mise à jour alors que ça faisait deux semaines qu’elle était en train de réaliser un calcul ^^

À moins que le redémarrage automatique soit désactivé, mais dans ce cas, la sécurité n'est pas assurée embarrassed
avatar

1389

(couplet sur le fait que Linux n'a pas besoin de redémarrer pour appliquer les mises à jour, etc. dans 3... 2... 1... ^^)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1390

Un tel couplet serait inapproprié smile
Pour appliquer des mises à jour de sécurité, moins besoin de redémarrer que Windows qui verrouille les fichiers du système en utilisation (sans que ça empêche significativement les malwares de fonctionner et de se rendre persistants, mais je ne suis pas sûr que cette pratique ait été à l'origine faite pour la sécurité ?), oui. Mais il est également un fait que comme les autres, les distros Linux et les BSD ont besoin de redémarrer pour appliquer certaines mises à jour, que ce soit le kernel dont presque toutes les mises à jour sont de sécurité (il y a quelques mises à jour qui contiennent un seul patch pour corriger une grosse erreur de compilation, par exemple, mais à part ça, peu de gens utilisent kexec / KSplice / KGraft / etc., qui réduisent la nécessité de rebooter), le daemon D-Bus qui a plusieurs vulnérabilités significatives dans l'année et dont le design ne permet pas de redémarrer, certains daemons systemd je crois, etc.

Des calculs qui prennent des semaines, sans possibilité de les redémarrer efficacement, j'en fais parfois, pour les sessions de fuzzing justement.

Stable. Sécurisé. Choisissez l'un ou l'autre smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1391

C'est pas tellement l'un ou l'autre qu'un compromis à trouver entre les deux en fonction de l'étude de risques ^^
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1392

Uther (./1372) :
A voir. On a des langage plus sécurisés que le C comme l'Ada depuis longtemps et ça n'a pas pris. Rust a l'air mieux parti, mais il est encore trop jeune pour convaincre les milieux sécurisé, qui aiment bien les outils qui ont fait leur preuve depuis longtemps.

+1 pour l'Ada ! Après je te rejoins sur la jeunesse de Rust mais avec des Mozilla et l'ANSSI qui poussent des projets derrière ça va permettre d'accélérer l'adoption du langage notamment dans le milieu de la sécuirté à mon sens !
avatar"If you see strict DRM and copy protection that threatens the preservation of history, fight it: copy the work, keep it safe, and eventually share it so it never disappears. [...] no one living 500 years from now will judge your infringing deeds harshly when they can load up an ancient program and see it for themselves."

Benj Edwards - Why History Needs Software Piracy

- - -
Achat ou échange: topic de mes recherches

1393

Interessant comme certains veulent vendre le release-early/release-often comme une mesure de sécuritée.

Le jour ou les fabricant d'avion, machin special ou reacteurs nucleaire commence dans ce domaine, on va pouvoir vraiment se preparer au pire.

Le RE/RO est l'antithese de la sécurité. En fait c'est meme le meilleur moyen de corriger ce meme truc en insinuant que ca a été fait pour etre plus sécurisé, alors qu'en fait c'est tout l'inverse.

Une partie des problemes actuels en terme de sécurité est a cause de cette politique.

Release when Ready and Tested, est la seule chose valable.

On le vois bien dans le domaine du JV par exemple. Bien sur les jeux n'etait pas bug-free a l’époque, mais le fait de devoir les livrer sur un media qu'on ne peux pas changer forçait les dev a faire plus d'effort. De nos jour, certains jeux sortent en version "finale" avec tellement de bug qu'une version alpha a l'ancienne semblerais bug-free. Mais maintenant on peux envoyer des patches 3x plus gros que le jeu d'origine, OSEF, ca corrige au moins un des probleme tout en ajoutant de nouveau, mais on pourra toujours patcher plus tard.

Voila la mentalité du RE/RO.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1394

Le truc c'est qu'on ne peu pas comparer les release régulière pratiquées par les navigateurs (ou le compilateur Rust) avec ce qui est fait dans d'autre secteurs comme le jeux vidéo. Sortir énormément de fonctionnalité avec des betas au final peu testée, c'est pas forcément mieux qu'un nombre limité de fonctionnalité dont on est sur qu'il est resté un temps suffisant en test.

Il faut voir que les sorties périodiques ne veulent absolument pas dire que l'on fait n'importe quoi. "Release when Ready and Tested" n'est pas incompatible avec un cycle rapide, je dirais même au contraire que c'est un prérequis indispensable à un cycle rapide sérieux. Les nouveautés sont développées dans la branche Nightly qui est activement utilisée est testée, et elles peuvent y rester des années si nécessaire. Elles ne sont introduites dans la beta et donc que lorsque l'on estime qu'elles sont stabilisées ou il faudra encore plusieurs semaines de tests avant d'arriver dans une version officielle.
Au contraire de ce que tu semble supposer, il y a d'autant moins de pression pour introduire une fonctionnalité non stable, étant donné que si une fonctionnalité n'est pas prête à temps, ça ne décale sa disponibilité que de quelques semaines.
avatar

1395

Je ne suis pas sur que tu te rende compte que des systemes de la complexité d'un navigateur web, quand tu ajoute une nouvelle feature, et que tu veux releaser, tu ne teste pas que la nouvelle feature. Il faut refaire une campagne QA sur l'ensemble du truc si tu veux etre sur qu'il n'y a aucune regression.

Et tout n'est pas automatisable.

Et en l'occurence, les navigateurs et ce que les promoteurs du RE/RO ne font pas c'est de faire ces tests de manière globale. Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité, c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.

La mentalité RE/RO est de construire un château de carte et de s’étonner qu'il s’écroule pour refaire la même chose encore et encore et encore.

Et si le JV est pertinent car c'est exactement le meme probleme.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1396

Godzil (./1395) :
Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité, c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.
Je ne trouve pas, au contraire... Les moteurs de rendu des navigateurs sont éprouvés, et les évolutions majeures sont développées et testées sur plusieurs mois/années... Typiquement, il a fallu 2 ans et 2 mois avant qu'Electrolysis passe du canal Trunk au canal Release (et actif par défaut pour tout le monde) ; 1 an et 4 mois si on prend la fourchette basse pour que les premiers échantillons d'utilisateurs (1cheeky du canal Release soient affectés. C'est tout sauf du release often à l'aveugle, je trouve...
avatar

1397

Godzil (./1395) :
Je ne suis pas sur que tu te rende compte que des systemes de la complexité d'un navigateur web, quand tu ajoute une nouvelle feature, et que tu veux releaser, tu ne teste pas que la nouvelle feature. Il faut refaire une campagne QA sur l'ensemble du truc si tu veux etre sur qu'il n'y a aucune regression.
Sauf que la non régression suite à une nouvelle fonctionnalité est faite sur Nightly (qui n'est pas qu'une branche ou on commite ses dev). Les tests automatiques sont joués en permanence et sont très poussés au point qu'il n'y a pas besoin de tant de tests manuels que ça. Certaines fonctionnalités y restent des années. Seules les fonctionnalité considérées stabilisées passent en phase beta.

Godzil (./1395) :
Et en l’occurrence, les navigateurs et ce que les promoteurs du RE/RO ne font pas c'est de faire ces tests de manière globale. Quand on vois a quel point la qualité des navigateur a baissé entre conso mémoire, CPU et autre ce n'est pas que lié a la complexité

Tu te bases sur autre chose que ton ressenti personnel ? Parce que j'ai vraiment l'impression inverse. Je trouve les navigateurs actuels bien plus stables et moins bugués qu'à l'époque où ils faisaient des sorties événementielles. Je trouve très rarement des choses qui relèvent clairement du vilain bug dans les navigateurs actuels alors que j'en trouvais en pagaille à l'époque. C'est d'autant plus remarquable que la complexité des navigateurs Web a explosé.

Comparer la consommation mémoire, n'a aucun sens, car comme tu le dis la complexité a changé et c'est clairement un point à prendre en compte. La complexité a explosé aussi bien du coté des moteurs que des sites web, ça rend toute comparaison directe caduque.

Et puis il y avait au moins autant de problèmes de performances à l'époque des sorties évènementielles. Je me souviens notamment de Firefox 3 et 4 qui ont du subir de grosses cure d'allègement via les version mineures suivantes, justement parce la nécessité de faire de grosses sorties, avec beaucoup de fonctionnalités, dans un délai raisonnable avait obliger à privilégier les fonctionnalités aux performances.

Godzil (./1395) :
c'est aussi lié au faut qu'on patche ici et la pour masquer les vrai problèmes et on fait une nouvelle feature qu'on teste, qui casse un autre truc que personne n'a vu et on continue sur la même lancé.
La encore j'ai l'impression que cette affirmation ne repose que sur ton extrapolation personnelle du fonctionnement d'équipes que tu ne connais pas. Ce que tu décris ressemble simplement à un environnement de travail non maitrisé, et ça n'a pas grand chose à voir avec le mode de sortie. Je dirais même au contraire que pour assurer des sorties régulières sérieuses, l’environnement se doit d'être maitrisé.

Godzil (./1395) :
La mentalité RE/RO est de construire un château de carte et de s’étonner qu'il s’écroule pour refaire la même chose encore et encore et encore.

Et si le JV est pertinent car c'est exactement le meme probleme.
Non, ça c'est juste du développement à La Rache™ et c'est en effet comme ça que sont gérés beaucoup trop de jeux-vidéos de nos jour vu qu'ils ont généralement des deadlines impératives, peu de considération pour la qualité et absolument aucunes pour la sécurité. Résultat on sort des produits non finis.

Les sorties périodiques permettent justement de ne pas être autant contraint par les deadlines. Les fonctionnalité prêtes sortent, et celles qui ne le sont pas attendent simplement le prochain cycle qui n'est que quelque semaines plus tard.
avatar

1398

En résumé, il y a une différence entre le Release Often et le Release Early, Release Often si cher à Kevin ^^


Il est possible de faire du Release Often tout en conservant la qualité… mais ça coûte cher. Du coup, quand il faut faire un choix entre « plein de fonctions utiles mais parfois bugguées » et « pas trop de fonctions utiles mais hyper fiables », je comprends que le second choix ne soit pas toujours le meilleur ^^
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1399

Je suis d'accord avec ça, RO != RERO et RO ne force pas nécessairement une mauvaise qualité.

https://langui.sh/2019/07/23/apple-memory-safety/ : sans surprise, chez Apple aussi, l'absence de sûreté mémoire est la cause majoritaire des vulnérabilités importantes.
Mais je les vois mal adopter Rust, vu qu'ils ont Swift, à ma connaissance nettement moins populaire hors de l'écosystème Apple que Go et Rust, préférés pour les logiciels portables.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1400

Lionel Debroux (./1399) :
Mais je les vois mal adopter Rust, vu qu'ils ont Swift, à ma connaissance nettement moins populaire hors de l'écosystème Apple que Go et Rust, préférés pour les logiciels portables.
De ce que j'avais lu, dans sa dernière version, Swift intégrerait en partie certaines des fonctionnalités qui font la particularité de Rust. J'ai pas regardé en détail mais si Swift devient viable pour la programmation système sure, ça peut devenir intéressant.
avatar

1401

Swift a toujours été pensé pour faire de la programmation système, avec. pas mal de garanties (mais pas autant que pour Rust) tout en restant très concis (on est assez proche du Python).
Ça fait quelques années qu'il fonctionne sur Ubuntu (au moins), mais c'est sûr qu'en termes de popularité sur Linux est assez loin…
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1402

CVE-2019-1125: Spectre SWAPGS gadget vulnerability - Red Hat Customer PortalRed Hat Customer PortalThis article presents background information and a resolution for the Spectre-like "SWAPGS" processor side-channel vulnerability.

new spectre v1 variant: CVE-2019-1125 Spectre SWAPGS gadget vulnerability · Issue #301 · speed47/spectre-meltdown-checkerGitHubthis vulnerability is mitigated in today&#39;s kernel releases (5.2.7, 4.19.65, 4.14.137, 4.9.188, 4.4.188). mitigation is indicated by Mitigation: usercopy/swapgs barriers and __user pointer sanit...

et autres: une nouvelle petite variante de Spectre v1 a été publiée aujourd'hui, patchée dans les kernels Linux stables, et les updates vont arriver dans les diverses distros des divers OS.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

1403

https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/ :
Today Microsoft released a set of fixes for Remote Desktop Services that include two critical Remote Code Execution (RCE) vulnerabilities, CVE-2019-1181 and CVE-2019-1182. Like the previously-fixed ‘BlueKeep’ vulnerability (CVE-2019-0708), these two vulnerabilities are also ‘wormable’, meaning that any future malware that exploits these could propagate from vulnerable computer to vulnerable computer without user interaction.

The affected versions of Windows are Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, and all supported versions of Windows 10, including server versions.

Windows XP, Windows Server 2003, and Windows Server 2008 are not affected, nor is the Remote Desktop Protocol (RDP) itself affected.

(...)

It is important that affected systems are patched as quickly as possible because of the elevated risks associated with wormable vulnerabilities like these, and downloads for these can be found in the Microsoft Security Update Guide.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1404

https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html

TL;DR : faille massive (et présente depuis de multiples versions de l'OS) dans la gestion de l'entrée de texte de Windows. Ça permet d'exécuter du code dans un autre processus, même si ce dernier a un niveau de privilège supérieur.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1405

Wow ! Et l'article vaut la lecture, merci pour le lien et le résumé smile
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

1406

De rien smile
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1407

epee
Et ça n'a pas l'air simple à corriger, en plus :/
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1408

Non en effet, et c'est ça qui est inquiétant sorry
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

1409

Tout refaire j’en ai peur
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

1410

Les posts du blog P0 sont en général un régal. Non seulement les membres du Project Zero sont très forts techniquement, mais au moins certains d'entre eux savent bien rédiger.

Huge Survey of Firmware Finds No Security Gains in 15 YearsThe Security LedgerA survey of more than 6,000 firmware images spanning more than a decade finds no improvement in firmware security and lax security standards for the software running connected devices by Linksys, N…

Super smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.