"avalisation" de documents

Oups ! Mon post précédent a été écrit sans voir le message de
Patrick... Il est 22h30, chez moi, je suis fatigué. :-s

Bon, toujours est-il que lui non plus ne voit pas l'intérêt de
l'UUID. J'y verrais plus clair demain, j'espère.

Bonjour,

Effectivement, je crois que je vais laisser tomber l'idée
(séduisante) des UUID pour garder le principe du hash et de la
sauvegarde de chaque état du document.

Pour ce qui est de l'association du document et de son certificat, je
choisis de mettre tout ça dans une archive, elle-même signée. Et le
tout est sauvegardé dans deux fichiers au niveau serveur. Je ne pense
pas qu'effacer la signature de cette archive soit une attaque crédible
: si on gène effectivement le processus, on ne l'empêche pas et on
n'obtient pas de données vitales.

Enfin, je ne pense pas que je vais passer par un système de gestion de
version : ça me paraît trop lourd par rapport à l'objectif, somme
toute modeste, de notre logiciel. Par contre, pour que les workflows ne
gonflent pas démesurement, je prevois un système d'ancienneté : tout
les états de fichiers d'un workflow qui sont plus anciens que la date
indiquée sont effacés.

Cela ne gène pas le processus d'avalisation : c'est juste qu'on ne
garantit plus la chaîne que jusqu'à une certaine date.

Voilà les dernières nouvelles du front !

++

Pierre

Je n'étais peut-être pas assez précis : a quoi cela sert-il de
calculer le hash du document si vous ne sauvegardez pas ledit document,
et que vous ne pouvez plus vérifier ensuite la signature ?

Je proposais donc d'utiliser un nombre aléatoire (que j'appelle
pompeusement UUID ou GUID ;o) associé à mon fichier, une date et je
signe le tout. Ensuite je passe ma signature à mon chef qui va signer
à son tour, etc.

C'est peut-être un peu trivial mais c'était là mon idée...

Vincent

Bonjour,

Effectivement, je crois que je vais laisser tomber l'idée
(séduisante) des UUID pour garder le principe du hash et de la
sauvegarde de chaque état du document.

Pour ce qui est de l'association du document et de son certificat, je
choisis de mettre tout ça dans une archive, elle-même signée. Et le
tout est sauvegardé dans deux fichiers au niveau serveur. Je ne pense
pas qu'effacer la signature de cette archive soit une attaque crédible
: si on gène effectivement le processus, on ne l'empêche pas et on
n'obtient pas de données vitales.

Enfin, je ne pense pas que je vais passer par un système de gestion de
version : ça me paraît trop lourd par rapport à l'objectif, somme
toute modeste, de notre logiciel. Par contre, pour que les workflows ne
gonflent pas démesurement, je prevois un système d'ancienneté : tout
les états de fichiers d'un workflow qui sont plus anciens que la date
indiquée sont effacés.

Cela ne gène pas le processus d'avalisation : c'est juste qu'on ne
garantit plus la chaîne que jusqu'à une certaine date.

Voilà les dernières nouvelles du front !

++

Pierre

Et bien, oui, l'idée est bonne...

Je n'étais peut-être pas assez précis : a quoi cela sert-il de
calculer le hash du document si vous ne sauvegardez pas ledit document,
et que vous ne pouvez plus vérifier ensuite la signature ?

...mais je me propose justement de sauvegarder tous les états du
document.

++

Pierre

Bonjour.

Je réponds à Pierre Goupil <goupilpierre@gmail.com>

Et bien, oui, l'idée est bonne...

Je n'étais peut-être pas assez précis : a quoi cela sert-il de
calculer le hash du document si vous ne sauvegardez pas ledit
document, et que vous ne pouvez plus vérifier ensuite la signature ?

...mais je me propose justement de sauvegarder tous les états du
document.

Dans ce cas, vous n'avez plus besoin de considérer que le document peut être
modifié après signature, et donc un système de signature classique suffit.

Mais cela vous met face à deux problèmes:

1) Enorme volume à stocker (du moins si vos documents et votre workflow sont
un peu consistants),

2) En cas de litige, énorme travail de dépouillement pour retrouver la
teneur de l'anomalie. En fait cette tâche sera probablement humainement
impossible ou sujette à erreurs, ce qui implique de la valider par un outil
d'analyse différentielle.

Ce qui réssuscite alors l'intérêt de ne conserver que des différentiels et
de traiter leur validation de manière externe au document.

Pour répondre aussi précisément à "godin", je ne proposais pas de renoncer à
conserver la trace des modifications. Je disais qu'il est possible de les
conserver sous une forme compacte dont la mise en oeuvre sera plus
laborieuse, dans la mesure où elle reste possible:
- l'existence notoire de cette possibilité et séparément l'identification
immédiate du "maillon faible" constituent une dissuasion efficace,
- si exceptionnellement ledit "maillon faible" conteste la faute en disant
que "c'est la faute à l'informatique", alors il sera justifié de procéder à
une reconstitution (exploitant seulement alors les différentiels).

