après avoir eu un avis du support de centre des impôts comme quoi, il
fallait faire sa déclaration en étant utilisateur root (sic), j'ai
regardé un peu ce dont leur application avait besoin.
En fait, il faut que le répertoire $JAVA_HOME/jre/lib/ext ait les droit
d'écriture pour celui qui exécute l'appli "impôts" afin de pouvoir y
écrire teleir_cryptolib.jar
ls -l $JAVA_HOME/jre/lib/ext
total 1264
-rw-r--r-- 1 root root 8896 nov 19 01:37 dnsns.jar
-rw-r--r-- 1 root root 53248 nov 19 01:45 ldapsec.jar
-rw-r--r-- 1 root root 769335 déc 30 20:15 localedata.jar
-r--r--r-- 1 root root 111374 nov 19 01:28 sunjce_provider.jar
-rw-r--r-- 1 jmax reymond 327218 mar 26 12:52 teleir_cryptolib.jar
De plus, et c'est une hérésie, l'appli vient créer un répertoire
teleir/certificats sous le répertoire d'installation de mozilla et y
colle les certificats. Pour celui qui utilise mozilla, installé depuis
une distribution, les accès étant root, ça ne marche pas:
ls -l mozilla1.7b/teleir/certificats
total 16
-rw-r--r-- 1 jmax reymond 4770 mar 26 13:03 0163645212017
REYMOND JEAN MAX.p12
-rw-r--r-- 1 jmax reymond 5931 mar 26 13:03 teleir.db
voili, voilou, si ça peut aider quelques personnes.
--
Jean-Max Reymond
dernière éruption de l'Etna: http://jmreymond.free.fr/Etna2002
Pas seulement open source, mais aussi tant qu'à faire des outils certifiés...
On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié. D'ailleurs, elle ne vérifie pas non plus elle même réellement leur contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas vraiment que personne n'arrivera pas à trouver une faille, mais plutôt qu'il n'y a pas de trou béant. Et aucune protection ne peut très sérieusement prétendre qu'elle résistera à un attaquant avec un accès local, ça c'est quelquechose que n'ont pas de gène à dire les gens de la DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type de solution demandé ici, qui doit tourner sur tous les os sans que l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas de solution matérielle à acheter, et dont le développement doit coûter pas cher pour rentrer dans le budget.
Conclusion, la certification est un outils, pas une panacée, et si en terme de formalisation des exigences, la certification est nécessaire, à un niveau individuel, il n'y a pas de raison de se reposer particulièrement plus dessus que sur de bonne procédure de validation d'un outils bien écrit. Même si même dans ce cas, l'avis des experts et le formalisme peut quand même révéler des choses, par exemple la plupart des faiblesse découvertes récemment sur Openssl l'on été par des suites de tests standardisée, telle que celle du NISCC.
Erwan David wrote:
Pas seulement open source, mais aussi tant qu'à faire des outils
certifiés...
On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié.
D'ailleurs, elle ne vérifie pas non plus elle même réellement leur
contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le
rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas
vraiment que personne n'arrivera pas à trouver une faille, mais plutôt
qu'il n'y a pas de trou béant. Et aucune protection ne peut très
sérieusement prétendre qu'elle résistera à un attaquant avec un accès
local, ça c'est quelquechose que n'ont pas de gène à dire les gens de la
DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type
de solution demandé ici, qui doit tourner sur tous les os sans que
l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas
de solution matérielle à acheter, et dont le développement doit coûter
pas cher pour rentrer dans le budget.
Conclusion, la certification est un outils, pas une panacée, et si en
terme de formalisation des exigences, la certification est nécessaire, à
un niveau individuel, il n'y a pas de raison de se reposer
particulièrement plus dessus que sur de bonne procédure de validation
d'un outils bien écrit. Même si même dans ce cas, l'avis des experts et
le formalisme peut quand même révéler des choses, par exemple la plupart
des faiblesse découvertes récemment sur Openssl l'on été par des suites
de tests standardisée, telle que celle du NISCC.
Pas seulement open source, mais aussi tant qu'à faire des outils certifiés...
On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié. D'ailleurs, elle ne vérifie pas non plus elle même réellement leur contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas vraiment que personne n'arrivera pas à trouver une faille, mais plutôt qu'il n'y a pas de trou béant. Et aucune protection ne peut très sérieusement prétendre qu'elle résistera à un attaquant avec un accès local, ça c'est quelquechose que n'ont pas de gène à dire les gens de la DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type de solution demandé ici, qui doit tourner sur tous les os sans que l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas de solution matérielle à acheter, et dont le développement doit coûter pas cher pour rentrer dans le budget.
Conclusion, la certification est un outils, pas une panacée, et si en terme de formalisation des exigences, la certification est nécessaire, à un niveau individuel, il n'y a pas de raison de se reposer particulièrement plus dessus que sur de bonne procédure de validation d'un outils bien écrit. Même si même dans ce cas, l'avis des experts et le formalisme peut quand même révéler des choses, par exemple la plupart des faiblesse découvertes récemment sur Openssl l'on été par des suites de tests standardisée, telle que celle du NISCC.
Erwan David
Jean-Marc Desperrier écrivait :
Erwan David wrote:
Pas seulement open source, mais aussi tant qu'à faire des outils certifiés... On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié. D'ailleurs, elle ne vérifie pas non plus elle même réellement leur contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas vraiment que personne n'arrivera pas à trouver une faille, mais plutôt qu'il n'y a pas de trou béant. Et aucune protection ne peut très sérieusement prétendre qu'elle résistera à un attaquant avec un accès local, ça c'est quelquechose que n'ont pas de gène à dire les gens de la DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Tout à fait, ce sont en gé,néral des gens qui saventce qu'ils font. Et quand ils confient une évaluation à quelqu'un, c'est à quelqu'un de compétent.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type de solution demandé ici, qui doit tourner sur tous les os sans que l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas de solution matérielle à acheter, et dont le développement doit coûter pas cher pour rentrer dans le budget.
Pourquoi ? Tout dépend de ce qu'on certifie.
Conclusion, la certification est un outils, pas une panacée, et si en terme de formalisation des exigences, la certification est nécessaire, à un niveau individuel, il n'y a pas de raison de se reposer particulièrement plus dessus que sur de bonne procédure de validation d'un outils bien écrit. Même si même dans ce cas, l'avis des experts et le formalisme peut quand même révéler des choses, par exemple la plupart des faiblesse découvertes récemment sur Openssl l'on été par des suites de tests standardisée, telle que celle du NISCC.
Oui. La certification prouve au moins que le code a été regardé par des gens compétents.
Pas seulement open source, mais aussi tant qu'à faire des outils
certifiés...
On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié.
D'ailleurs, elle ne vérifie pas non plus elle même réellement leur
contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le
rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas
vraiment que personne n'arrivera pas à trouver une faille, mais plutôt
qu'il n'y a pas de trou béant. Et aucune protection ne peut très
sérieusement prétendre qu'elle résistera à un attaquant avec un accès
local, ça c'est quelquechose que n'ont pas de gène à dire les gens de
la DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Tout à fait, ce sont en gé,néral des gens qui saventce qu'ils
font. Et quand ils confient une évaluation à quelqu'un, c'est à
quelqu'un de compétent.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type
de solution demandé ici, qui doit tourner sur tous les os sans que
l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas
de solution matérielle à acheter, et dont le développement doit coûter
pas cher pour rentrer dans le budget.
Pourquoi ? Tout dépend de ce qu'on certifie.
Conclusion, la certification est un outils, pas une panacée, et si en
terme de formalisation des exigences, la certification est nécessaire,
à un niveau individuel, il n'y a pas de raison de se reposer
particulièrement plus dessus que sur de bonne procédure de validation
d'un outils bien écrit. Même si même dans ce cas, l'avis des experts
et le formalisme peut quand même révéler des choses, par exemple la
plupart des faiblesse découvertes récemment sur Openssl l'on été par
des suites de tests standardisée, telle que celle du NISCC.
Oui. La certification prouve au moins que le code a été regardé par
des gens compétents.
Pas seulement open source, mais aussi tant qu'à faire des outils certifiés... On paye une DCSSI, c'est pas pour ça ?
La DCSSI ne les écrit pas les outils certifié. D'ailleurs, elle ne vérifie pas non plus elle même réellement leur contenu, il y a un tiers accrédité qui remplit ce rôle et c'est sur le rapport de ce tiers qu'elle se base.
Sauf pour les niveaux réellement élevés, l'accréditation ne prouve pas vraiment que personne n'arrivera pas à trouver une faille, mais plutôt qu'il n'y a pas de trou béant. Et aucune protection ne peut très sérieusement prétendre qu'elle résistera à un attaquant avec un accès local, ça c'est quelquechose que n'ont pas de gène à dire les gens de la DCSSI tels que ceux que j'ai eu l'occasion de rencontrer.
Tout à fait, ce sont en gé,néral des gens qui saventce qu'ils font. Et quand ils confient une évaluation à quelqu'un, c'est à quelqu'un de compétent.
Et aussi on ne pourra jamais accréditer à un niveau très élevé le type de solution demandé ici, qui doit tourner sur tous les os sans que l'utilisateur n'ait quoi que ce soit de compliqué à faire, surtout pas de solution matérielle à acheter, et dont le développement doit coûter pas cher pour rentrer dans le budget.
Pourquoi ? Tout dépend de ce qu'on certifie.
Conclusion, la certification est un outils, pas une panacée, et si en terme de formalisation des exigences, la certification est nécessaire, à un niveau individuel, il n'y a pas de raison de se reposer particulièrement plus dessus que sur de bonne procédure de validation d'un outils bien écrit. Même si même dans ce cas, l'avis des experts et le formalisme peut quand même révéler des choses, par exemple la plupart des faiblesse découvertes récemment sur Openssl l'on été par des suites de tests standardisée, telle que celle du NISCC.
Oui. La certification prouve au moins que le code a été regardé par des gens compétents.
