Boa Treize a écrit 3449 commentaires

> Penser qu'il existe pas de dieu, c'est simplement penser que rien ne prouve qu'il en existe.

Pas d'accord. Je pense que rien ne prouve qu'il en existe, et pour autant je n'exclue pas qu'il en existe.

Il me semble que c'est la différence entre l'athéisme et l'agnosticisme.

xterm a des barres de défilement, mais tu risque de pas les aimer. ;-)

Le rendu des polices est basé sur Freetype et il supporte donc les polices TrueType avec anti-aliasing (même si pour un terminal, je préfère utiliser une police bien hintée). Il est facile de basculer entre les tailles de police préréglées (shift+plus, shift+moins), moins agréable d'éditer cette liste (enfin bon, c'est rien qu'un fichier de conf). La taille de l'historique se règle en un coup de vi également, même si elle n'est pas vraiment illimitée rien n'empêche de mettre une "grosse" valeur.

Pour l'encodage et le clavier, c'est moins évident (j'ai moins pratiqué, surtout).

Et pour le reste, bah non, XTerm n'a pas. Mais on s'en fout, il est très bien comme ça. :-)

Je ne pense pas pouvoir citer mes sources. :-/

Disons que ces valeurs sont issues d'un site dont la visite s'impose à la plupart de mes concitoyens... ;-)

Pète un coup, t'es tout rouge !

La plupart des commentateurs s'accorde à dire qu'il aurait certainement eu beaucoup moins, en gros il aurait été jugé pour un équivalent de "meurtre passionnel" plutôt que "meurtre avec préméditation". De l'ordre de 5 à 10 ans. (Un peu comme Bertrand Cantat, bien que les systèmes judiciaires soient très différents.)

Par ailleurs c'est très courant que le système judiciaire passe des deals avec les accusés, ce qui donne des résultats parfois surprenants ou décevants. Cette flexibilité a bien sûr des avantages (la vérité mieux connue, plusse de complices en taule, une sentence plus équitable que ce que le "système" impose) et des inconvénients (sentences ridicules, méchants qui "échappent" à ce qu'ils méritent, favoritisme). Mais faisant partie du système, ce genre de pratique est également probablement mieux encadré que s'il se faisait à la marge.

Ceci dit, VMS n'est pas encore mort. :-)

M'en fous, c'est le meilleur émulateur de terminal. Quand tu te connectes à une machine qui s'attend à avoir une vraie VT510 en face, tu es content d'avoir XTerm.

Ça dépend de la taille de l'accumulateur...

Est-ce bien constructif de s'emporter avec autant violence pour si peu ?

Ton câble USB (tout comme ton câble Ethernet) il est blindé... ton fil électrique, il émet tout ton traffic réseau dans la gueule de tes voisins...

Non : je pense que même OpenJDK6 de Juin 2008 n'aurait pas permis de télédéclarer ses impôts en France : ils exigent une machine Java CERTIFIEE par Sun.

Je crois pas non. Ils exigent une machine Java qu'ils ont pu tester, mais par exemple sous Mac, ça doit passer avec l'implémentation d'Apple.

Parts de marché pour info :

- 87 % Sun
- 10 % Microsoft (Java 1.1)
- 3 % Apple
- 0,07 % Blackdown
- 0,07 % IBM
- 0,004 % autres

