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-fr01:12
-!- thaneor(~lenovo3@r179-25-33-245.dialup.adsl.anteldata.net.uy) has joined #tryton-fr04:12
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr09:12
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-berc10:12
semarieelle refait le point sur la réglementation au regard des dernières mises à jour du BOFIP10:12
cedksemarie: ça reste toujours une demande impossible à réaliser techniquement: http://bofip.impots.gouv.fr/bofip/10691-PGP#10691-PGP_100_02111:12
cedkce qui est terrible c'est que les exemples donnés: empreinte numérique à clé privée, chaînage ne garantie pas la demande11:12
semariece qui est demandé, ce n'est pas une obligation de résultat, mais une obligation de moyens renforcée11:12
cedkmais j'image que c'est juste pas bien rédigé et que dans les faites de simples controls applicatifs sont suffisant11:12
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ée11:12
semariec'est à dire en faisant que toute écriture de paiement de "la caisse" soit posté automatiquement en comptabilité11:12
semarieils font la définition sur l'enregistrement extra-comptable des paiements reçus11:12
semarieil faut que le paiement soit enregistré: "concomitamment, automatiquement et obligatoirement" en comptabilité11:12
semarieensuite, il me semble qu'il existe des moyens techniques pour assurer l'inaltérabilité de manière "plausible".11:12
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érable11:12
semarieque ce qui est avant est* inaltérable11:12
cedksemarie: ce que j'ai vu c'est la chaînage par hash (comme mercurial ou git)11:12
semariecedk: si on imprime ce hash sur une facture, et que la facture est envoyée au tiers, ça rend la comptabilité inaltérable11:12
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)11:12
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é11:12
semariezut11:12
semarieles factures*11:12
cedksemarie: pourqoi pas11:12
cedkje verrais bien un Mixin qui fournit les outils pour faire une chaine de hash11:12
cedkcar si on implement un POS, ça pourrait être réutilisé11:12
semarieje verrais bien la question du POS séparée de la question de l'inaltérabilité de la comptabilité11:12
cedkpour moi, techniquement ce sont les même solutions qui doivent être appliquées11:12
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 caisse11:12
semarie"un particulier" = "non assujetti à la TVA". donc l'administration ne peut pas lui demander ses tickets de caisse11:12
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)11:12
semarieet comme les écritures du POS sont dans la comptabilité, elles sont indirectement authentifiées comme non modifiable aussi11:12
cedkpour moi afficher le hash c'est juste un bonus mais pas une obligation absolue11:12
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 simple11:12
semaries'il n'est pas affiché quelque part hors du contrôle de l'utilisateur, il peut être recalculé11:12
semarieaprès, on peut utiliser une fonction de hash "lente" comme pour les mots de passe11:12
cedkil y a d'autre technique qui pourrait être utilisée à la place de la publication comme une signature timestamp11:12
semariecela limite le recalcul de l'ensemble des hashs de la base (cela devient trop long à faire), mais cela ne prouve rien.11:12
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 suffisant11:12
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é"11:12
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 recaculer11:12
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)11:12
semarieon peut modifier les données, mais la modification reste visible11:12
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)11:12
cedktout comme la signature de timestamp, c'est un plus qui rend la falsification plus difficile11:12
semariela signature de timestamp suppose un tiers. mais oui, c'est un procédé qui est efficace aussi11:12
cedkmais c'est pas infaïble par example on peut toujours supprimer le dernier mouvement sans problème11:12
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 facture11:12
semariec'est vrai11:12
cedksemarie: c'est pareil avec la signature timestamp11:12
cedkje ne pense pas qu'il y ait une solution 100% fiable comme toujours en sécurité11:12
cedkOdoo ne fait que ça: https://github.com/odoo/odoo/blob/12.0/addons/l10n_fr_certification/models/account.py11:12
semarieoui, c'est un simple chainage de sha25612:12
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é12:12
semariemais on doit pouvoir n'imprimer que un hmac ?12:12
semarieou avoir directement le hmac de stocké12:12
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr12:12
cedksemarie: ha oui c'est une possibilité12:12
cedkaprès l'astuce est d'avoir plusieurs sécurités afin d'avoir une confiance suffisante12:12
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr14:12
-!- thaneor1(~lenovo3@r179-25-169-1.dialup.adsl.anteldata.net.uy) has joined #tryton-fr16:12
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr18:12
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr18:12
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr18:12
-!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr20:12
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr22:12
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr23:12

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