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...

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.

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.

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.

À 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 !

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.

Ce message a été modifié par SartMatt - 11 Oct 2017, 12:31.

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.

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

+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..

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 😉

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...

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.

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

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...

Ce message a été modifié par Hebus - 11 Oct 2017, 17:52.

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.

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

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

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.

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

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

Elle contient le correctif.

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.

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

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

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!