S'il a fait ça, c'est globalement pour respecter ses engagements européens (c'est bon, on a une entreprise de train prête à entrer en concurrence avec les autres, elle est saine elle va bien).

(Je ne dis pas que c'est un bien.)

Pour info, c'est la même situation en Angleterre : séparation des compagnies qui possèdent les trains et vendent des billets des compagnies qui possèdent les rails et les louent aux autres.

(Par contre c'est un monstrueux bordel qui marche pas, en Angleterre, tu n'es sûr que d'une chose, c'est d'arriver en retard. Mais c'est un autre débat.)

> Mais la gestion des certificats clients au niveau des navigateurs n'est pas facile à gérer.

En quoi l'applet change quoi que ce soit ? De ce que j'en ai vu (de loin et dans Firefox), le certificat est intégré au gestionnaire de certificats de Firefox, et c'est Firefox qui demande le mot de passe, non ?

Il n'y a aucun standard à ce sujet, chaque navigateur a sa propre manière de faire, extrêmement diverse (fonction dans Firefox, API Windows pour IE, dans certains cas il faut aller lire le magasin de certificats sur le disque dur, etc.).

D'où nécessité d'implémentation spécifique et parfois de code natif s'exécutant hors du navigateur. D'où Java et ActiveX, et non pas simplement JavaScript.

Si tu es connecté en SSL, tu reçois les pages web (des formulaires tout ce qu'il y a de plus classique) sur une connexion sûre. Tu es également certain qu'ils n'ont pas été modifiés.

Vraiment ? :-) Il n'y a jamais eu de bug à ce propos dans les navigateurs, d'injection JavaScript et autres blagues du même genre ?

Après, peut-être que légalement l'un est valable et l'autre pas.

Je ne suis pas expert sur ce point, mais je sais que ça a été un élément très déterminant dans les choix effectués par la Direction Générale des Impôts (qui en connaît un rayon, elle).

Ne pas oublier également deux aspects extrêmement importants que nous avons du mal à bien visualiser en tant que geek linuxiens :

- L'ergonomie (application utilisée par des gens qui ne savent pas ce qu'est une session web, dans quel état (bien sécurisé ou non) ils sont, ni même avec quel utilisateurs ils sont loggués sur leur poste de travail ;-))

- Les responsabilités juridiques : installer du code chez les utilisateurs, c'est prendre la responsabilité des éventuelles failles de sécurité dans ce code (surtout un code installé chez des millions de gens), gérer les versions du produit, gérer les mises à jour, etc. Java (ou ActiveX) résolvent ce problème en exécutant le code de manière encadrée et en assurant de l'exécution systématique de code à jour.

> Pour la génération du certificat, il existe une fonction sous firefox et un composant active X pour IE qui permet de faire générer une clef au client et de la faire ensuite signer par le serveur.

Je crois que c'est ce que font les impôts. Je ne crois pas qu'ils ont ta clé privée, le couple clé privée / clé publique a donc été créé sur ton poste, puis ta clé publique a été signée par eux, ce qui forme ton certificat, qu'ils te remettent à la fin de la procédure.

Techniquement le certificat n'a rien d'exceptionnel, il peut être utilisé par toute entité qui reconnaît la Direction Générale des Impôts comme une autorité de certification et qui sait interpréter le CN de ce certificat (rien de bien difficile).

À l'inverse la Direction Générale des Impôts peut utiliser tout certificat signé par une autorité reconnue, elle a choisi de ne pas le faire dans le cadre des impôts des particuliers (encore que... faudrait tester un certificat généré par une autorité tierce avec un CN "qui va bien"... si ça se trouve ça passe), mais elle le fait dans le cadre des impôts des professionnels.

Je ne sais plus comment se passe la délivrance du certificat précisément, en tout cas derrière la façade commune c'est deux applications bien différentes qui se chargent d'une part de la génération / distribution, et d'autre part de la saisie de l'impôt. Ce serait peut-être plus clair (et plus sûr ?) si les deux étapes étaient clairement séparées, mais ça se ferait au coût de la convivialité de l'opération, critère manifestement important aux yeux du ministère.

Le PDF est bien généré côté client, mais je ne crois pas que ce soit pour un quelconque critère de sécurité : c'est soit pour économiser de la bande passante, soit parce que quand cette partie a été développée (aux environs de 2004 je crois) il n'y avait pas de bonne techno stable de génération PDF côté serveur, soit enfin pour économiser du CPU et de la RAM côté serveur.

Ils pourraient peut-être se contenter d'afficher du PDF pour les parties critiques, mais ce serait beaucoup moins convivial voire très confus (cas des PDF qui s'affichent systématiquement hors du navigateur) ; en termes d'ergonomie c'est beaucoup plus propre d'intégrer une applet au sein du site qui a exactement la même apparence que le reste du HTML. Par contre pour ces sections critiques, une applet est bien utile, car outre l'aspect juridique qui est vraiment important (en cas de bug, on peut sortir le code source, alors que sinon on peut juste dire "faute à pas de chance" et ça marche pas génial dans un tribunal), elle diminue également les chances d'injection de HTML ou de JavaScript de provenance externe (les navigateurs ont eu pas mal de failles de sécurité à ces niveaux).

