flagos a écrit 3077 commentaires

Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire make test après la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.

C'est très bien alors.

– même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?

Alors il ne faut pas laisser au mainteneur croire que faire un make test est suffisant pour valider le binaire ! Si c'est trop compliqué à tester alors il ne faut pas laisser un mainteneur produire des patchs qu'il ne pourra pas qualifier ensuite. Si c'est ca, il reporte upstream, et c'est au projet de voir ce qu'il fait de ce patch.

La pour le coup, je rejoints complètement Zenitram. En matière de sécurité, on a une obligation de résultat. C'est donc très important que les projets et leurs packageurs communiquent bien.

On parle de sécurité.

Ca je suis entièrement avec toi. Il est inacceptable de publier une lib censé implémenter du SSL si ce n'est pas fait sérieusement. Si on a pas le budget ou les connaissances pour le faire sérieusement, on ne le fait pas. Et cela vaut pour Apple comme pour Debian.

Dans le cas d'Apple, le sentiment que ca me donne est qu'il n'y a derrière aucun coding-rule, aucune relecture, aucune vérification sérieuse, aucune analyse de code. Rien. Le pissage de code et c'est envoyé cash à l'utilisateur. La merde est arrivée alors que c'est le flow normal de travail et que rien ne pouvait la filtrer. Ca n'est pas correct, c'est de la responsabilité d'Apple, car comme tu dis, "On parle de sécurité".

Dans le cas de Debian, ce qui n'est pas normal, c'est que le mainteneur est intervenu hors workflow du projet. A mon sens, une distrib n'a pas a faire des patchs à chaud sur ce genre de libs. Mais je suppose (du moins j'espère !) qu'un tel flow existe au sein du projet, même si c'est fait par des bénévoles ! Après peut-être faudrait il que les projets fournissent une suite de tests pour que les mainteneurs puissent vérifier que rien n'a rien régressé au moment du packaging ?

Utilisation du goto, mauvaise indentation, manque de tests, non initialisation de la variable d'erreur, non utilisation des accolades.

Beaucoup de petites erreurs cumulées. Chacun est sensible différemment a ces erreurs. Au final, grosse conséquence puisque le code est une passoire.

Justement non. Et c'est ce qui me choque. Je suis pas expert mais rien que des bonnes pratiques de base aurait du détecter ce souci. Pratiques que l'on applique par ailleurs sur du code beaucoup moins sensible.

Donc oui, je réitère, cette faille est révélatrice: ce n'est pas qu'un problème d'étourderie, c'est un manque de méthode.

Ouai enfin ils vont quand même pas dépenser de l'argent dont on sait pertinemment qu'il n'y aura pas de retour économique, juste parce que çà fait plaisir a Zenitram qui a décrété que c'était l'avenir. C'est un peu court comme argument.

Suggestions/pubs qui ne seront plus faites une fois que les 9 tuiles seront remplies, autrement dit, une fois que l'utilisateur aura visité 9 sites différents.

Et puis un beau jour, on va se rendre compte que sur les 9 tuiles affichées, les 3 dernières ne servent a rien car une étude de haute volée a démontré que l'utilisateur en avait besoin que de 6.

Donc, comme on a en stock un bel algo de suggestion qui permet de savoir mieux que l'utilisateur ce qui lui convient, et ben hop, on remplace les 3 premieres tuiles par quelque chose qui exploitera mieux son temps de cerveau disponible.

Qydlc3QgdnJhaSBxdWUgYydlc3QgZXh0cmVtZW1lbnQgcHJhdGlxdWUuIE9uIHBvdXJyYWl0IGZh
aXJlIHBhcmVpbCBhdmVjIGxlcyBmaWNoaWVycyBkZSBjb25maWcgZGFucyAvZXRjLy4gUG91ciBn
YWduZXIgZGUgbGEgcGxhY2UgYmllbiBzdXIuIEF2ZWMgdW4gYWxnbyBkaWZm6XJlbnQgYSBjaGFx
dWUgZm9pcyBzaW5vbiBjJ2VzdCBwYXMgZHJvbGUuCg==

Il me semble qu'il y a une option avec journald pour retrouver des log en texte.

