Version imprimable du sujet

Écrit par : Lionel 10 Oct 2017, 11:21

High Sierra a démarré sa carrière avec un bug touchant la sécurité des volumes chiffrés.Le mot de passe se retrouvé affiché en clair à la place de l'indice.
Apple l'a rapidement réglé heureusement.

Le site Cocoaengineering.com a décortiqué la mise à jour proposée par Apple pour comprendre ce qui a provoqué ce bug.

Pour résumer les choses, le code contenait une erreur de variable. Dans ce code, il y a (entre autres choses) une variable dans laquelle est stocké le code choisi par l'utilisateur, et une autre pour l'indice.
Il s'avère que lors du renvoi de ces variables, le développeur a fait l'erreur d'utiliser dans les deux cas la variable mot de passe, qui a donc remplacé celle contenant l'indice. C'est une erreur toute bête comme tous ceux qui ont développé en ont connu, mais ici elle a provoqué un problème grave, mais difficile à détecter puisque n'induisant aucun plantage.

La bonne nouvelle est qu'une fois le code corrigé le problème ne se pose plus. La mauvaise reste la nécessité de reformater les volumes pour s'en débarrasser.

http://macbidouille.com/news/2017/10/10/les-raisons-du-bug-de-mot-de-passe-de-high-sierra

Écrit par : raoulito 10 Oct 2017, 11:28

attend.. quand même !! une équipe d eQA qui ne regarde pas l'indice lors de la création d'une volume ou son déverrouillage ? Je sais qu'ils ont bcp de taff et pleins de choses à voir, mais quand même ! S'ils ne sont que 10 je comprend, s'ils sont 100 c'est injustifiable. J'ajoute que les limites de l'énorme beta testing sur plusieurs niveaux prouve là aussi sa limite...

Écrit par : Lionel 10 Oct 2017, 11:35

Je me mettais dans la peau du gars qui a codé cette partie. Une erreur arrive. En revanche, on sait qu'il y a un vrai problème de contrôle qualité chez Apple depuis un bon moment.

Écrit par : Macbox 10 Oct 2017, 11:40

Wouaaaa, top top top!


Ils n'ont aucune checklist des choses à vérifier, d'une mise à jour à l'autre?

Écrit par : Lionel 10 Oct 2017, 11:50

Sisi, pour suivre le cours AAPL et sortir un produit, faire une annonce ou lancer une rumeur quand c'est nécessaire.

Écrit par : Macbox 10 Oct 2017, 11:51

Écrit par : divoli 10 Oct 2017, 11:52

C'est vrai que ça ne doit pas sentir très bon pour lui, en ce moment.

Écrit par : fedorinux 10 Oct 2017, 12:00

Insuffisant dans certains cas. Pour une image disque sur un stockage en ligne, il faut considérer le mot de passe comme corrompu et en changer définitivement.

Écrit par : malloc 10 Oct 2017, 12:26

+1

Ce genre d'erreur saute aux yeux lors d'un code review par des pairs... C'est pour cela que je pensais initialement que l'erreur devait venir de dev "à la souris" (beaucoup plus dur à relire).
Que ce soit un échange de variable en dit long sur l'efficacité du process de validation des révisions. Si des échanges de variables passent entre les mailles du filet, on se demande ce qu'ils trouvent

Écrit par : sansnom 10 Oct 2017, 12:36

Question de béotien : n'existe-t-il pas des robots logiciels ou des procédures automatisées à lancer avant déploiement afin d'effectuer des tâches particulières de test (suivi des variables, gestion des ressources...)... histoire de déverminer le bouzin ?...

Je crois me souvenir qu'une partie des développements logiciels de la firme sont sous-traités en Inde : est-ce toujours le cas et serait-ce la source du problème (malgré la très bonne réputation des ingénieurs Indiens) ?...

Écrit par : Bunios 10 Oct 2017, 12:38

Bien vu......

Écrit par : yponomeute 10 Oct 2017, 12:44

Cela saute aussi "aux yeux" si c'est couvert par un test unitaire.

Écrit par : Lionel 10 Oct 2017, 12:46

On le voit à chaque fois, il faut 10 mois et un bêta test à échelle 1 pour arriver à rendre un système stable. Dès qu'il l'est, on sort le suivant.

