FF3 et update.url des extensions > amo obligatoire ?

[Goofy]

[déplacer le sujet si nécessaire - merci]

Je viens de regarder par curiosité gran paradiso 3.0a8, histoire de voir ce qu'il advient des extensions. Pas de problème : toutes celles qui sont incompatibles sont reconnues comme telles et désactivées.
Histoire de tester j'ai pris une extension banale (BabelZillaMenu) et j'en ai passé la maxversion à 3.0a8. Au redémarrage j'obtiens
"BabelZillaMenu will not be installed because it does not provide secure updates"
Ce qui me semble :
1. logique puisque l'adresse de l'update.rdf est sur BabelZilla et pas sur AMO. Si on décide de rendre plus sûr le système des mises à jour, cel ame semble une bonne idée, mais...

2. inquiétant, car si j'ai bien compris ( oui je sais, on peut avoir des doutes sur ce point, c'est bien pour cela que je pose la question), seules les extensions ayant un système d'update enregistré chez AMO vont pouvoir s'installer sur FF3.
Donc :
- je fais comment pour tester une extension qui n'est pas encore chez amo parce que je suis en phase de développement (j'avoue que je caricature vues mes capacités, mais enfin comment feront les vrais développeurs?, ou parce qu'elle est en phase de traduction chez BabelZilla (une étape habituelle avant de déclarer la traduction disponible)...
- qu'advient-il des nombreuses extensions sur EGO auxquelles de courageux contributeurs se sont efforcé d'adjoindre des fichiers update.rdf (ce que pour ma part j'ai lâchement refusé de faire) ?

J'aimerais que vous me répondiez :
- mais non, mon pauvre Goofy, tu n'as rien compris, tout se passera bien car...

Dans l'espoir d'une réponse consolatrice et rassurante, je vous prie d'agréer, bande de technogeeks, mes plus vifs remerciements anticipés et mes salutations les plus scaphandrières

- goofy

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[teoli2003]

En fait, il y a un exploit depuis mai qui permet d'injecter du code malveillant dans Firefox si on contrôle le DNS le plus proche de la cible. Ce n'est pas simple, sauf peut-être si la cible est sur un Wifi mal patché/sécurisé. C'est un problème de sécurité grave, mais pas critique puisque ce n'est pas trivial à exploiter.

Pour contrer cette attaque qui est un MiM (Man-in-the-middle), Firefox a implémenté l'obligation de mettre à jour les extensions par un lien sécurisé (https). Toute extension qui fait des mises à jour et qui n'utilise pas un lien sécurisé est désactivée.

Néanmoins, il existe une clef dans le about:config pour désactiver ce contrôle et il y a en développement une alternative d'authentification au https qui pourra être utilisée par les développeurs pour signer leurs extensions et éviter le besoin d'un lien https. Mais cette alternative n'est pour l'instant pas encore disponible.

A noter que, malgré tout, certaines extensions n'utilisent pas le système de Firefox pour les mises à jour et ont leur propre code: mal codée, elles peuvent avoir le même risque de Mim et Firefox ne peut le combler ainsi.

Message envoyé avec : Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; fr-CH; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[Goofy]

Merci pour ces précisions sur la nécessaire et peu contestable sécurité de la mise à jour.
Je ne suis cependant pas très rassuré sur l'ergonomie du système qui consisterait à aller changer une valeur dans le about:config ou une procédure en https à chaque fois qu'on veut tester des extensions (les versions soumises sur Babelzilla sont très souvent des pré-publications, le développeur ne publie sa version sur amo qu'après avoir récolté ses traductions en général)

Je ne sais pas s'il est réaliste d'ésperer une case à cocher/ décocher dans les options avancées de mises à jour..."Mettre à jour les extensions..."
"Seulement celles dont la mise à jour est sécurisée par AMO"

Si Pascal Chevrel passe par là...

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[Benoit]

En fait, une version de test de l'outil de sécurisation alternatif (appelé McCoy) qui consiste à signer numériquement les fichiers update.rdf, est déjà disponible. Si quelqu'un pouvait l'essayer et nous dire si ça fonctionne...

chBok est en train de traduire la documentation ici :
http://developer.mozilla.org/fr/docs/McCoy

[martin]

mais non, mon pauvre Goofy, tu n'as rien compris, tout se passera bien car un système a été prévu pour les extensions qui ne sont pas sur AMO .

J'ai testé çà hier, je t'explique ce que je compris, qu'on me corrige si je fais des erreurs .

Firefox 3 n'acceptera pas d'extensions sécurisées.
Une extension sécurisée est :
- une extension provenant de AMO.
- une extension dont le update.rdf (signalé dans le install.rdf) est situé sur - un serveur https. La mise à jour (le .xpi) ne s'installera que si il est également sur https.
- une extension signée, c'est le cas qui m'intéressait, applicable si on a pas de https.

Une extension signée :
- Son install.rdf contient un élément em:updateKey

- l'update.rdf pour les mises à jour contient un élément em:signature, et un élément em:updateHash (important, j'ai pas compris de suite qu'il était indispensable, il contient le sha1 du .xpi).
voir les précisions.


Tout çà semble pénible à mettre en oeuvre, mais mccoy vient à la rescousse, et le fait pout nous (sauf le em:updateHash, à faire soi-même !)

ps: ce post mériterai d'être dans la section " Développement d'applications Gecko", les développeurs vont tous y être confronté .

[martin]

Si quelqu'un pouvait l'essayer et nous dire si ça fonctionne...

voilà la marche à suivre :
On lance Mccoy, et on y crée une nouvelle clé.

La première démarche est de signer l'install.rdf de l'extension avec cette clé.
2 solutions:
- soit on le fait par mccoy, en lui indiquant le fichier install.rdf à modifier. Le résultat est un rdf pas très lisible humainement.
- soit on fait un clic droit sur la clé dans mccoy et choisit "Copy public key".
On insère alors soi-même un élément em:updateKey contenant cette clé public dans le install.rdf (au même niveau que le em:updateUrl). On peut couper cette clé sur plusieurs lignes, les blancs seront ignorés .

Par la suite, quand il y a une mise à jour, on signe de la même façon (et avec la même clé !) le nouveau install.rdf.
On fabrique son package (le .xpi).
On calcule le sha-1 du .xpi (sur Linux, sha1sum nomfichier.xpi )

Puis on fait un fichier update.rdf classique, dans lequel on rajoute un élément em:updateHash qui contient le sha-1 calculé, au même niveau que l'élément em:updateLink.
On signe alors ce fichier update.rdf via mccoy ("Sign").

Par la suite il ne faut pas modifier manuellement ce update.rdf, sinon il ne marchera pas ! (les signatures tiennent compte du contenu de celui-ci)

En espérant avoir été clair .

[calimo]

tout se passera bien car un système a été prévu

Cependant, il reste horriblement complexe, en particulier en cas de changement de traducteur (je parle pour Liberté d'extension là)

Pour ma part je n'ai toujours pas exactement compris comment ça fonctionne, mais je compte bien m'y repencher

Au final, je pense que oui, ça va effectivement rendre AMO obligatoire de fait

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firedragon Firefox/2.0.0.6 (Ubuntu-feisty)

[Goofy]

merci martin , tu es parfaitement clair dans ton exposé didactique, mais pour un goofy ordinaire c'est tout de même comme le dit calimo horriblement complexe...

... et dans le about.config ? je vois bien une clé
extensions.updated.url
...est-ce que c'est celle-là qu'il faut tripoter ?

Et lui donner quelle valeur dans ce cas ?

S'il suffisait d'agir sur cette clé, ça serait plus facile, un petit malin nous ferait vite fait une extension pour mettre sa valeur en bascule par un clic sur une icône (?)




Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[Benoit]

Cependant, il reste horriblement complexe, en particulier en cas de changement de traducteur (je parle pour Liberté d'extension là)

Je ne vois pas pourquoi ça poserait un problème si on utilise une clé "globale" (par opposition à une par traducteur) pour toutes les extensions qui sont sur e.g.o.

Idéalement il faudrait qu'elle soit juste connue des admins (ce qui reviendrait à avoir une sorte de sandbox avec les extensions pas encore signées), mais là je sais pas si ça va être pratique. En tout cas si on la donne à tout le monde ça reviendrait à n'ajouter aucune sécurité (tout en en donnant un faux sentiment), ça c'est sûr

[arno.]

En fait si j'ai bien compris, ils ont mis en place un système pour sécuriser la mise à jour des extensions, mais par contre, le problème reste entier lors de la première installation En attendant, l'installation de Firefox ne se fait pas par https, et est elle même vulnérable à une attaque de type man in the middle. Alors, pourquoi se focaliser uniquement sur la maj des extensions ?

Peut-être que que j'ai pas tout compris, et que y'a un truc que j'ai loupé, mais pour l'instant, ça me donne la drôle d'impresion d'avoir mis en place un truc hyper compliqué juste pour dire: voilà, on fait de la sécurité

[teoli2003]

En fait si j'ai bien compris, ils ont mis en place un système pour sécuriser la mise à jour des extensions, mais par contre, le problème reste entier lors de la première installation En attendant, l'installation de Firefox ne se fait pas par https, et est elle même vulnérable à une attaque de type man in the middle. Alors, pourquoi se focaliser uniquement sur la maj des extensions ?

La première installation résulte d'un acte volontaire ("Je veux installer Adblock"), rare, les mises à jour sont déclenchées par le site distant lorsqu'il répond à une demande "As-tu une mise à jour?", requête qui a lieu tous les x heures.

Compter sur le premier cas pour faire une attaque Man-in-the-middle, c'est à peu près comme jouer au loto. Compter sur le deuxième, c'est comme jouer au loto en connaissant 5 des 6 chiffres qui vont sortir.


Message envoyé avec : Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; fr-CH; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[martin]

Je ne vois pas pourquoi ça poserait un problème si on utilise une clé "globale" (par opposition à une par traducteur) pour toutes les extensions qui sont sur e.g.o.

oui, çà me parait une solution censée.
Le problème que je vois pour l'instant, c'est que mccoy ne permet d'exporter/importer une clé (à filer aux membres d'EGO par exemple). Donc une seule personne devrait signer toutes les extensions d'EGO.

C'est peut être une amélioration à demander pour la prochaine version de mccoy.

[edit]
je précise que j'ai essayé de créer une nouvelle clé portant le même nom qu'une précédente dans mccoy, c'est bien une clé différente qui est générée.[/edit]
[edit 2]
en fait les traducteur speuvent signer eux même l'extension, mais une seule personne peut signer les update.rdf.
[/edit]

[Goofy]

merci de ces efforts et tests sophistiqués...
J'ai essayé quant à moi la chose suivante :

dans about:config je remplace la chaîne d'origine de la clé extensions.updated.url par https//www.goofytest.com/update.rdf

dans mon extension je mets aussi n'importe quoi (j'adooore ), même différent du moment que c'est httpS

et ça marche.

[EDIT] en fait pas besoin de changer une clé du about:config, il suffit que l'adresse du fichier d'update soit en https (même si c'est une adresse bidon)

hihi


Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

[Benoit]

Le problème que je vois pour l'instant, c'est que mccoy ne permet d'exporter/importer une clé (à filer aux membres d'EGO par exemple). Donc une seule personne devrait signer toutes les extensions d'EGO.

Bon, finalement j'ai installé l'outil aussi

Il y a en fait un répertoire de profil (c'est une application XULRunner) qui contient plus que probablement les clés (dans un des fichiers .db j'imagine), donc il doit être possible de le dupliquer d'une machine à l'autre.

Même si, effectivement, la possibilité d'exporter la clé privée depuis le programme serait préférable.

[Goofy]

[ Si vous voulez juste pouvoir tester votre extension, il suffit d'ajouter un s au htttp qui donne l'adresse de votre update.rdf dans la ligne updateURL de l'install.rdf, même si cette adresse n'existe pas en fait ]

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7