Mmmm OK.

En fait, la seule explication que je vois c'est que le fait de ne pas avoir cliqué sur refuser doit être équivalent à une acceptation. C'est fou.

Disons que leur implémentation est conforme à l'objectif:

Un mécanisme d’opposition doit être accessible simplement et doit pouvoir être utilisable sur tout types de terminaux (y compris les smartphones et tablettes).

Et c'est bien ca. Tu as une bien une petite popup qui te permet de t'opposer si tu ne souhaites pas être traqué.

Je pense que la petite phrase que tu cite ("Le script suivant permet de désactiver le traçage des outils de mesure d'audience tant que les utilisateurs n'ont pas donné leur consentement.") est juste la pour présenter le script mais qu'elle est mal formulée. Enfin c'est ce que j'en comprend.

Ca y est je l'ai, c'est plus subtil:

   if ( referrer_host != document.location.hostname ) { //si il vient d'un autre site
   //on désactive le tracking et on affiche la demande de consentement            
     window[disableStr] = true;
     window[disableStr] = true;
     window.onload = askConsent;
   } else { //sinon on lui dépose un cookie 
      document.cookie = 'hasConsent=true; '+ getCookieExpireDate() +' ; path=/'; 
   }

En clair, sur la première page, on affiche la banniere, pas de tracking. L'utilisateur ne peut que refuser ou continuer. S'il continue et clic ailleurs, cela vaut acceptation, on tombe dans le else, et cela active le cookie et le tracking.

Du coup, c'est quand même de l'opt-out (comme indiqué par le nom de la méthode dans les sources), mais tu n'es pas traqué sur le premier load. Ca te laisse une chance quoi.

Non. Ce qui me gêne, c'est ce que tu as marqué dans l'article:

Attention, il ne s'agit pas de prévoir un moyen pour que l'utilisateur puisse a posteriori refuser une futur utilisation, mais bien d'une demande d'autorisation préalable,

Alors que c'est bien une demande d'effacement du cookie a postériori, qui se doit par contre d’être facilement accessible. Popup dans l'implémentation de référence. Mais par défaut, le cookie reste intallé de base.

Et surtout en face d'une embassade. C'est toujours très mal pris car les conséquences politiques peuvent etre assez graves si ca dégénère.

Je peux pas recouper son email de remontée de bug avec l'analytique pour savoir quel navigateur il utilise …

Oui, ca c'est vraiment dommage.

Je peux pas voir qu'il visite la page du pricing 3 fois de suite et le croiser avec son abonnement actuel pour lui proposer une periode d'essai sur un plan supérieur …

Tant mieux. En tant que client, je déteste ces pratiques.

Je peux donc pas vérifier si il utilise seulement une partie des fonctionnalités et jamais certaines autres pour tenter de mieux cerner mes clients et améliorer mes offres ?

Si. Tant que ces données restent anonymes.

C'est pas ce que je lis:

// Le code HTML de la demande de consentement
// Vous pouvez modifier le contenu ainsi que le style
div.innerHTML =  '<div style="background-color:#ffffff">Ce site utilise Google Analytics.\
En continuant à naviguer, vous nous autorisez à déposer des cookies à des fins de \
mesure d\'audience.  Pour s\'opposer à ce dépôt vous pouvez cliquer  \
<a href="javascript:gaOptout()">ici</a>.</div>';    

Et apres tu as la fonction gaOptout, qui efface, apres coup, le fameux cookie.

Non. Regarde le code Javascript fourni, c'est bien de l'opt-out. Si l'utilisateur n'a pas refusé, il reste soumis au tracking.

Par contre, la bannière ne disparait qu'une fois qu'il a cliqué.

Quand on va sur le lien, on voit que ce que demande la CNIL est que le mécanisme d'opposition soit accessible. En gros, il faut juste d'afficher dans un coin de la page: "On vous traque avec Analytics, OK avec ca ?" Et proposer refuser ou continuer. Et si le gars continue par ailleurs sans s'interesser à la popup, il continue a être suivi.

Cela n'a rien avec une demande d'autorisation préalable où le 0 action de l'utilisateur n’entraîne aucun tracking.