Écrit par : malloc 10 Oct 2017, 12:46

Si bien sûr, et c'est souvent mis en place, mais en pratique rien ne remplace une revue humaine, surtout quand elle est faite avec sérieux.
Rien de tel que devoir justifier chaque mot ajouté dans le code à un collègue pour éviter les bourdes.

On le fait pour tous les systèmes industriels critiques (souvent, les revues sont même faites à plusieurs et là c'est *très* long mais rien n'échappe). Je veux bien qu'Apple ne le fasse pas pour iPhoto (et encore), mais pour un composant de sécurité de l'OS... C'est vraiment pas sérieux :-/

Écrit par : iiolivier 10 Oct 2017, 12:54

Tout ceci est parfaitement argumentable, excusable, pardonnable, compréhensible, pour n'importe quelle entreprise au monde....

SAUF...

SAUF...


pour une entreprise qui fait plus de 70 MILLIARD de dollards de bénéfices, qui pourrait mettre 2, 3 4, 5 , 6, 7 personnes en relecture de code 24/24 avant de pondre une bétise d'une telle énormité, que c'est


totalement...


.. INEXCUSABLE

C'est vraiment inexcusable de laisser passer un tel bug. les mots de manque tellement c'est déplorable.

Le type qui a codé un tel bug n'a aucun reproche à se faire.

C'est le fait d'avoir laissé passé un tel bug qui doit effrayer + d'un developpeur.

Attendez.... imaginez un développeur qui est faché avec Apple et qui sait qu'il va se faire virer dans 2 semaines. Il fou un rm -rf dans une mise à jour MAJEURE du système et il détruit tout. Y compris si il a envie les volumes TIMEMACHINE associé au moment de l'installation ?

Mais fuyez Apple, fuyez cette arnaque totale. C'est une honte. Ca passe comme une News habituelle, mais c'est une vrai honte.

Écrit par : Beaubarre 10 Oct 2017, 12:57

Je ne comprends pas pourquoi le mot de passe est transmis en clair.

A minima ne devrait il pas être codé de telle façon que le programme ne connaisse que sa transformation?

C'est comme si etc/passwd était en plain text ?

Au-delà de l'erreur, c'est un grave problème de conception, sinon n'importe quel programme avec assez de privilèges va pouvoir lire le mot de passe en clair.

Écrit par : iiolivier 10 Oct 2017, 13:02

J'ai vraiment du mal à comprendre qu'un mot de passe, un fois arrivé dans le système ne soit pas immédiatement masqué / encodé, ou je ne sais quoi. Il n'y a aucune raison valable pour le garder en clair, à aucun endroit. Sauf si on mélange indice et mot de passe c'est vrai....

Mais moi perso, suite à ce bug, je vais lacher mon MacBook pour autre chose car c'est trop honteux. Pire que n'importe quel bug.

Écrit par : ob1 10 Oct 2017, 13:04

<Mode hors-sujet ironico-polémique>Il aurait fallu mettre en place un framework de nommage de variables.</Mode hors-sujet ironico-polémique>

Écrit par : sansnom 10 Oct 2017, 13:05

D'un côté, une variable de quelques octets. Une petite merde quoi !...
De l'autre, des utilisateurs qui doivent reformater à zéro leurs volumes !...
Ce monde n'est plus équitable (s'il l'a déjà été ?...)...

Écrit par : divoli 10 Oct 2017, 13:08

Je ne suis pas certain que ce soit l'avis d'Apple, vois-tu (j'ai d'ailleurs un peu de mal avec ce concept qui ferait que, lorsque l'on a fait une erreur, on n'a rien à se reprocher, qui plus est lorsque ladite erreur a de très fâcheuses conséquences). À cette erreur, s'est ajoutée une insuffisance au niveau du contrôle qualité, ça fait beaucoup. Et en bout de course c'est une personne extérieure à Apple, et heureusement bien intentionnée, qui a repéré et signalé l'erreur rapidement. Au final cela peut donner l'impression que les équipes de développement sont constituées de bras cassés.

Écrit par : Eagle Kiss 10 Oct 2017, 13:16

Écrit par : marc_os 10 Oct 2017, 13:18

