Au final, on relèvera trois contraintes gênantes pour des utilisateurs de logiciels libres :
- l'applet et sa bibliothèque de chiffrement propriétaire ;
- la nécessité d'accepter une licence avec la société américaine Sun pour déclarer ses revenus en France (« Si vous disposez de Windows ou Linux avec un des navigateurs suivants Netscape 6 ou 7, Mozilla, Opera (version sans JVM) ou Galeon : cliquez ici » qui envoie sur java.sun.com) ;
- la nécessité d'accepter de faire confiance à une autre société américaine (trop célèbre :() Verisign qui fournit le certificat pour la télédéclaration. Il restait bien quelques difficultés (cf divers journaux ici-même), comme le problème des permissions sur le répertoire où doit se trouver la bibliothèque propriétaire de la Direction Générale des Impôts, ou des soucis pour ceux utilisant l'UTF8 dans les paramètres de régionalisation (« locales »), mais globalement le support s'est amélioré.
Ceci est d'autant plus intéressant qu'« à compter de 2005, une réduction d'impôt annuelle de 20 ¤ est instaurée pour les contribuables qui souscrivent leur déclaration de revenus 2004 par voie électronique et qui acquittent l'impôt sur le revenu par prélèvements mensuels, par prélèvement à la date limite de paiement ou par voie électronique. ».
Sur fr.comp.os.securite, une longue discussion a eu lieu sur la sécurité du système, sa complexité, sur la bibliothèque propriétaire de la DGI, sur des solutions alternatives, etc., etc.
Il n'existe pas à ma connaissance de plugin Java libre susceptible de permettre la télédéclaration, et la DGI ne dispose pas encore des moyens pour certifier elle-même son certificat (projet de signature électronique en cours).
Aller plus loin
- DLFP : « Le ministère des Finances utilisera les logiciels libres dans la gestion des impôts » (8 clics)
- APRIL : Analyse du projet gouvernemental ADELE (8 clics)
- Journal DLFP sur l'afflux trop important sur les serveurs de télédéclaration (4 clics)
- DLFP : « 500.000 déclarations de revenus en ligne ! » (2003) (5 clics)
- Longue discussion sur Usenet fr.comp.securite (5 clics)
- DLFP : « VeriSign attaque l'ICANN » (2 clics)
# support amélioré ???
Posté par TazForEver . Évalué à -9.
Là où la CAF ou les taxe d'habitation font du HTML simple et qui marche partout, pour la déclaration de revenus, et bien ça ne marche sans installer cette pourriture de Sun. Pis encore, même sous MacOSX (on m'a rapporté) ça ne passe pas. En gros, c'est une énorme daube en Java pour faire portable mais au final, faut un ouin ouin et la bordel de Sun. Ras le bol !
Je me souviens pas comment c'était l'année dernière, mais présenter un truc en Java Sun comme une innovation, une amélioration, c'est le monde à l'envers !
Quant à tout le fric que perd l'état français perd avec des sociétés américaines, c'est navrant. La réduction de 20E pourrait être bien supérieure je pense.
[^] # Re: support amélioré ???
Posté par Brice Carpentier . Évalué à 4.
[^] # Re: support amélioré ???
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
http://about.me/straumat
[^] # Re: support amélioré ???
Posté par domi . Évalué à 4.
Mais bien sûr !
Par exemple dans le domaine de la carte Vitale, que je connais bien, on utilise des certificats made in cororico :-)
[^] # Re: support amélioré ???
Posté par jcs (site web personnel) . Évalué à 6.
D'abord contrairement à ce qui est dit dans la dépèche, Verisign ne fournit pas le certificat pour la télédéclaration mais le certificat de signature de l'applet, ce qui n'est pas la même chose. Le certificat de télédéclaration est fournit par l'autorité de certification du Minéfi.
Alors bien sûr les certificats pour la carte Vitale ne sont pas exactement la même chose. Produire un certificat c'est simple mais ici ce qu'il faut c'est un certificat de signature de code reconnu nativement par les navigateurs web. Pour cet usage je ne crois pas qu'il existe une entreprise française (ou même européenne) qui fasse cela, c'est à dire qui possède une autorité racine autorisée à signer du code et présente nativement dans les navigateurs web.
[^] # Re: support amélioré ???
Posté par Christophe Lucas (site web personnel) . Évalué à 3.
A titre de curiosité, qui crée les certificats concernant la carte Sesam Vitale ?
[^] # Re: support amélioré ???
Posté par jcs (site web personnel) . Évalué à 7.
Tu ne peux pas comparer ce qui n'est pas comparable. Pour la télédéclaration tu as besoin de signer numériquement, c'est à dire faire tourner du code côté client. Pour cela il existe deux technologies qui tournent à peu près partout : javascript et java.
Pour ce qui est de Javascript, deux problèmes : existe-t-il une bibliothèque crypto en javascript ? Et surtout où en est le support du javascript signé dans les différents navigateurs, car il faut accéder au disque de l'utilisateur pour stocker son certificat par exemple ?
Oui, TéléIR est critiquable mais je choix de java n'est certainement pas le pire des choix qui a été fait.
[^] # Re: support amélioré ???
Posté par Nicolas Bernard (site web personnel) . Évalué à 2.
En même temps, vu comment on obtient le certificat, elle est belle la signature numérique...
[^] # Re: support amélioré ???
Posté par TazForEver . Évalué à 1.
[^] # Re: support amélioré ???
Posté par Gerbus . Évalué à 6.
Ce ne serait pas un faux débat ?
A partir du moment où un appareil est utilisé (mécanique, eléctrique, électronique), et encore plus lorsque du soft entre en action, il est impossible d'identifier de façon certaine la personne à l'origine d'une action.
Un interlocuteur humain n'est pas non plus la solution, puisqu'il en faudrait un qui connaisse personnellement et identifie de façon formelle l'ensemble des déclarants qui s'adressent à lui.
Que proposerais-tu comme solution ?
[^] # Re: support amélioré ???
Posté par alnicodon . Évalué à 4.
Je m'étais déjà émerveillé (ou plutôt inquiété) de l'insécurité des mots de passes Yahoo: ni https, ni rien d'autre, apparemment. Quand, en regardant le source des pages de login/mot de passe (http://edit.europe.yahoo.com/config/mail?.intl=fr(...) ), j'ai trouvé des tas de fonctions compliquées, genre, hex_chr, str2blks_MD5, MD5 etc...
et un gros commentaire, avec le lien vers tout ce qu'il faut:
/*
* A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
* Digest Algorithm, as defined in RFC 1321.
* Copyright (C) Paul Johnston 1999 - 2000.
* Updated by Greg Holt 2000 - 2001.
* See http://pajhome.org.uk/site/legal.html(...) for details.
*/
Sinon, pour le support des scripts signés, pas la moindre idée, désolé.
[^] # Re: support amélioré ???
Posté par ptitatou . Évalué à 3.
C'est le système que j'utilise pour tout les formulaires de login que je met en place, et c'est difficile de faire mieux.
[^] # Re: support amélioré ???
Posté par ruz revr . Évalué à 2.
[^] # Re: support amélioré ???
Posté par lom (site web personnel) . Évalué à 3.
[^] # Re: support amélioré ???
Posté par alnicodon . Évalué à 2.
Ben oui, mais tant qu'on a pas été voir les sources de leurs pages, on est pas au courant que, je cite:
D'accord, j'étais peut-être un peu trop "implicite" dans mon message. Mais l'implication est que l'utilisateur lambda mais parano, il voit pas de cadenas fermé comme on en voit sur une page HTTPS, et donc il n'est pas rassuré. L'avantage du système Yahoo est que pour la sécurité recherché (confidentialité du mot de passe, et rien d'autre), est la légèreté de ce hack pour le client comme pour le serveur.
Alexis
[^] # Re: support amélioré ???
Posté par Julien Wajsberg . Évalué à 1.
[^] # Re: support amélioré ???
Posté par let antibarbie = xp <- xp - 1 . Évalué à 0.
Et si on ne stocke qu'une empreinte de celui-ci (on pourrait l'imaginer au premier abord) on ne pourra la comparer qu'à une empreinte du coté client, donc au final, le mot de passe devient l'empreinte mémorisée... le problème est équivalent.
Néanmoins la seule possibilité de compromission, reste le piratage de la base de données du serveur.
[^] # Re: support amélioré ???
Posté par Julien Wajsberg . Évalué à 1.
Ça n'ajoute peut-être aucune sécurité au niveau de cette appli là, mais globalement, ça doit avoir du bon... non ? :)
[^] # Re: support amélioré ???
Posté par Éric (site web personnel) . Évalué à 5.
> télédéclaration tu as besoin de signer numériquement,
La force d'un système de sécurité c'est celle de son maillon le plus faible. Ici la "signature" ne sert strictement à rien. Vu que tout le monde obtient la clé pour signer grace à trois question, il n'y a *aucun* intérêt à avoir une clé complexe avec java et tout et tout plutot que de demander simplement les 3 questions lors des différentes étapes. La sécurité est exactement la même dans les deux cas (vu qu'on est sur ssl).
[^] # Re: support amélioré ???
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: support amélioré ???
Posté par jcs (site web personnel) . Évalué à 4.
Non, il ne faut pas confondre authentification et signature. La signature est plus forte que l'authentification car elle fournit aussi l'intégrité du message signé et la non-répudiation.
Ce que tu proposes là c'est simplement de l'authentification. De plus la signature est nécessaire pour des raisons légales.
[^] # Re: support amélioré ???
Posté par Éric (site web personnel) . Évalué à 4.
Oui, l'intégrité du message et sa sécurité étant assuré par SSL et le certificat du serveur Web, comme partout ailleurs. Ca suffit tout à fait techniquement. Là on a empilé des couches inutilement.
> De plus la signature est nécessaire pour des raisons légales.
Oui, mais la signature électronique est un concept mal défini. Ainsi le code secret d'une carte bleu est considéré comme signature électronique, je ne vois pas pourquoi la réponse à trois questions sensées être privées ne pourraient pas l'être aussi.
Bref, les raisons ne sont d'après moi pas techniques. Il faut juste faire un montage complexe pour "montrer" qu'on est sécuriser et qu'on a monté un truc super avancé techniquement, même si en réalité ça n'apporte rien de plus et c'est moins compatible.
[^] # Re: support amélioré ???
Posté par jcs (site web personnel) . Évalué à 1.
SSL assure l'intégrité du transport mais pas de la déclaration. Une fois l'échange terminé, rien n'assure que la déclaration ne sera pas modifiée sauf une signature.
Oui, mais la signature électronique est un concept mal défini.
Qu'appelles-tu mal défini
La signature électronique est définie en autre
là : http://www.legifrance.gouv.fr/texteconsolide/ARHCG.htm(...)
et là : http://www.legifrance.gouv.fr/WAspad/Visu?cid=3213762&indice=2&(...)
Ainsi le code secret d'une carte bleu est considéré comme signature électronique, je ne vois pas pourquoi la réponse à trois questions sensées être privées ne pourraient pas l'être aussi.
Je m'avance peut-être car je ne connais pas trop le méchanisme des cartes bancaires mais il est fort possible que tu fasses effectivement une signature électronique (au sens que tu appliques un algorithme de signature) quand tu paies avec une carte. Et dans ce cas le code PIN sert uniquement à autoriser la carte à utiliser la clé privée pour calculer la signature.
Les trois questions posées pour TéléIR permettent de s'identifier auprès de l'autorité de certification du Minéfi et de récupérer sa clé et son certificat (c'est un peu comme prouver à sa banque son identité pour obtenir une carte). La signature ne s'effectue qu'à la fin quand on te demande ton mot de passe, ce qui est l'équivalent de taper son code PIN pour une carte à puce.
[^] # Re: support amélioré ???
Posté par Moule Atarte (site web personnel) . Évalué à 6.
Faux
Et c'est là que, en fait, utiliser le bouzin en java (mais un bouzin en javascript aurait marché aussi) prend du sens (voir étape 3).
1- tu te connecte en SSL à la DGI, la signature du certificat de la dgi par Verisign (ou Thawte ou laposte) te garantie que tu parle bien à la DGI et à personne d'autre.
2- tu réponds à 3 questions triviales dont toi et la DGI sont (normalement) les seuls dépositaires des réponses correctes (<melvin>m'enfin rien n'empêche d'imaginer que pour un quidam qui n'a de revenu que son salaire, il soit possible à son employeur de faire les calculs pour connaitre les réponses</melvin>*). Cela permets à la machine de la DGI de savoir que tu es bien celui que tu prétends être.
3- Tes bonnes réponses te permettent non pas de retirer un certificats comme tu retire ta carte à la banque, mais de télécharger l'applet qui génèrera ton certificats sur TON disque, avec TON CPU, TA mémoire vive et TON /dev/random. Que cet applet soit en java ou que ce soit un code javascript n'est pas la question. LE point crucial est que c'est éxécuté en local.
4- Tu fait ta déclaration, tu la chiffre avec la clef publique de la DGI et tu signe le tout avec la clef privé du certificat que tu viens de générer (dans cet ordre) : seule la dgi peut lire le contenu transmis, et ta signature numérique apposé sur le tout garantie que c'est toi qui a généré le lot de données chiffrée transmises à la dgi contenant ta déclaration.
ouala ouala
*: le tag <melvin></melvin> est là parce que 42 ! (d'ailleurs le film sors bientôt).
[^] # Re: support amélioré ???
Posté par jcs (site web personnel) . Évalué à 4.
Ok, tu as raison, mea culpa. A trop vouloir raccourcir on finit par dire des trucs imprécis et limite faux.
Deux remarques cenpendant :
- connaitre le revenu d'une personne ne suffit pas, il faut aussi le n° de télédéclarant et le n° fiscal (quoique celui-là il est peut-être public)
- quitte à être précis, je crois que la cinétique des échanges entre le client et la PKI qui délivre les certificats est la suivante :
1 - Tu télécharges l'applet (qui installe la 1er fois un package crypto sur le disque local ; c'est super laid comme mécanisme et ça fout la merde sous Linux et les Windows bien configuré mais passons)
2 - Tu remplis les réponses aux questions (nom, n° fiscal...)
3 - Tu génères une clé privée en local (je n'ai pas insisté la-dessus parce que ça me semblait évident, mais c'est crucial tu as raison de le rappeler)
4 - tu envoies les réponses et la clé dans une requête (PKCS#10 ou équivalent)
5 - Si tout va bien, tu reçois un certificat (valable 3 ans) à ton nom et signé par le Minfi
6 - Le PKCS#12 contenant ton certificat, ta clé et les certificats des autorités du Minéfi, est sauvegardé sur ton disque dur
[^] # Re: support amélioré ???
Posté par Éric (site web personnel) . Évalué à 5.
> fois l'échange terminé, rien n'assure que la déclaration ne sera pas
> modifiée sauf une signature.
C'est vrai. Mais notes bien que dans le cas d'une déclaration papier peronne ne me certifie qu'il est impossible de rajouter un nombre dans les cases vides. Ca n'a étrangement jamais posé de problèmes à personne pour les impots.
Dans d'autres formulaires (type constat automobile) on a des systèmes papier pour s'assurer que personne ne rajoute rien (compte des cases cochées par exemple). Pour les impots on a toujours fait confiance à notre administration pour ne rien bidouiller. Je ne comprend pas que d'un coup ça puisse devenir un problème sur l'informatique alors qu'il y a même moins d'intermédiaires que le papier.
De plus même avec la signature, s'il me suffit de trois questions pour avoir le certificat de signature. La signature elle me certifit quoi de plus que la réponse aux trois questions ? n'importe qui qui pourra répondre aux trois questions pourra me regénérer une clé, envoyer une autre fiche d'impot qui passera par dessus l'ancienne. Ca me fait une belle jambe d'avoir une signature complexe du coup
[^] # Re: support amélioré ???
Posté par kesako . Évalué à 2.
surtout que bien des organismes demandent photocopie de avis d'impositions complets
Mon comité d'entreprise par ex veux une photo des 4 pages de mon avis d'imposition 2003 pour calculer mon quotien familial.
Ils en font quoi de ces copies? quiconque les aura en main peut faire une declaration d'impot a ma place...
[^] # Re: support amélioré ???
Posté par gastounet . Évalué à 3.
Heureusement non, l'avis d'imposition ne contient pas le numéro de télédéclarant.
[^] # Re: support amélioré ???
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Avec l'informatique, on peut cocher ou pré-remplir toutes les cases que l'on veut sur toutes les déclarations que l'on veut, avec une requête sur une base de données. On peut aussi envisager d'intercepter ou d'écouter toutes les communications (surtout si on oblige à passer par des intermédiaires donnés). Avec le papier, on peut localement modifier quelques déclarations une par une, ou globalement modifier toutes les déclarations une par une... Et on ne peut pas intercepter globalement tout le courrier.
Un peu comme le fait de recevoir 3 à 4000 pourriels/mois (cf http://oumph.free.fr/textes/pourriel.html(...) ) alors que ma boîte aux lettres papier en reçoit une dizaine environ/semaine.
Idem sur le vote électronique par exemple. Les problèmes de sécurité sont démultipliés par l'informatique.
Bref l'outil informatique offre de nouvelles possibilités (bonnes ou mauvaises), une rapidité incomparable, une capacité de traitement inégalée, etc., etc. Rien de bien nouveau pour les visiteurs de LinuxFr, mais il fallait bien quelqu'un pour le rappeler.
[^] # Re: support amélioré ???
Posté par bobo . Évalué à 1.
[^] # Bien de chez nous
Posté par bobert . Évalué à 10.
L'expression ne manque pas de sel...
# Retour vers le logiciel libre
Posté par Etienne Juliot (site web personnel) . Évalué à 6.
OK, c'est génial que de grandes structures se tournent vers le logiciel libre, mais c'est pour moi indispensable qu'elles le fassent en aidant en retour les développements de ces mêmes logiciels. Non pas forcément pour la beauté du geste ou pour se faire de la pub, mais aussi dans leur propre intérêt (genre, plutot que de créer sa propre verrue pour corriger un problème, autant envoyer un patch directement à l'auteur du logiciel).
J'ai toujours du mal à faire comprendre qu'on peut être rentable en participant au développement d'un logiciel ne nous appartenant pas.
S'il n'y a pas de retour de leur part, l'avantage qu'ils utilisent des logiciels libres est pour moi moindre.
[^] # Re: Retour vers le logiciel libre
Posté par Sebastien . Évalué à 2.
Pour info, la DGI utilise des serveurs GNU/LInux + JBoss pour la tele-declaration. Je crois qu'ils fonctionnent aussi quasiment uniquement sous Linux, sauf les postes clients (pour le moment) mais des migrations sont en cours vers open-office (c'est deja ca).
[^] # Re: Retour vers le logiciel libre
Posté par l_arpenteur_k . Évalué à 1.
[^] # Re: Retour vers le logiciel libre
Posté par melyadon . Évalué à 2.
La communauté des programmeurs du logiciel libre de gestion de contenus SPIP, en particulier utilisé par l'Etat français et par les Collectivités locales pour la totalité de leurs sites Internet, a décidé d'organiser avec notre aide des séjours de vacances pour les 13-15 ans et les 16-18 ans qui leur pemettent, dans une ambiance de loisirs, d'apprendre avec plaisir et de s'en donner à coeur joie en innovation pour les plus passionnés.
L'Etat et les propriétaires du logiciel avec qui nous travaillons ont émis le désir qu'un maximum de jeunes français de toutes catégories sociales et de toutes les régions de France puisse profiter de cette occasion pour accéder à une informatique utile et professionnelle.
http://asso.objectif-sciences.com/rubrique.php3?id_rubrique=21(...)
# et l'année prochaine, on fait la même mais en fiable...
Posté par Maclag . Évalué à 3.
* Votre certificat électronique est invalide, résiliez-le
* Impossible de résilier votre certificat
On arrête plus le progrès...
[^] # Re: et l'année prochaine, on fait la même mais en fiable...
Posté par Arnaud Vigoureux . Évalué à 2.
[^] # Re: et l'année prochaine, on fait la même mais en fiable...
Posté par gyom gyom . Évalué à 0.
Tout ce qui est dit au-dessus me parraît exact: Java est une usine à gaz et n'est pas libre. Mais c'est autre chose qui me trouble : comment est-ce possible que certains aient pu télédéclarer depuis linux alors que chez moi leur usine à butiner du CPU cherchait à stoquer le certificat dans c:\TéléIR\certificats ou un truc du genre... Et que l'applet bloquait là-dessus ?
Je leur ai écrit un mail pour gueuler parce qu'ils ne prenaient pas en compte les autres OS que M$, alors j'aimerais savoir si c'est moi qui suis une buse ou si d'autres ont eu le même problème.
Gyom
[^] # Re: et l'année prochaine, on fait la même mais en fiable...
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[^] # Re: et l'année prochaine, on fait la même mais en fiable...
Posté par gyom gyom . Évalué à 1.
1. Il me semble que pour se faire il faut installer une extension et j'l'ai pas fait.
2. IE existe en natif sous Mac OS...
[^] # Re: et l'année prochaine, on fait la même mais en fiable...
Posté par Yann Droneaud (site web personnel) . Évalué à 3.
Un petit changement de droit sur le répertoires des plugins et de Java (et c'est aussi pour cela que je ne voulais pas installer ce cheval de Troie sur mon système primaire).
Ensuite je lance Xnest (dans le chroot ou à l'extérieur, mais dans tout les cas il y a des soucis pour laisser l'accès au display).
Dans le chroot,
export DISPLAY=:X
lancement d'un window manager,
lancement de firefox.
Et là, ho miracle, cela marche.
Mais faut croire que le MINEFI vous dira que le plus simple c'est de lancer votre navigateur en 'root', comme cela plus de problème ...
A qui la faute: au navigateur, à Java, au Minefi, je ne sais pas, mais le constat c'est que par défaut, l'usage n'est pas prévu pour les systèmes multi utilisateurs (ce qui ne veux pas dire qu'il faille faire votre déclaration sur le premier poste en libre service que vous trouvez ;)
# Mauvaise pub pour GNU/Linux
Posté par j . Évalué à 3.
Il m'a fallu essayer pendant quinze jours avant de pouvoir enfin remplir la déclaration. Même le week-end, à 6h du matin ou la nuit, le site affichait inlassablement "vous êtes trop nombreux à vouloir télédéclarer, veuillez réessayer plus tard".
Evidemment si leur site ne tient pas (mais vraiment pas du tout) la charge, c'est sans doute dû à autre chose qu'au système d'exploitation. Mais le décideur (vous savez, celui qui fait de l'informatique en lisant 01 ou Décision Micro) qui apprend que le truc de télédéclaration tourne sous Linux risque immédiatement de penser que Linux n'est pas un choix très judicieux.
C'est bien de citer l'utilisation de Verisign et l'emploi de Java, mais à mon avis le plus génant pour les utilisateurs de logiciel libre c'est surtout le constat d'un échec.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par Éric (site web personnel) . Évalué à 3.
Surtout quand je vois que je m'étais pris un "trop nombreux" à 2 ou 3h du mat un mercredi .... fallait vraiment que ce soit mal dimensionné
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par j . Évalué à 5.
Car effectivement un tel message à 3h du mat ça n'est pas très crédible.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par melyadon . Évalué à 2.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par Éric (site web personnel) . Évalué à 3.
Leur message d'erreur est vraiment con là alors.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par Janfi . Évalué à -1.
Mais qu'est-ce que c'est que ce gros troll bien velu ?
Sans doute qu'un Win NT/2000/2003 ou autre Solaris (la GPL çai mal !) seraient préférables, j'ai bien compris ?
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par j . Évalué à 3.
Dis à un non-linuxien qui a tenté de remplir sa déclaratation en ligne "tiens tu sais quoi ? le site tourne sous Linux". Je suis prêt à parier n'importe quoi que sa réponse va être du type "ah bein ça marche pas terrible".
Sous un autre OS la situation aurait été la même, mais dans ce cas précis, c'est une *mauvaise* pub pour LInux.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par Christophe BAEGERT . Évalué à 1.
[^] # Re: Mauvaise pub pour GNU/Linux
Posté par kesako . Évalué à 2.
en plus, j'ai dû resilier mon vieux certificat et en reprendre un autre : pas de probleme.
bref je trouve que ca marche tres bien .
(p'tete parce que je suis sur paris , avec un adsl degroupé tres rapide)
# Mauvais support du codage unicode utf-8
Posté par Jean M. . Évalué à 10.
L'assistance par courriel de la dgi ... Il n'y plus de Gabonnais au numéro que vous avez demandé comme souvent avec l'administration.
En fait, en faisant quelques recherches et en insistant en changeant la conf...
Lancer un terminal ligne de commande. Si à la commande "env" le paramètre Lang donne LANG=fr_FR.utf8 , comme moi, vous avez tout faux.
Fermer le navigateur, Redéfinir la variable
LANG=fr_FR
export LANG
firefox &
Le navigateur est relancé à partir de la console et là, MIRACLE ça fonctionne, il est possible de signer sa déclaration.
En suite fermer le navigateur et remettre la variable LANG comme elle était avant.
Salutations,
[^] # Re: Mauvais support du codage unicode utf-8
Posté par Maclag . Évalué à 1.
Non seulement c'est une critique constructive (le support d'utf8 est à revoir) mais en plus il apporte 1 solution à un problème qui si ça se trouve est en cause dans mes déboires avec la télédéclaration!
Hop! Je pertinente!!
[^] # Re: Mauvais support du codage unicode utf-8
Posté par rictus (site web personnel) . Évalué à 3.
Déjà ça m'a "gavé" d'avoir à installer java juste pour ça... (oui, java ça pue, et là c'est un vrai troll..., pas seulement parce que c'est pas libre, mais parce que je trouve ça usine à gaz, extrémement lent, avec un installeur extrémement crade... même avec le package debian qui vous fait un .deb du .bin de l'installeur java)...
Ah oui déjà, le système teleir pourrait être un peu plus user-beta proof... c'est techniquement pas possible de signaler au télédéclarant qu'il n'a pas de JVM fonctionnelle sur son browser ? Parce qu'au départ, j'essayais bêtement d'obtenir mon certificat, il ne se passait rien, et je pensais que c'était peut-être dû au site qui était saturé...
Bon, j'ai ensuite réussi à installer java et à le faire fonctionner, j'ai lu les différentes astuces qui avaient été postées ici : donner les droits qui vont bien au répertoire qui accueille les applets java... les différents modules se sont téléchargés (mais super lentement, et sans barre de progression comme j'ai vu ultérieurement sous windows avec IE :(, et avec le process java qui bouffe 100% de cpu pendant 3 plombes ). J'ai positionné la variable LANG=fr_FR et réessayé d'obtenir mon certificat... j'ai validé l'exécution d'1 ou 2 applets java, ça s'est remis à mouliner à 100% pendant plusieurs minutes, et puis rien... pas la moindre erreur, on ne sait pas pourquoi ça a échoué...
Bon, allez, je sais qu'il y a des gars qui ont bossé dur sur le système, et on peut toujours discuter le choix des technologies retenues... Moi je regrette seulement que le système retenu me semble avoir été spécialement développé pour windows avec internet explorer et la JVM de crosoft sur lequel il fonctionne nickel... et marchotte (ou marchotte pas du tout) sur les autres plateformes...
Encore une fois, je veux bien reconnaitre que c'est peut-être moi qui m'y suis mal pris. Mais donc au final, ça m'a parru vraiment rebutant... car ça a échoué chaque fois sans le moindre message d'erreur. Sachant que faire sa déclaration de revenus n'est pas spécialement quelque chose de plaisant en soi... quand ça merdouille, ça exaspère encore plus...
[^] # Re: Mauvais support du codage unicode utf-8
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 1.
Sans doute un probleme de distribution ....
[^] # Re: Mauvais support du codage unicode utf-8
Posté par syntaxerror . Évalué à 9.
désolé.
[^] # Re: Mauvais support du codage unicode utf-8
Posté par oliv . Évalué à 3.
[^] # Re: Mauvais support du codage unicode utf-8
Posté par Laurent Vaills . Évalué à 1.
Merci beaucoup pour cette astuce. J'avais effectivement ce problème et je n'aurai amais pensé qu'une mauvaise locale pouvait aboutir à un échec de signature électronique !
Tu es mon sauveur ;-)
# Pas besoin de déclarer par voie électronique
Posté par JoeBar . Évalué à 1.
Hors des autres avantages que ça apporte, nul besoin de déclarer ses revenus par voie électronique pour bénéficier des 20 ¤ de réduction : il suffit pour celà de payer par voie électronique ou de choisir le prélèvement automatique.
[^] # Re: Pas besoin de déclarer par voie électronique
Posté par rictus (site web personnel) . Évalué à 6.
[^] # Re: Pas besoin de déclarer par voie électronique
Posté par JoeBar . Évalué à 2.
( http://www.impots.gouv.fr/portal/deploiement/p1/fichedescriptive_22(...) , page 3)
[^] # Re: Pas besoin de déclarer par voie électronique
Posté par Laurent Vaills . Évalué à 2.
Tout le monde ne peut pas se payer un ordinateur et un accès à un Internet. Je pense que cette réduction est discriminative.
De plus il est possible d'avoir un ordinateur, d'avoir choisi le prélèvement automatique mais pas d'avoir un accès Internet et donc dans ce cas pas de réduction.
Pareil pour ceux qui ont changé de situation familiale l'année dernière : ils ne peuvent pas télédéclarer et donc pas de réduction !
[^] # Re: Pas besoin de déclarer par voie électronique
Posté par Jean-Paul Chiron (site web personnel) . Évalué à 1.
S'il n'y avait pas cette carotte, la télédéclaratio n 'aurait pas ce succès. De plus, au vu des problèmes actuels, cela peut être considéré comme une indemnité pour le temps perdu ;)
# Technologie de la télédéclaration...
Posté par sylware . Évalué à 5.
- Installation d'un module de crypotgraphie JAVA dans un répertoire uniquement accessible avec les droits administrateur
- Problème du système de certificat dans un encodage système autres que fr_FR en ISO-8859-1(ou 15)
Bref, c'est pas joli joli... mais au moins ils vont dans la bonne direction! Ils ne faut surtout pas qu'ils s'arrêtent en chemin. Les technologies comme XForms avec signature électronique sont presques là et on pourra alors laisser tomber la dépendance JAVA qui est un standard qui n'est pas libre de droits (et puis c'est une technologie à la usine à gaz) pas comme ceux du W3C! Donc si vous vous sentez une âme citoyenne rendez-vous sur mozdev et contribuez à l'uniformisation des magasins de clefs, XForms et à sa signature électronique, et le support de la cryptographie sur HTTP (à ne pas confondre avec HTTPS). Et là on sera sûr que TOUT le monde pourra télédéclarer sans se prendre la tête. Ce que je trouve fantastique c'est "ce risque" pris pas une administration française. Ça signifie que les choses bougent, que du bon!# Déclaration en live-CD avec UBUNTU
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
C'est ce qu'a fait Olivier Cortes, l'un des développeurs d'Abuledu. C'est lui le O de Ryxeo, Ryx venant d'Éric Seigne.
Vous trouverez sa recette sur http://abul.org/article293.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.