| chat.freenode.net #tryton-fr log beginning Sat Dec 1 00:03:01 CET 2018 | ||
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | 00:30 | |
| -!- thaneor(~lenovo3@r179-25-33-245.dialup.adsl.anteldata.net.uy) has joined #tryton-fr | 03:08 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | 08:07 | |
| semarie | une 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-berc | 09:45 |
|---|---|---|
| semarie | elle refait le point sur la réglementation au regard des dernières mises à jour du BOFIP | 09:46 |
| cedk | semarie: ça reste toujours une demande impossible à réaliser techniquement: http://bofip.impots.gouv.fr/bofip/10691-PGP#10691-PGP_100_021 | 10:18 |
| cedk | ce qui est terrible c'est que les exemples donnés: empreinte numérique à clé privée, chaînage ne garantie pas la demande | 10:20 |
| semarie | ce qui est demandé, ce n'est pas une obligation de résultat, mais une obligation de moyens renforcée | 10:22 |
| cedk | mais j'image que c'est juste pas bien rédigé et que dans les faites de simples controls applicatifs sont suffisant | 10:22 |
| semarie | de 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ée | 10:23 |
| semarie | c'est à dire en faisant que toute écriture de paiement de "la caisse" soit posté automatiquement en comptabilité | 10:24 |
| semarie | ils font la définition sur l'enregistrement extra-comptable des paiements reçus | 10:24 |
| semarie | il faut que le paiement soit enregistré: "concomitamment, automatiquement et obligatoirement" en comptabilité | 10:25 |
| semarie | ensuite, il me semble qu'il existe des moyens techniques pour assurer l'inaltérabilité de manière "plausible". | 10:27 |
| semarie | donc 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érable | 10:27 |
| semarie | que ce qui est avant est* inaltérable | 10:27 |
| cedk | semarie: ce que j'ai vu c'est la chaînage par hash (comme mercurial ou git) | 10:27 |
| semarie | cedk: si on imprime ce hash sur une facture, et que la facture est envoyée au tiers, ça rend la comptabilité inaltérable | 10:28 |
| semarie | la 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 |
| semarie | et 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 |
| semarie | zut | 10:30 |
| semarie | les factures* | 10:30 |
| cedk | semarie: pourqoi pas | 10:30 |
| cedk | je verrais bien un Mixin qui fournit les outils pour faire une chaine de hash | 10:31 |
| cedk | car si on implement un POS, ça pourrait être réutilisé | 10:32 |
| semarie | je verrais bien la question du POS séparée de la question de l'inaltérabilité de la comptabilité | 10:33 |
| cedk | pour moi, techniquement ce sont les même solutions qui doivent être appliquées | 10:34 |
| semarie | sauf 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 caisse | 10:35 |
| semarie | "un particulier" = "non assujetti à la TVA". donc l'administration ne peut pas lui demander ses tickets de caisse | 10:36 |
| semarie | le 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 |
| semarie | et comme les écritures du POS sont dans la comptabilité, elles sont indirectement authentifiées comme non modifiable aussi | 10:38 |
| cedk | pour moi afficher le hash c'est juste un bonus mais pas une obligation absolue | 10:44 |
| cedk | si comme le document l'indique une chaine de hash est un moyen technique valable (suffisante) d'inaltérabilité, c'est la solution la plus simple | 10:45 |
| semarie | s'il n'est pas affiché quelque part hors du contrôle de l'utilisateur, il peut être recalculé | 10:46 |
| semarie | après, on peut utiliser une fonction de hash "lente" comme pour les mots de passe | 10:46 |
| cedk | il y a d'autre technique qui pourrait être utilisée à la place de la publication comme une signature timestamp | 10:46 |
| semarie | cela limite le recalcul de l'ensemble des hashs de la base (cela devient trop long à faire), mais cela ne prouve rien. | 10:47 |
| cedk | semarie: oui on peut recalculer une chaine de hash mais d'après ce que je vois ce n'est pas considérer comme non suffisant | 10:47 |
| cedk | je 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 |
| cedk | semarie: 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 recaculer | 10:50 |
| semarie | oui, 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 |
| semarie | on peut modifier les données, mais la modification reste visible | 10:52 |
| cedk | semarie: 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 |
| cedk | tout comme la signature de timestamp, c'est un plus qui rend la falsification plus difficile | 10:53 |
| semarie | la signature de timestamp suppose un tiers. mais oui, c'est un procédé qui est efficace aussi | 10:54 |
| cedk | mais c'est pas infaïble par example on peut toujours supprimer le dernier mouvement sans problème | 10:54 |
| cedk | car 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 facture | 10:54 |
| semarie | c'est vrai | 10:55 |
| cedk | semarie: c'est pareil avec la signature timestamp | 10:58 |
| cedk | je ne pense pas qu'il y ait une solution 100% fiable comme toujours en sécurité | 10:58 |
| cedk | Odoo ne fait que ça: https://github.com/odoo/odoo/blob/12.0/addons/l10n_fr_certification/models/account.py | 10:59 |
| semarie | oui, c'est un simple chainage de sha256 | 11:00 |
| semarie | je 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 |
| semarie | mais on doit pouvoir n'imprimer que un hmac ? | 11:07 |
| semarie | ou avoir directement le hmac de stocké | 11:08 |
| -!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr | 11:31 | |
| cedk | semarie: ha oui c'est une possibilité | 11:43 |
| cedk | après l'astuce est d'avoir plusieurs sécurités afin d'avoir une confiance suffisante | 11:44 |
| -!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr | 13:25 | |
| -!- thaneor1(~lenovo3@r179-25-169-1.dialup.adsl.anteldata.net.uy) has joined #tryton-fr | 15:11 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | 17:06 | |
| -!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr | 17:15 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | 17:32 | |
| -!- azerttyu(~azerttyu@37.61.245.231) has joined #tryton-fr | 19:57 | |
| -!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr | 21:01 | |
| -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | 22:11 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!