Pour ce qui est de la "mise en échec totale des avantages de la signature" il faudrait que tu t'expliques plus en détail, car je ne te comprends pas. Il me semble au contraire qu'on a là une utilisation correcte des certificats, mais je ne suis pas expert en la matière. Arguments bienvenus.

Enfin pour conclure, Java a bien été choisi sur des critères techniques (et également architecturaux et stratégiques) et non pas administrativo-bureaucrato-légaux-truc. Clairement la démarche a abouti à Java et n'est pas partie d'un a priori.

(Et au fait, il y a aussi une version ActiveX de secours pour ceux qui sont sur un poste Windows sans Java correct. La sélection est transparente lors de la phase de détection initiale.)

Il me semble que Dedibox tout autant qu'OVH ont cette fonctionnalité dans le cadre de toutes leurs offres.

Comme d'autres l'ont dit, SSL ne permet que d'assurer la confidentialité du flux HTTP entre ton navigateur et les serveurs des impôts.

Or, il faut aussi exécuter du code dans ton navigateur :

- Affichage de ce que tu as déclaré indépendamment du navigateur utilisé (le résumé de ta déclaration est affiché par une applet, et pas par le navigateur) (ce résumé t'engage, c'est le point le plus important juridiquement)

- Sélection du certificat à utiliser pour signer (il n'y a pas de standard pour afficher une telle liste, d'où code spécifique aux navigateurs)

- Signature de ce que tu as déclaré (exécuté sur ton navigateur, pas aux impôts) (bien sûr, très important)

- Affichage de l'accusé de réception des impôts et génération du PDF associé (généré par une applet) (cet accusé de réception engage les impôts, c'est l'autre point important juridiquement)

Avec bien sûr, chiffrements, signatures, vérifications et contre-vérifications aux endroits appropriés.

Tout cela, SSL ne le permet pas bien sûr. On pourrait imaginer utiliser du JavaScript, mais c'est pas assez standard, trop dynamique, pas assez performant, trop enfermé dans le navigateur... Reste donc Java (ou ActiveX).

Crois bien que les impôts se seraient passés de télécharger (et surtout programmer) un .so ;-)

Malheureusement l'accès aux certificats des navigateurs n'est absolument pas standardisée (voire impossible, dans le cas d'Opera je crois), d'où le développement de code spécifique à chaque plate-forme...

Et c'est quoi l'erreur obscure ? :-)

Firefox 3 n'est pas encore sorti. Faut quand même pas s'attendre à ce qu'il soit officiellement supporté. ;-)

Quelle architecture utilises-tu ? 32 bits ou 64 bits ? Le support n'est pas le même, ni chez Sun (qui d'après un commentaire ci-dessus ne fournit tout simplement pas de plugin 64 bits), ni aux impôts (un peu pareil pour le 64 bits).

Reste plus qu'à trouver un moyen d'avoir le son... :-)

C'est marrant que tu t'évertues à vouloir démontrer que Wesnoth est un jeu stratégique, comme si tu avais l'impression que la tactique était quelque chose de petit, méprisable et trop simple (ce qui est bien sûr faux).

Rigolade à part, X démarre vraiment plus vite que Firefox.

C'est ton environnement de travail (celui pré-réglé par ta distro, qui contient typiquement KDE ou GNOME plus quelques trucs annexes) qui met des plombes à se charger.

Si tu es frugal et qu'un xterm sans window manager te suffit, X peut démarrer très rapidement, plus que Firefox.

Je sais pas d'où le modérateur a sorti son info « les neuf premières pistes (Ghosts I) étaient disponibles gratuitement dans la limite de 100 000 téléchargements sur le site officiel » mais c'est très faux, puisqu'on peut encore les télécharger sans problème là maintenant.

(Et je n'ai vu aucun autre site parler d'une telle limite. Le site officiel s'est certes écroulé sous la charge lors du lancement, mais depuis tout baigne.)