Cette solution relève donc de l'optimisation, en évitant d'être
systématiquement procédurier mais en se réservant la possibilité de l'être
en cas de litige. Carotte et bâton, le début de la sagesse.

Comme disait l'ami Laspalès, "Y'en a qui vont essayer, ils auront des
problèmes", mais "c'est vous qui voyez".
:o)

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Tout d'abord, désolé de mon manque de réactivité ! Je n 'avais pas
vu qu'il y avait une deuxième page de messages... :s

Ensuite, et bien, oui, je vois l'idée ! Mais je te rassure, le
"dépouillement" sera fait par des moyens purement automatiques. Faut
pas déconner : je suis prêt à bosser deux semaines de plus p our que
mes utilisateurs soient dans le confort.

Pour ce qui est des différentiels, je suis en train de creuser
l'idée. Mais avec celle que j'ai et que je vais exposer ça me par aît
plus difficile.

Je compte mettre un système d'ancienneté des workflows : tous les
états plus anciens qu'une certaine valeur (1 semaine, 1 mois, 1 an,
...) sont effacés et passent à la trappe.

Mais si je fonctionne également par différentiels, ça coince ! Car
si j'efface un état, trop ancien, et que celui-ci est la base de
fichiers plus récents qui n'ont sauvegardé que leurs différe nces par
rapport à lui, 2 problèmes :

-premièrement, je n'ai pas a priori de moyen de savoir que j'ai
effacé un fichier qui était certes trop vieux, mais dont j'ai bes oin
pour reconstituer un workflow, qui lui est toujours d'actualité

-et donc deuxièmement, comment être sûr que les états q ue je
persiste à conserver, car n'étant pas trop vieux, peuvent êt re
reconstitués ?

C'est poser la question suivante : comment être sûr que je garde
toutes les différences, même obsolètes, d'un certain fichier que je
veux garder ?

Cela ne me paraît pas trivial.

Bon week-end à tous et encore merci pour cette gymnastique
intellectuelle ;-)


Pierre

Bonjour.

Je réponds à Pierre Goupil <goupilpierre@gmail.com>

Tout d'abord, désolé de mon manque de réactivité ! Je n'avais pas
vu qu'il y avait une deuxième page de messages... :s

Ensuite, et bien, oui, je vois l'idée ! Mais je te rassure, le
"dépouillement" sera fait par des moyens purement automatiques. Faut
pas déconner : je suis prêt à bosser deux semaines de plus pour que
mes utilisateurs soient dans le confort.

Pour ce qui est des différentiels, je suis en train de creuser
l'idée. Mais avec celle que j'ai et que je vais exposer ça me paraît
plus difficile.

Je compte mettre un système d'ancienneté des workflows : tous les
états plus anciens qu'une certaine valeur (1 semaine, 1 mois, 1 an,
...) sont effacés et passent à la trappe.

Mais si je fonctionne également par différentiels, ça coince ! Car
si j'efface un état, trop ancien, et que celui-ci est la base de
fichiers plus récents qui n'ont sauvegardé que leurs différences par
rapport à lui, 2 problèmes :

-premièrement, je n'ai pas a priori de moyen de savoir que j'ai
effacé un fichier qui était certes trop vieux, mais dont j'ai besoin
pour reconstituer un workflow, qui lui est toujours d'actualité

-et donc deuxièmement, comment être sûr que les états que je
persiste à conserver, car n'étant pas trop vieux, peuvent être
reconstitués ?

C'est poser la question suivante : comment être sûr que je garde
toutes les différences, même obsolètes, d'un certain fichier que je
veux garder ?

Cela ne me paraît pas trivial.

J'ignore si le respect des normes CMMI est au programme, mais il me paraît
très négatif de procéder ainsi:
- il y a effectivement un risque de perdre sans le savoir les origines d'un
workflow,
- cela admet tacitement qu'un document puisse "sédimenter" dans la chaîne.

Je propose une alternative qui me paraît élégante:

Il faudrait rajouter un mécanisme d'alerte temporelle par timeout (qui peut
être associé à la gestion des congés et des délégations de responsabilités).

Ainsi un document qui "traîne" sera détourné du flot normal pour partir dans
une ligne de traitement d'anomalies. A son issue, après diagnostic de la
cause, il sera soit réinjecté, soit clos par annulation, mais sans avoir à
se retrouver périmé dans un état imprévisible par simple timeout du début de
la chaîne.

Dans ces conditions, il devient possible de majorer le temps de traitement
prévu d'un document, et donc de gérer fiablement les états d'origine.

Il s'agit d'une simple adaptation des mécanismes fondamentaux de la
programmation temps-réel.

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

C'est poser la question suivante : comment être sûr que je garde
toutes les différences, même obsolètes, d'un certain fichier que je
veux garder ?
Pierre
La réalisation du projet "Avalisation" soulève un problème