Il n'y a que ceux qui ne font rien qui ne se trompent jamais.

Écrit par : Hebus 10 Oct 2017, 13:20

Des tests unitaires, des tests d’intégration ce sont des programmes en plus du programme, donc y a des bugs aussi

Tout tester est impossible, meme quand on fait du dev piloté par les tests (test driven development ou TDD)

Écrit par : divoli 10 Oct 2017, 13:23

Ou quand quelqu'un qui travaille comme un cochon essaye de trouver des excuses.

Écrit par : Homer Simpson 10 Oct 2017, 13:26

Mais euh. Y'a personne qui relis le code derrière le premier ???

Écrit par : marc_os 10 Oct 2017, 13:28

Le mot de passe est très certainement chiffré immédiatement.
Mais il y a bien une étape où il est en clair : A la saisie (on peut regarder au dessus de ton épaule), et pendant la transmission du mot de passe en clair au code qui va le chiffrer. Or c'est au niveau cette étape de transmission du mot de passe saisi en clair que s'est situé le bogue. Il y a deux variables : Une pour le mot de passe (en clair) et une pour l'indice (en clair). Le module de chiffrement lit la variable du mot de passe et le module de stockage de l'indice lit la variable de l'indice. Et c'est là qu'a eu lieu l'erreur : Le module de stockage de l'indice a lu la variable du mot de passe. Il n'y a rien de scandaleux, il s'agit d'une erreur très stupide au mauvais endroit, corrigée promptement par Apple. Ceci dit, il est clair aussi que la QA d'Apple a merdé également de son côté.

C'est une erreur qui craint, c'est clair , mais cependant je serais curieux de savoir combien de personnes rien que sur ce forum ont jamais utilisé cette fonction bien particulière, ajouter une partition chiffrée via l'utilitaire disque. Visiblement, il n'y a pas tant de gens que ça qui l'ont utilisée alors que le bogue existait dans les versions beta. Sinon l'erreur aurait été découverte avant qu'il ne soit trop tard ! Mais bon.

Écrit par : Hebus 10 Oct 2017, 13:31

On va la faire courte... la programmation actuelle trouve ses limites, meme en oop, une forêts d’objets mutables dont il devient très difficile de controler et d’assurer l’etat, ses invariants en particulier.

Il y a un test de complexité cyclomatique qui evalue la testabilité du code, à 10 c bien, à 30 c’est pratiquement intestable.

J’ai fait tourner ces tests sur le code C de ma précédente équipe, on avait des fichiers de sources (20 ans de dev) qui avait une complexité entre 300 et 600... les patches sur les patches…… sur les patches

Écrit par : Macbox 10 Oct 2017, 13:34

C'est super d'avoir un vocabulaire compréhensible par les personnes qui ne font pas de programmation. Merci beaucoup pour cette vulgarisation.

Écrit par : sansnom 10 Oct 2017, 13:36

Encore une fois, je ne suis pas compétent... mais travailler et mettre à jour des pièces logicielles déjà existantes et produire par dessus des erreurs basiques aussi visibles devant un test tout aussi simple à mettre en œuvre !... Non, j'avoue ne pas comprendre, sauf à envisager de la légèreté, voir de l'arrogance, de la part de ces "techniciens" et de leur hiérarchie.
La méfiance est donc de mise.

Écrit par : Hebus 10 Oct 2017, 13:37

ça mesure grosso modo les embranchements... qui dit embranchement dit condition... trster revient à évaluer toute la combinatoire des conditions possibles.... factorielle donc

@sansnom

Je parle en general des tests de logiciel

Ici je ne crois pas à une complexité locale bien grande, par contre il n'y a pas que cela à tester … et va convaincre une hierarchie de mettre en face des besoins les ressources humaines adéquates ... c’est une épreuve

Écrit par : marc_os 10 Oct 2017, 13:38

J'ai bossé pendant plusieurs années il y a bien longtemps sur un sujet très particulier appelé DFT : Design For Testability.
Mais il s'agissait de la conception non pas de logiciels, mais de circuits intégrés qui eux aussi devenaient quasi "intestables" en production avec l'augmentation de leur complexité. D'où la nécessité de penser à la testabilité dès la phase de conception, soit pour ajouter des composants d'autotest, soit pour partitionner les circuits, etc.
Ce qui est marrant, c'est que les méthodes de test logiciels étaient source d'inspiration pour certains. Et j'ai comme l'impression que la boucle est bouclée et que peut être la conception de logiciels pourrait s'inspirer de ce qui se fait en DFT pour les circuits intégrés !

