Si c'est asymétrique, le "casser" de manière à ce que tout le monde puisse générer sa propre signature sans modif hard revient grossièrement à quelque chose d'aussi difficile que de casser du RSA, donc je doute qu'une telle attaque frontale soit si facile si c'est le cas. Après il existe peut-être des failles subtiles dans l'implémentation du bouzin, mais si c'est possible à péter ça le restera probablement par des voies complexes et difficiles dans tous les cas.
Si tu passes un appel d'urgence sans entrer le code pin, il est probable que tu ne t'authentifies pas sur le réseau (mais tu, du moins la carte sim s'identifie sûrement partiellement) et que donc le réseau va par définition n'autoriser que les appels d'urgence.
Vu les uses case ça à tout de même un sens que la partie appli des téléphone reconnaisse des numéros d'urgence potentiels, mais il faut mieux voir large.
En fait initialement je trouvais ça absurde en réaction à la description du pb supposé initial, très probablement erronée (Manque de bol, son application d'appel était développée par un européen et n'avait pas prévu les appels de numéros à 3 chiffres.)
Tout à fait d'accord, mais quand tu vois les plus en vue, Linus en premier, tenir à très peu de chose près des propos similaire à ma caricature, tu te dis qu'il n'y avait même pas la moindre chance pour que quelqu'un entreprenne cela, et que même si un cinglé l'avait quand même entrepris ça n'aurait pas abouti par refus de Linus et quelques autres (et sûrement des boites) qui auraient refusés pour ces raisons. Raisons qui ne sont autre que la liberté pour les développeurs de priver en pratique celle des autres, absolument contraire à l'éthique même du logiciel libre. (J'ai dis "en pratique" car ils se justifient en disant que les malheureux n'ont "cas" faire leur propre hard et que donc en théorie tout le monde reste libre, ce qui est au delà du ridicule 99,999% du temps vu le hard considéré et la cible grand public visée). Bref la culture "officielle" de licence de Linux est bien celle autorisant les DRM y compris et surtout dans des devices à destination du grand public. Ca me rend triste à chaque fois que je me souviens de cela.
Et les Linux Kernel Hacker les plus en vue vont nous expliquer avec tout leur sérieux que c'est VRAIMENT GÉNIAL que motorola ait le droit de faire ça, que c'est la VRAI LIBERTÉ, et que heureusement qu'il est hors de question de passer en GPLv3, et que rester en GPLv2 doit pour donner à motorola la LIBERTÉ de faire ça être privilégié idéologiquement, et que la FSF c'est une bande de communiste du mal qui mange des bébé (phoque en plus) :p
On sous-entend que les filles NE peuvent PAS coder. Or, moins de 30% des métiers du domaine de l'informatique sont directement liés à la production de code à proprement parlé (je vais poster la référence si je la trouve, il s'agit du livre d'Isabelle Collet édité par Harmattan en 2006 de mémoire).
Ça m'a bien fait rire... Tu as l'air horrifiée qu'"on sous-entend[e] que les filles NE peuvent PAS coder." Et dans la phrase suivante, tu sous-entends juste en gros : bon ben c'est pas si grave en fait qu'elles savent pas coder... elles peuvent faire autre chose.
Pour ma part, j'ai juste du mal à voir pourquoi les filles ne pourraient pas coder...
(Et il ne faut pas se leurrer, la contribution très technique est plus valorisée dans le libre que d'autre styles de contributions.)
Concernant le problème des coordonnées bancaires utilisées à postériori ; les derniers commentaires sur le blog de Schneier montrent que les protocoles bancaires sont maintenant probablement suffisamment évolués pour permettre ce genre de chose sans avoir besoin du numéro de CB (cf. "tokenization" commentaire de Ryan at July 5, 2010 7:32 PM en réponse à Curt Sampson at July 5, 2010 4:06 AM)
Ah oui, j'avais pas encore lu les commentaires du post de Schneier.
Marre d'avoir des idées aussi communes :p
(à y réfléchir, et vu que je suis convaincu que ce genre de choses peut être breveté dans certains pays voire l'est déjà, je me demande si on obtiendrait pas en peu de temps le contenu de la très grande majorité des brevets logiciels et autres saletés, réécris par 30 personnes indépendantes n'ayant jamais eu connaissance des dits brevet, rien qu'en postant des problèmes sur des blogs et en attendant d'avoir une analyse des solutions et de leurs caractéristiques dans les commentaires -- ce qui montre l'inadéquation entre leur faible valeur réelle et l'effet démesuré accordé à "l'inventeur" de par son monopole artificiel potentiellement mondial)
Je préfère moi aussi que les sites ne stocke pas mon numéro de CB, et ça ne me gène pas de le saisir à chaque fois car j'ai toujours ma carte sur moi et je ne passe pas mes journées à faire des achats.
Mais je constate que nombre de sites persistent à vouloir stocker les numéros de CB, et je me dis que faute de mieux ils devraient au moins les chiffrer par des clefs qui ne sont pas stockées sur le site. (certains le font peut-être déjà ?)
La clef est chez l'utilisateur. (une clef par utilisateur)
Si l'attaquant se maintient sur le site, il pourra peut-être récupérer quelques clefs, mais pas toutes.
L'idée est d'éviter une exploitation massive au cas où une DB remplie de numéro de CB est récupérée, et de la transformer en au pire une exploitation beaucoup plus partielle de la même base.
Je suis d'accord qu'il n'y a pas vraiment d'effet si l'attaquant cible à la base un utilisateur.
Je ne résous effectivement pas son problème de fond, mais son exemple m'a fait tilté et je pense que la sécu peut être améliorée dans le domaine précis du stockage des numéro de CB, justement en évitant la situation qu'il décrit.
Quand à la seule difficulté de retrouver le couple login/password, l'idée est justement que c'est toujours mieux de forcer un attaquant à faire en plus cela (et pour chaque utilisateur) que de se contenter de lui permettre d'exploiter immédiatement tous les numéro en clair s'il parvient à mettre la main sur la base (suite à l'obtention d'un accès ponctuel au site de commerce).
Les microcodes acceptés par la communauté Linux ne tournent pas dans le CPU. La situation serait certes encore meilleure si tous les coprocesseurs étaient complètement documentés et avec des toolchains libres, ainsi que des firmwares libres, mais la situation actuelle n'est guère différente de s'il y avait une ROM contenant les microcode au lieu que cela soit le CPU qui l'upload. (Mais ça reste quand même triste de savoir qu'on pourrait améliorer beaucoup de choses si les docs et toolchains étaient publique ; en ce moment je bosse sur un design hard et je me prend parfois à rêver à comment je pourrais l'améliorer si je pouvais modifier/réécrire un FW -- et malheureusement je ne peux pas...)
Attention la CeCILL est compatible (par transformation) mais != à la GNU GPL, même si elle reste proche de la GPLv2.
Après un parcours très rapide, j'ai noté par exemple :
- qu'un module externe semble être principalement défini dans la CeCILL par le fait qu'il tourne dans un espace d'adressage disjoint
- Le 12.3 me laisse songeur : "Tout Logiciel diffusé sous une version donnée du Contrat ne pourra faire l'objet d'une diffusion ultérieure que sous la même version du Contrat ou une version postérieure, sous réserve des dispositions de l'article 5.3.4."
Il y a aussi des manques par rapport à la GPLv3 sur la plupart des points que la GPLv3 adresse spécifiquement par rapport à la V2
Bref CeCILL ne doit pas être une licence à utiliser aveuglement en remplacement de la GNU GPL mais à réserver aux cas où elle est imposée ou bien si vous l'avez bien étudiée et que vous préférez ses termes à ceux de la GNU GPL.
L'intérêt est probablement simplement qu'un contrefacteur aura du mal à minimiser sa responsabilité en invoquant l'erreur humaine s'il vire les en-têtes donnant la licence ou s'il utilise autrement les fichiers en la violant.
IIRC, des composants d'Android (dont la libc) ont spécialement été écrits par Google pour justement permettre aux constructeurs de téléphone de faire leur tambouille bien propriétaire.
Peut-être qu'Android aurait eu moins de succès sans cela, ou peut-être que les systèmes seraient plus libre, je ne sais pas.
De son esprit critique ? (son commentaire étant à mon sens plus porté sur le jugement que sur une simple affaire de définition des mots -- et j'aurais tendance à dire qu'on a pas besoin d'un dico pour se définir une ligne de conduite morale)
[^] # Re: Interopérabilité
Posté par Guillaume Knispel . En réponse à la dépêche Open source technology center by Microsoft - interview of Tom Hanrahan. Évalué à 6.
[^] # Re: Apple ?
Posté par Guillaume Knispel . En réponse à la dépêche Motorola : une nouvelle étape dans l'ignominie ?. Évalué à 6.
[^] # Re: dans tout ça...
Posté par Guillaume Knispel . En réponse au journal Motorola: Une nouvelle étape dans l'ignominie ?. Évalué à 2.
Vu les uses case ça à tout de même un sens que la partie appli des téléphone reconnaisse des numéros d'urgence potentiels, mais il faut mieux voir large.
En fait initialement je trouvais ça absurde en réaction à la description du pb supposé initial, très probablement erronée (Manque de bol, son application d'appel était développée par un européen et n'avait pas prévu les appels de numéros à 3 chiffres.)
[^] # Re: ahahaha
Posté par Guillaume Knispel . En réponse au journal Motorola: Une nouvelle étape dans l'ignominie ?. Évalué à 1.
[^] # Re: dans tout ça...
Posté par Guillaume Knispel . En réponse au journal Motorola: Une nouvelle étape dans l'ignominie ?. Évalué à 2.
# ahahaha
Posté par Guillaume Knispel . En réponse au journal Motorola: Une nouvelle étape dans l'ignominie ?. Évalué à 5.
[^] # Re: Bravo
Posté par Guillaume Knispel . En réponse à la dépêche Les femmes et le logiciel libre : retours d'une conférence des RMLL. Évalué à 2.
[^] # Re: WTP inempaquetable
Posté par Guillaume Knispel . En réponse au journal Plugin Eclipse : Jean qui rit et Jean qui pleure?. Évalué à 2.
[^] # Re: Bravo
Posté par Guillaume Knispel . En réponse à la dépêche Les femmes et le logiciel libre : retours d'une conférence des RMLL. Évalué à 3.
Ça m'a bien fait rire... Tu as l'air horrifiée qu'"on sous-entend[e] que les filles NE peuvent PAS coder." Et dans la phrase suivante, tu sous-entends juste en gros : bon ben c'est pas si grave en fait qu'elles savent pas coder... elles peuvent faire autre chose.
Pour ma part, j'ai juste du mal à voir pourquoi les filles ne pourraient pas coder...
(Et il ne faut pas se leurrer, la contribution très technique est plus valorisée dans le libre que d'autre styles de contributions.)
[^] # Re: WTP inempaquetable
Posté par Guillaume Knispel . En réponse au journal Plugin Eclipse : Jean qui rit et Jean qui pleure?. Évalué à 5.
[^] # Re: c'est discuté sur le blog à Schneier
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 3.
[^] # Re: nourjal pense qu'il ne faut pas poster d'idée après minuit
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 2.
[^] # Re: c'est discuté sur le blog à Schneier
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 4.
Marre d'avoir des idées aussi communes :p
(à y réfléchir, et vu que je suis convaincu que ce genre de choses peut être breveté dans certains pays voire l'est déjà, je me demande si on obtiendrait pas en peu de temps le contenu de la très grande majorité des brevets logiciels et autres saletés, réécris par 30 personnes indépendantes n'ayant jamais eu connaissance des dits brevet, rien qu'en postant des problèmes sur des blogs et en attendant d'avoir une analyse des solutions et de leurs caractéristiques dans les commentaires -- ce qui montre l'inadéquation entre leur faible valeur réelle et l'effet démesuré accordé à "l'inventeur" de par son monopole artificiel potentiellement mondial)
[^] # Re: Bien, mais il y a mieux
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 1.
Mais je constate que nombre de sites persistent à vouloir stocker les numéros de CB, et je me dis que faute de mieux ils devraient au moins les chiffrer par des clefs qui ne sont pas stockées sur le site. (certains le font peut-être déjà ?)
[^] # Re: nourjal pense qu'il ne faut pas poster d'idée après minuit
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 3.
Si l'attaquant se maintient sur le site, il pourra peut-être récupérer quelques clefs, mais pas toutes.
[^] # Re: nourjal pense qu'il ne faut pas poster d'idée après minuit
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 4.
Je suis d'accord qu'il n'y a pas vraiment d'effet si l'attaquant cible à la base un utilisateur.
[^] # Re: nourjal pense qu'il ne faut pas poster d'idée après minuit
Posté par Guillaume Knispel . En réponse au journal Idée (c'est-à-dire invention pour les daissidor praiçez) pour le stockage de CB en commerce électronique. Évalué à 3.
Quand à la seule difficulté de retrouver le couple login/password, l'idée est justement que c'est toujours mieux de forcer un attaquant à faire en plus cela (et pour chaque utilisateur) que de se contenter de lui permettre d'exploiter immédiatement tous les numéro en clair s'il parvient à mettre la main sur la base (suite à l'obtention d'un accès ponctuel au site de commerce).
# graph atténuation en dB / barres affichées
Posté par Guillaume Knispel . En réponse au journal [HS] Probablement le plus gros foutage de gueule de l'année ? la lettre d'Apple. Évalué à 2.
http://www.20minutes.fr/article/583123/High-Tech-Antenne-de-(...)
[^] # Re: C'est pas mieux..
Posté par Guillaume Knispel . En réponse au journal Débat autour des pilotes graphiques à moitié libres.. Évalué à 8.
[^] # Re: le Coca
Posté par Guillaume Knispel . En réponse au sondage Quand j'ai chaud je préfère boire. Évalué à 3.
# attention CeCILL compatible mais != à la GNU GPL
Posté par Guillaume Knispel . En réponse au journal Licence de logiciel libre et droit français. Évalué à 5.
Après un parcours très rapide, j'ai noté par exemple :
- qu'un module externe semble être principalement défini dans la CeCILL par le fait qu'il tourne dans un espace d'adressage disjoint
- Le 12.3 me laisse songeur : "Tout Logiciel diffusé sous une version donnée du Contrat ne pourra faire l'objet d'une diffusion ultérieure que sous la même version du Contrat ou une version postérieure, sous réserve des dispositions de l'article 5.3.4."
Il y a aussi des manques par rapport à la GPLv3 sur la plupart des points que la GPLv3 adresse spécifiquement par rapport à la V2
Bref CeCILL ne doit pas être une licence à utiliser aveuglement en remplacement de la GNU GPL mais à réserver aux cas où elle est imposée ou bien si vous l'avez bien étudiée et que vous préférez ses termes à ceux de la GNU GPL.
[^] # Re: Utilité réelle de ces "versions courtes"?
Posté par Guillaume Knispel . En réponse au journal Licence de logiciel libre et droit français. Évalué à 3.
[^] # Re: j'ai du loupé un episode mais
Posté par Guillaume Knispel . En réponse au journal Pour utiliser Windows, utilisez Linux (bis). Évalué à 2.
[^] # Re: un système libre ?
Posté par Guillaume Knispel . En réponse au journal Mon téléphone est mort, vive mon (nouveau) téléphone. Évalué à 5.
Peut-être qu'Android aurait eu moins de succès sans cela, ou peut-être que les systèmes seraient plus libre, je ne sais pas.
[^] # Re: Délation
Posté par Guillaume Knispel . En réponse au journal Defective By Design, ou le business model des bugs volontaires.. Évalué à 3.