IRC logs of #tryton-fr for Saturday, 2018-12-01

chat.freenode.net #tryton-fr log beginning Sat Dec 1 00:03:01 CET 2018
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr00:30
-!- thaneor(~lenovo3@r179-25-33-245.dialup.adsl.anteldata.net.uy) has joined #tryton-fr03:08
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr08:07
semarieune note intéressante de l'APRIL: "Réglementation des systèmes de caisse : les logiciels libres de mieux en mieux pris en compte par Bercy" https://www.april.org/reglementation-des-systemes-de-caisse-les-logiciels-libres-de-mieux-en-mieux-pris-en-compte-par-berc09:45
semarieelle refait le point sur la réglementation au regard des dernières mises à jour du BOFIP09:46
cedksemarie: ça reste toujours une demande impossible à réaliser techniquement: http://bofip.impots.gouv.fr/bofip/10691-PGP#10691-PGP_100_02110:18
cedkce qui est terrible c'est que les exemples donnés: empreinte numérique à clé privée, chaînage ne garantie pas la demande10:20
semariece qui est demandé, ce n'est pas une obligation de résultat, mais une obligation de moyens renforcée10:22
cedkmais j'image que c'est juste pas bien rédigé et que dans les faites de simples controls applicatifs sont suffisant10:22
semariede mon point de vue, avoir une caisse avec tryton est possible, mais en mettant en place un système qui ne soit pas une caisse selon la définition donnée10:23
semariec'est à dire en faisant que toute écriture de paiement de "la caisse" soit posté automatiquement en comptabilité10:24
semarieils font la définition sur l'enregistrement extra-comptable des paiements reçus10:24
semarieil faut que le paiement soit enregistré: "concomitamment, automatiquement et obligatoirement" en comptabilité10:25
semarieensuite, il me semble qu'il existe des moyens techniques pour assurer l'inaltérabilité de manière "plausible".10:27
semariedonc pas de système infaillible à 100%, mais simplement des "points de contrôle" dans le temps où l'on peut prouver que ce qui est avant et inaltérable10:27
semarieque ce qui est avant est* inaltérable10:27
cedksemarie: ce que j'ai vu c'est la chaînage par hash (comme mercurial ou git)10:27
semariecedk: si on imprime ce hash sur une facture, et que la facture est envoyée au tiers, ça rend la comptabilité inaltérable10:28
semariela fait que le hash soit sur la facture, le rend non modifiable sans que cela se voit (le nouveau hash sera différent de celui qui est sur la facture chez le client)10:29
semarieet l'administration a la capacité de demander au client (si c'est un professionnel) les facturent. on peut donc contrôler l'inaltérabilité10:30
semariezut10:30
semarieles factures*10:30
cedksemarie: pourqoi pas10:30
cedkje verrais bien un Mixin qui fournit les outils pour faire une chaine de hash10:31
cedkcar si on implement un POS, ça pourrait être réutilisé10:32
semarieje verrais bien la question du POS séparée de la question de l'inaltérabilité de la comptabilité10:33
cedkpour moi, techniquement ce sont les même solutions qui doivent être appliquées10:34
semariesauf que pour un POS, avoir un hash imprimé sur le ticket est plus contestable. le client est généralement un particulier, et il n'a pas l'obligation de conserver ses tickets de caisse10:35
semarie"un particulier" = "non assujetti à la TVA". donc l'administration ne peut pas lui demander ses tickets de caisse10:36
semariele hash a plus de pertinence en étant au niveau de l'écriture comptable. cela authentifie l'ensemble de la comptabilité comme non modifiée (dès qu'un hash est "publié" sur une facture professionnelle)10:37
semarieet comme les écritures du POS sont dans la comptabilité, elles sont indirectement authentifiées comme non modifiable aussi10:38
cedkpour moi afficher le hash c'est juste un bonus mais pas une obligation absolue10:44
cedksi comme le document l'indique une chaine de hash est un moyen technique valable (suffisante) d'inaltérabilité, c'est la solution la plus simple10:45
semaries'il n'est pas affiché quelque part hors du contrôle de l'utilisateur, il peut être recalculé10:46
semarieaprès, on peut utiliser une fonction de hash "lente" comme pour les mots de passe10:46
cedkil y a d'autre technique qui pourrait être utilisée à la place de la publication comme une signature timestamp10:46
semariecela limite le recalcul de l'ensemble des hashs de la base (cela devient trop long à faire), mais cela ne prouve rien.10:47
cedksemarie: oui on peut recalculer une chaine de hash mais d'après ce que je vois ce n'est pas considérer comme non suffisant10:47
cedkje suppose que ça rentre dans le cadre de "L'accès à une donnée par un homme de l'art ne pouvant jamais être empêché"10:49
cedksemarie: je ne pense pas qu'un hash lent soit viable, soit il sera trop lent pour être utiliser en direct (et/ou valider la chaîne) ou bien toujours trop rapide pour recaculer10:50
semarieoui, apparemment le hash est suffissant. mais ce que j'aime avec l'aspect "affiché sur une facture", c'est que même l'homme de l'art ne peut rien faire (sauf à considérer des cambriolages et le remplacement des factures chez les tiers)10:50
semarieon peut modifier les données, mais la modification reste visible10:52
cedksemarie: oui comme je dis l'affichage sur la facture est un bonus (facile à implémenter une fois que le hash existe sur le mouvement)10:52
cedktout comme la signature de timestamp, c'est un plus qui rend la falsification plus difficile10:53
semariela signature de timestamp suppose un tiers. mais oui, c'est un procédé qui est efficace aussi10:54
cedkmais c'est pas infaïble par example on peut toujours supprimer le dernier mouvement sans problème10:54
cedkcar en cas de control on ne sait pas qu'il y a une facture chez le client avec un faux hash car on a pas de trace de la facture10:54
semariec'est vrai10:55
cedksemarie: c'est pareil avec la signature timestamp10:58
cedkje ne pense pas qu'il y ait une solution 100% fiable comme toujours en sécurité10:58
cedkOdoo ne fait que ça: https://github.com/odoo/odoo/blob/12.0/addons/l10n_fr_certification/models/account.py10:59
semarieoui, c'est un simple chainage de sha25611:00
semarieje pense à un problème potentiel avec le fait d'avoir un simple hash imprimé sur une facture. un client (mal-honnête) pourrait modifier le hash qui est imprimé (surtout s'il a accès à un document PDF de la facture), et rend contestable l'état de ma comptabilité11:06
semariemais on doit pouvoir n'imprimer que un hmac ?11:07
semarieou avoir directement le hmac de stocké11:08
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr11:31
cedksemarie: ha oui c'est une possibilité11:43
cedkaprès l'astuce est d'avoir plusieurs sécurités afin d'avoir une confiance suffisante11:44
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr13:25
-!- thaneor1(~lenovo3@r179-25-169-1.dialup.adsl.anteldata.net.uy) has joined #tryton-fr15:11
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr17:06
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr17:15
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr17:32
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr19:57
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr21:01
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr22:11

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!