Intestable pour les CI ça voulait dire que les temps de tests nécessaires n’arrêtaient pas d'augmenter. Or chaque puce doit être testée individuellement et "le temps, c'est de l'argent" si bien que les coûts liés au tests devenaient prohibitifs.

Écrit par : Xdave 10 Oct 2017, 13:42

Heu non!
Le type qui a codé un tel bug est un con (et je pèse mes mots).

Je peux éventuellement comprendre -bien au contraire- que ce genre de bug passe au travers de tests automatisés ou humains.
ça voudrait dire que le type qui développe le test pense à l'avance que le codeur sera un con.

Cela étant dit, un dev con c'est pléthore.

Je m'en vais de ce pas mettre à jour ma liste de Risk Management… putain les boulets.

Écrit par : Hebus 10 Oct 2017, 13:44

La mode aujourd’hui c’est la programmation fonctionnelle, la croyance qu’avec un systeme basé sur des fonctions pure, qui ne dependents pas d’un contexte mutable, et des structures non mutables en immense majorité on va repousser les limites de la complexité gérable.

C’est certain que cela rend plus concis, facilite la programmation concurrente... mais la courbe d’apprentissage est dure et j’en bave, même si j’ai fait de la programmation Lisp et Mathematica...

Écrit par : vlady 10 Oct 2017, 14:04

Malheureusement la programmation fonctionnelle ne t'aidera pas à ne pas confondre 2 variables ou faire un copier/coller pourri. Surtout si les deux variables password et passwordHint sont du même type (NSString* par exemple)

Écrit par : sansnom 10 Oct 2017, 14:07

Je crois aussi qu'il est facile de taper sur ce pôvre bougre de programmeur.
Peut-on imaginer la complexité d'un OS : ce doit être l'enfer absolu !...

Par contre, on peut maintenant appréhender la crainte d'Apple à refondre... son Finder, qui n'a pas bougé une oreille depuis des lustres :
pièce angulaire de macOS, toucher à ce vieillard, c'est peut-être le risque de tout casser... big-bah-da-boum !...

Écrit par : Hebus 10 Oct 2017, 14:11

@Vlady

Je ne fait plus que du Swift moa Monsieur ... du passé faisont table rase, debout, debout .... ha merde je m’égarre

Plus sérieusement... comment se fait il que le code de ce genre de saisie n’est pas factorisé au point qu’il a été validé il y a une eternité et plus touché depuis...

Écrit par : downanotch 10 Oct 2017, 14:11

Sur le coup, le contrôle qualité sur APFS aurait plutôt fonctionner à merveille. A part cette stupide confusion entre deux variables, je n'ai pas eu vent d'autres bugs.

Écrit par : raoulito 10 Oct 2017, 14:12

attention, dès le début je critique (et pluessoie lionel) le contrôle QA et à la limite le système de beta test d'apple.
Un type fait une erreur de code sur quelques lignes au milieu de tout un tintouin, oui ca arrive, bien évidement.

comme le precise Hebus: meme le slogiciels de debugs peuvent être buggés. Seul le SkynexOs, conçu par Skynet en silicium et en electrons sera parfait

Écrit par : yponomeute 10 Oct 2017, 14:15

/etc/passwd est en plain text

Écrit par : vlady 10 Oct 2017, 14:18

Ici, il me semble, il s'agit d'une Application 'Disk Utility' qui est n'est pas spécialement complexe. Moi personnellement je préfère qu'Apple fait un bug dans le Finder au lieux de claquer un, aussi débile, dans l'opération de gestion des mots de passe que je crois infiniment plus prioritaire.

Écrit par : johnstone 10 Oct 2017, 14:34

C'est un fichier texte avec les mots de passe encodés (hash) depuis très très longtemps...

Écrit par : vlady 10 Oct 2017, 14:36