T'inquiète pas, moi aussi j'ai installé mes premiers linux dans les années 90 en allant récupérer ca a base de disquettes (une red bat je crois) a la médiathèque du coin. Bon c'était pas vraiment mieux a la fin, en gros quand tu passais 3 jours dessus pour au final avoir juste un bureau, sans aucun son et un clavier qui marchait pas dans la bonne langue, ben voilà quoi. C'était pas mieux avant.

Mais ne t'inquiète donc pas, systemd, une fois qu'on a un template d'un fichier de service pour lancer ses propres scripts et qu'on a compris la ligne de commande, et ben on s'y fait. C'est pas si horrible quoi.

Bon moi par contre j'ai jamais réussi a me faire a GNOME shell, et ca me gonfle vraiment parce que du coup j'ai du quitter Arch que j'aimais bien.

Oui enfin tu arriveras pas a me faire pleurer sur cette horreur des auto tools.

Ya des fois où il faut arriver a se débarrasser de ce genre de choses complètement horrible.

Alors, ce que je te propose, plutôt que de réinstaller tout ton OS, c'est de créer un répertoire /etc/init.d/ (ou rc.d faut vraiment pas changer les habitudes, une fois tous les 20 ans c'est vraiment trop rapide) et dedans tu te met des scripts qui appellent systemctl avec les options qui vont bien.

Comme ca hop, tu ne vois plus tout ce qui fait l'intérêt de systemd (lancement dans un process maitrise a base de cgroups, reveil a chaud des process avec gestions des dépendances) et tu retrouves tes petits scripts a lancer a la mano si tu as envie.

Avec 18 ans d'expérience en Unix, ca devrait être faisable non ?

Tu peux expliquer la différence ?

et surtout, modulo le point principal, des gens qui font le taf, car c'est bien joli les touchages de nouilles par mail interposés, mais ça va ps faire des patches tout seul

C'est sur qu'il y aura un changement, mais la dessus debian n'est pas tout seul. Ces fameux patchs ont deja été faits pour d'autres distribs. Pour beaucoup d'entre eux, il s'agit de les valider.

En fait, la vraie bonne question a se poser, c'est plutôt qu'est ca va couter a Debian s'ils ne rejoignent pas systemd et s'ils s'amusent a mainteneur un système d'init tout seul ? Il est évident qu'a terme, le moindre coût est du cote de systemd.

Qu'ils donnent les specs précises de leur matos et la communauté se chargera de faire des drivers libres corrects !

Bon alors ca, c'est un mythe qui a vécu, va falloir arreter avec ca. Développer un driver décent, c'est un travail énorme. Pour bosser dans l’électronique, un driver c'est pas loin d'etre 25% des ressources alloués a un SoC. Les specs, je t'assure que ca fait pas des miracles. Bien souvent, les blocs fonctionnels sont mal spécifiés. Les drivers en interne sont en général codés avec un petit bout de code faisant office de driver léger pour le test fourni en tant que template.

Et quand bien même, les specs sont belles, a jour, compréhensibles et non buggés, ben derrière il faut lever une armée pour que ca suive. Regarde ATI par exemple, il a fallu un temps dingue pour avoir la gestion de l'énergie. D'ailleurs, au final, ca marche vraiment bien maintenant ?

La réalité, c'est que le seul moyen d'avoir un support linux libre décent, c'est de faire participer le constructeur. Répondre a des questions, fournir des specs pourquoi pas, fournir des bouts de code qui marche… mais surtout, contribuer directement sur le kernel.

Au final, on peut vraiment etre content que NVidia ait eu ce déclic après l'avoir refusé pendant des années. Globalement, j'ai l'impression que l'industrie de la micro elec dans son ensemble a de plus en plus envie de contribuer directement sur le kernel en mode upstream, et on ne peut que s'en féliciter. L'effet Android certainement.

Et dans le cas d'un jeu video en mode webgl, ca pourrait pas être utile ? Pour mesurer des distances entre objets dans un espace en 3D ?

https://code.google.com/p/android/issues/detail?id=32630

Apparement, le problème n'existe qu'en wifi. En mobile, ca a l'air d'aller.