capital. Les corrections apportées au texte principal par les membres
du workflow sont-elles de nature mineure ou majeure. En d'autres
termes, si les modifications ne changent pas les idées principales, on
peut concevoir qu'un même texte parcourt toutes les étapes en allant
du premier au dernier signataire. Par contre, on pourrait imaginer
qu'un signataire apporte une modification changeant l'esprit initial.
Dans ces conditions, on crée fatalement de nouveaux textes et le
nombre de nouveaux textes pourraient théoriquement être égal à la
factorielle du nombre des signataires du workflow, ce qui est
imaginable.
Si on se limite à des corrections mineures ou tout au plus si l'on
admet un nombre très restreint de corrections majeures, le logiciel
ClassicSys tel quel est tout indiqué pour cette application. Très
convivial, il garantit la confidentialité et l'intégrité du texte
chiffré avec en prime l'authentification formelle des correspondants
et l'impossibilité de renier une signature.

Emile

Bonjour.

Je réponds à Emile <emilemusyck@gmail.com>

C'est poser la question suivante : comment être sûr que je garde
toutes les différences, même obsolètes, d'un certain fichier que je
veux garder ?
Pierre
La réalisation du projet "Avalisation" soulève un problème

capital. Les corrections apportées au texte principal par les membres
du workflow sont-elles de nature mineure ou majeure. En d'autres
termes, si les modifications ne changent pas les idées principales, on
peut concevoir qu'un même texte parcourt toutes les étapes en allant
du premier au dernier signataire. Par contre, on pourrait imaginer
qu'un signataire apporte une modification changeant l'esprit initial.
Dans ces conditions, on crée fatalement de nouveaux textes et le
nombre de nouveaux textes pourraient théoriquement être égal à la
factorielle du nombre des signataires du workflow, ce qui est
imaginable.
Si on se limite à des corrections mineures ou tout au plus si l'on
admet un nombre très restreint de corrections majeures, le logiciel
ClassicSys tel quel est tout indiqué pour cette application. Très
convivial, il garantit la confidentialité et l'intégrité du texte
chiffré avec en prime l'authentification formelle des correspondants
et l'impossibilité de renier une signature.

C'est une réflexion pertinente, et qui remet en cause la logique actuelle,
qui était celle d'un développement + validation...
Si les fondements du document sont altérés, il me paraît nécessaire
d'interrompre cette logique pour rebrancher vers le début.
En fait idéalement il faudrait alors remettre en discussion le problème
initial, ce qui peut conduire à la création de nouveaux documents (solutions
alternatives, etc.)
Cela correspond à ce qui se passe dans le cycle de développement logiciel,
lorsqu'un test invalide une part du projet...

Mais je ne sais pas si tel était le problème initial ici... ie: je ne sais
pas si l'ambiance est propice à un tel brain storming.

S'il s'agit d'un cycle administratif avec validation hiérarchique, il est
probable qu'un veto va fonctionner comme une requête en annulation de la
signature précédente (avec charge pour le signataire de requérir lui-même de
son prédécesseur...). Je connais, j'ai subi ça un certain temps.

Bref le document peut reculer dans le workflow, avec annulation des
signatures, mais sans débranchement.

Je laisse Pierre Goupil trancher lui-même la question.

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Bonjour !

Tout d'abord, pour le time-out : oui, nous avions prévu un tel
système. Du moins, nous avions prévu un système d'alarme pour
rappeller à l'ordre un employé qui laisse traîner le workflow.

Pour ce qui est est de le coupler à un système qui fait sortir le
document de la chaîne afin de ne pas le laisser dans un état
inconsistent vis-à-vis du système d'ancienneté, l'idée me paraît
très bonne. Si un document traîne dans une boîte de réception
depuis 3 semaines, le fait d'effacer ses états vieux de plus d'un mois
a en effet moins de sens...

Ensuite, et pour ce qui est de savoir si les modifications sont
mineures ou majeures, je dois bien avouer que je ne sais pas trop
moi-même ! Mais une chose dont je suis sûr c'est que le principe est
que l'on donne son aval au suivant quoi qu'il se passe parce que l'on
peut garantir qu'il a bien obtenu le document de nous.

Le problème de savoir ce qu'il en fera lui-même me paraît
secondaire. Donc oui, le document peut reculer dans le workflow : quand
l'administrateur décide de parcourir la chaîne de signatures pour la
valider (à la demande d'un de ses utilisateurs).

Ensuite, au niveau utilisateur, tout ce qui peut être fait, c'est
d'annuler un workflow (ou appeller l'administrateur ! ;-). Et encore,
seul l'initiateur de ce workflow en a le droit. La seule façon -
logicielle - d'annuler une signature que nous envisagions c'était
quand on vérifie un document et que celui-ci apparaît ne pas être
signé par celui qui le prétend.

Par contre, le fait pour un utilisateur de refuser un document par
rapport à son contenu est bien sûr une possibilité : Bob reçoit un
document d'Alice, refuse de donner son aval, appelle Alice, le lui
signifie. Celle-ci en prend acte et annule le workflow, ou bien, si
elle n'en est pas l'auteur, fait une demande à qui de droit.

Donc si un document paraît utile tout en ayant été trop modifié par
rapport à l'oginal, on peut effectivement annuler le workflow et en
relancer un avec le dit document pour base.

Voilà, j'espère vous avoir compris.

Cordialement,


Pierre