C'est une question de priorités. macOS pour eux est un mal nécessaire pour vendre des jolies machines hors de prix. Du coup, il y a juste quelques punis, ballottés à droite et à gauche qui continuent à trifouiller dans ce vieux merdier. Leur retrait du marché des serveurs a clairement indiqué que macOS se transformera d'un OS "le plus avancé du monde" en un gros firmware qui est tout juste bon pour faire tourner, au mieux, des machines de développeurs.

Swift c'est super mais je le laisse "mûrir" un peu (ABI stability, async/await notamment) et surtout, je trouve, que le support de Swift par Xcode n'est pas à la hauteur de tout ce tapage médiatique qu'Apple fait autour du langage. Pour l'instant tous (ou presque) les frameworks continuent à se faire en Objective-C chez Apple. Ne pas être un neuneu en Objective-C est important pour moi.

Écrit par : downanotch 10 Oct 2017, 14:48

Le problème ne se produit que via la commande "Add APFS" donc c'est sans doute un nouveau bloc de code. Par contre, il devrait y avoir un test au niveau de l'API pour générer une erreur si le mot de passe et l'indice reçus sont identique !

Écrit par : Xdave 10 Oct 2017, 15:53

D'ailleurs, au demeurant, savez-vous pourquoi -hormis le passage à APFS- pourquoi le Mr a tout re-codé de zéro au point de dupliquer une variable à la con?

oui ça m'intéresse au delà du bashing Apple coutumier sur ce site.

Non sans blague c'est codé en Swift ou c'est juste une méthode de repartir de zéro, je suis curieux…

Écrit par : marc_os 10 Oct 2017, 16:19

Oh le Lisp, que de vieux souvenirs !
Le côté concret de mon travail sur la DFT fut la réalisation d'un système expert en Common Lisp... J'ai adoré ce langage.

Écrit par : courbafond 10 Oct 2017, 16:20

J'ai été Analyste programmeur pendant de longues années, sur des progs. industriels.
Une erreur est vite arrivée dans des milliers de lignes de code, ce n'est pas du Basic...
Que celui qui n'a jamais fait d'erreur de programmation dans ce métier lui jette la première pierre.
Ce ne sera pas moi...

Écrit par : Xdave 10 Oct 2017, 16:24

Je n'avais pas vu ta réponse au moment de poster.
Cela étant, ton explication ne résout pas le problème (visiblement), vu que les deux ne sont pas identiques (théoriquement).

Un test logiciel devrait dire que les deux variables sont identiques (cf mon message plus haut) et faire un output "Gros boulet tu as 2 variables identiques dans ton code!", encore faut-il que le test soit AIA (Assez Intelligent Artificiellement) pour qu'il comprenne que ces 2 variables n'ont pas la même fonction.

Je vulgarise mais c'est l'idée.

D'ailleurs un "testeur" ne se serait pas rendu compte de l'idée parce qu'il aurait fait "Return OK" sans même lire (l'indice) tellement la chose est ENORME*.
Enfin je vois ça comme ça, sans dédouaner qui que ce soit, juste pour comprendre.


*Alan Edgar Poe et la lettre volée

Écrit par : Le Fée Vert 10 Oct 2017, 16:45

Dans ce cas, ça aurait été vachement pratique. Personellement autant ça ne m'amuse pas de créer certains tests, autant je ne pense pas qu'il y en aient qui soient inutiles. Par contre ça rallonge beaucoup/trop le build de certains projets.

Écrit par : DevilDave 10 Oct 2017, 17:10

Je ne comprends pas : est-ce que je dois reformater mon volume de démarrage et changer le mot de passe de ma session ?
Pour info :
- j’ai un MBPr13, son SSD avec 10.13 et mes données
- un DD externe (sauvegarde carbon copy cloner) en HFS+
- une Time Capsule, dans le mot de passe est le même que celui de ma session
- j’ai bien fait la mise à jour proposée par Apple
??

Écrit par : yponomeute 10 Oct 2017, 17:11

Et ça fait très longtemps que les mots de passe encodés ne se trouvent plus dans /etc/passwd, /etc/passwd étant accessible en lecture par n'importe qui.

Écrit par : johnstone 10 Oct 2017, 17:26

Damn, tu as raison! J'aurais du dire "il y a très très longtemps". Même le fichier /etc/shadow est maintenant obsolète. Je me sens vieux, vieux, vieux...

Écrit par : yponomeute 10 Oct 2017, 17:42

J'ai connu l'époque des mots de passe dans /etc/passwd

Écrit par : castor74 10 Oct 2017, 18:45

Heu... je pose une question de béotien, mais lorsqu'on sort une nouvelle version d'un OS, n'y a-t-il pas déjà toute une partie qui est écrite et que l'on ne touche pas? Ce genre de connerie ne devrait pas arriver, dans ce cas?

Écrit par : Macbox 10 Oct 2017, 18:48

L'erreur de programmation n'est pas vraiment condamnable. Car, en effet, qui n'a jamais fait de connerie(s) dans son boulot, avec des conséquences faibles ou catastrophiques, selon les conditions.

Ce qui est critiquable et inadmissible, c'est le fait que cette boulette ai pu arriver dans une version finale. Car Apple n'est pas une petit boîte de développement avec peu de moyens humains et techniques. Elle a largement de quoi se payer les conditions pour éviter ce type de conneries.Et si les coups de gueules sont nombreux, c'est aussi un retour de bâton face à une entreprise prétentieuse qui n'arrête pas de sa vanter dans faire dans l'excellence. *

De plus, cette erreur concerne un aspect de sécurité et pas un petit bout de code qui soigne le visuel de l'interface ou qui concerne une fonction absolument anodine. Tout ce qui touche à la sécurité devrait donc être traité avec plus de sérieux et de moyens.

* "https://www.apple.com/befr/newsroom/2017/02/apple-park-opens-to-employees-in-april/"

Écrit par : Billjobs 10 Oct 2017, 21:51

Pas obligé de mettre a jour tout de suite tu peux passer de version en version au mois d´aout ainsi tu as les version finale de chaque OS ! 10.11.6 10.12.6 etc...

Écrit par : raoulito 10 Oct 2017, 21:59

+1 d'autant que toutes les app sont optimisées pour le nouvel OS..

Écrit par : chombier 10 Oct 2017, 22:05

Comme ça, par magie, toutes les apps deviennent optimisées, parce qu'un nouvel OS est sorti ?
Office Mac 2011, et hop, Office Mac 2016.

Écrit par : ungars 10 Oct 2017, 22:23

La mauvaise foi la plus crasse. A ce niveau, c'est de l'incompétence avérée, du je m'enfoutisme pur et dur ! N'importe quel test unitaire ferait apparaitre le bug.



Et les tests unitaires, c'est pour qui ? Il y a les codeurs purs d'un côté et les testeurs purs de l'autre ?

Écrit par : chombier 10 Oct 2017, 22:27

Il faudrait déjà que chaque "dev" sache vraiment ce que signifie le terme "test unitaire". Et c'est pas gagné...

Écrit par : MixUnix 10 Oct 2017, 23:44

Tu modifies une/plusieurs lignes de code dans un ensemble, tu rebootes, tu testes ./ rien à ajouter
Sinon, ça veut dire, pas de contrôle mis en place.
TRÈS grave.
TRÈS.

Écrit par : raoulito 10 Oct 2017, 23:50

oui, je reformule:
un an plus tard, la plupart des applications privilégiant un suivit des techniques et une chasse aux bug auront ete mises à jours.
adobe oui, autodesk ok, microsoft...

Écrit par : yponomeute 11 Oct 2017, 08:05

J'ai connu un "dev" (enfin pas longtemps, il est resté que 15 jours ) qui modifiait les tests unitaires pour qu'ils passent au vert au lieu de corriger le code.

Écrit par : amike 11 Oct 2017, 08:55

Lorsqu'un développement touche une donnée "critique" (ici, le mot de passe), je dirais que la personne même du développeur devient matière à soupçon. Sa parole ou ses certitudes ne valent autant qu'une promesse....

Les tests unitaires ou les revues de code ne sont pas suffisantes : un développeur qui vérifie le travail d'un autre développeur, c'est comme un trader qui vérifie les comptes d'un autre trader...

En réalité, il faut exercer un contrôle orthogonal : pas sur le fond (l'exactitude du code) mais la forme (les procédures ont-elles été respectées ?).

En tout état de cause, cette histoire est étonnante car elle ne se résume pas à un simple bogue mais à un (petit) accident industriel. Dans les cas de VAG ou Samsung, on sait qu'il s'agissait respectivement d'un menfoutisme et d'une pression de la haute direction sur les étages inférieurs. Ici, je crois qu'il s'agit plutôt d'un "flottement" de l'encadrement.

Écrit par : Le Fée Vert 11 Oct 2017, 09:46

C'est top! J'ai vu un développeur qui avait créé les tests en même temps qu'un nouveau module. La review de code a permis de voire que les tests n'étaient pas importés et donc pas exécutés. Il à donc dû corriger son code.

Écrit par : marc_os 11 Oct 2017, 11:23

À priori non. (Si tu as juste fait la mise à jour via High Sierra.)
Car vu ta description tu n'as semble-t-il pas dû ouvrir l'Utilitaire Disque pour lui demander explicitement d'ajouter une partition APFS cryptée. Or did you ?


Il a donc dû devenir un spécialiste en tests unitaires s'il savait les modifier !

Écrit par : SartMatt 11 Oct 2017, 12:34

Le mot de passe est saisi en clair par l'utilisateur. Donc forcément, il y a un moment où il est en clair dans la machine. Et c'est à ce moment que, par erreur, il est récupéré à la place de l'indice. Et comme ensuite l'indice n'est pas chiffré (il ne peut pas l'être, puisque justement, il doit pouvoir être affiché en clair à quelqu'un qui ne connait pas le mot de passe !), cette copie accidentelle du mot de passe n'est pas chiffrée.

Non, c'est comme si juste avant de hasher ton mot de passe pour le mettre dans le fichier de mot de passes il était copié par erreur dans un fichier en clair.

Non, c'est uniquement une erreur d'implémentation.

Il n'y a jamais eu par conception de stockage du mot de passe en clair. Il n'est même probablement pas stocké en version hashée ou chiffrée. En général, ce qu'on fait pour ce genre de système, c'est qu'on génère une clé de chiffrement aléatoire, qui va être utilisée pour chiffrer les données du disque, et on stocke quelque par au début du disque la clé de chiffrement, elle même chiffrée à partir du mot de passe. Comme ça, le mot de passe n'est stocké sous aucune forme. Quand le volume chiffré doit être déverrouillé, l'utilisateur saisi un mot de passe, la clé de chiffrement est déchiffrée avec ce mot de passe, puis le début du volume est déchiffré avec la clé obtenue. Si ce début déchiffré est valide, on considère que le mot de passe était bien le bon et on continue, sinon on considère qu'il était mauvais et on le redemande.

Ce qu'il s'est passé, c'est simplement qu'au moment de l'initialisation du chiffrement, le mot de passe en clair (forcément en clair à ce moment) a été recopié accidentellement à la place de l'indice et stocké là où l'indice est censé être stocké.

Ce qui m'étonne plus, c'est qu'il y ait une différence entre SSD et HDD à ce niveau... Peut-être une implémentation différente du chiffrement dans le cas des SSD, pour tenir compte des problématiques d'usure ?

Tiens, on a connu le même
J'avais un souci avec un truc qui marchait pas du tout chez moi, alors que tous les tests étaient en vert dans le Hudson. Je suis allé voir les fichiers de test unitaire... Les 3/4 des assert étaient commentés
Le pire, c'est que c'était un mec qui avait bien 20 ans d'expérience...

Pour la blague, le même mec avait dans ses classes Java une fonction getThis(). Je sais pas ce qui me choquait le plus : le fait qu'il fasse une fonction getThis qui les 3/4 du temps ne faisait que retourner this, où le fait que parfois elle retournait complètement autre chose

C'est surtout une boîte qui depuis quelques années consacre bien plus d'argent à la rémunération de ses actionnaires qu'au développement de ses produits.

Écrit par : downanotch 11 Oct 2017, 12:58

Y en a-t-il vraiment une ? Quand on dit que seul sont affectées les machines avec High Sierra et SSD, c'est peut-être simplement parce que les SSD sont convertis en APFS à l'installation alors que les HDD restent en HFS+...


Je ne pense pas que ce soit la raison… Développer par exemple 4 OS alors qu'il y a 2 ans il n'y en avait encore que deux, ça n'est pas une évolution facile à gérer, même avec tous les moyens financier du monde.

Écrit par : SartMatt 11 Oct 2017, 13:30

Bien vu, la page sur le support d'Apple ne précise en effet pas que c'est spécifique aux SSD.

Écrit par : raoulito 11 Oct 2017, 15:27

+1
les actionnaires va falloir arreter avec ca. C'est pas le nombre de gens et d'equipes sur un projet qui en font la reussite, cf microsoft..

Écrit par : DevilDave 11 Oct 2017, 15:41

Eh bien effectivement, merci pour ta réponse, j’ai fait une mise à jour classique. Je n’avais pas compris que le bug intervenait seulement en utilisant Utilitaire de Disque 😉

Écrit par : SartMatt 11 Oct 2017, 16:14

C'est vrai pour la R&D. Par contre pour le contrôle qualité, c'est quand même essentiellement une question de moyens mis en œuvre...

Écrit par : yponomeute 11 Oct 2017, 16:41

C'est une question de volonté de la part des dirigeants de la boite. Il fut une époque où il y avait un certain Steve à la tête de la société, et il n'acceptait aucune imperfection sur un produit.

Écrit par : raoulito 11 Oct 2017, 17:42

c'était différent: une erreur comme ca et tu étais "stevé" (ton responsable aussi ptt) dans les deux jours.
plus besoin de qa

Écrit par : Hebus 11 Oct 2017, 17:50

Y avait pas de gros bugs du temps de Steve ???

Je suis sur qu’en cherchant dans les archive de MB on doit trouver de belles perles...

Déjà la couche réseau dans un environnement hétérogène...

Écrit par : yponomeute 11 Oct 2017, 19:50

Il y avait forcément des bugs du temps de Steve, surtout quand on tenait mal son iPhone

Mais il y avait Steve aux commandes, et son obsession c'était de sortir le produit "parfait". Les directives qui viennent "d'en haut" ont quand même un impact sur toute la marche de l'entreprise et sur la manière dont travaillent les employés.

Écrit par : chombier 11 Oct 2017, 21:07

Et les actionnaires, du temps de Mister Jobs, ils avaient des actions, qui ne rapportaient rien, et aucun pouvoir sur Tim Cook.

Écrit par : lionelmacb 12 Oct 2017, 09:29

L'ennui est que seule la version 10.13 est disponible à l'installation. Ensuite faut mettre à jour…

Pas de module d'installation direct en version supérieure

Écrit par : Eagle Kiss 12 Oct 2017, 09:48

Il n'y a pas de version supérieure. Et j'imagine que la 10.13 proposée sur l'Apple store est depuis patchée d'origine.

Écrit par : lionelmacb 12 Oct 2017, 10:17

Justement pas
J'en viens et c'est bien la 10.13 qui est affichée.

Écrit par : raoulito 12 Oct 2017, 11:17

tiens c bizarre. on pouvait penser que le fait de devoir la telecharger à chaque fois c'etait pour mettre la denriere mouture ?

Écrit par : downanotch 12 Oct 2017, 11:18

Elle contient le correctif.

Écrit par : Eagle Kiss 12 Oct 2017, 11:21

C'est exactement ce que je dis !!!

Il n'y a pas de version supérieure. Et j'imagine que la 10.13 proposée sur l'Apple store est depuis patchée d'origine.

Écrit par : Macbox 12 Oct 2017, 12:27

Sur le store, sur la page de High Sierra, il est bien indiqué qu'il s'agit de la version mise à jour le 5 octobre. Date qui correspond à la sortie de la mise à jour supplémentaire de macOS High Sierra 10.13

Écrit par : yponomeute 12 Oct 2017, 19:17

Et voilà enfin le fin mot de l'histoire révélé


http://www.commitstrip.com/fr/2017/02/08/where-are-the-tests/

Écrit par : iAPX 14 Oct 2017, 02:27

C'est peu de le dire, et vu ce que j'ai vu sur iOS 11 comme quantité de bugs, et vu celle-ci qui est incroyablement simple et impactante sur la sécurité, il est évident qu'il est urgent d'attendre!