View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009053 | Taler | exchange | public | 2024-08-09 20:29 | 2025-05-29 16:16 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.0 stretch goals | ||||
| Summary | 0009053: add support for automated sanction list processing [4d] | ||||
| Description | We first need to get our hands on an actual sanction list so we know what the format looks like. | ||||
| Tags | compliance | ||||
|
|
Todo: - actual helper(s) to evaluate sanctions list against attributes - testing! - improve threshold formulas |
|
|
Vint has delivered: https://git.disroot.org/lnrs/kycheck |
|
|
I've compiled the code, several issues: 1) Downloaded the consolidated-list_2025-05-15.xml from https://www.sesam.search.admin.ch/sesam-search-web/pages/downloadXmlGesamtliste.xhtml?lang=en&action=downloadXmlGesamtlisteAction, then imported the 37 MB file via ~/.local/bin/kycheck --input ~/Downloads/consolidated-list_2025-05-15.xml Result: kyccheck takes 60s compute time on a Threadripper 1950X and consumes 1000 GB of virtual and 6 GB of actual RAM on-load. WTF? Note that xmllint parses the same XML in less than 1s on this system. There is also no conceivable reason to use significantly more RAM than the size of the list, so 64 MB would be fine, but 6 GB is out-of-this-world! Note that we will intend to deploy GNU Taler on systems with less memory than this, you're using more than everything else combined! Plus it is awfully slow. 2) Next I tried to use it, and pasted '{"company_name" : "Eindhoven University of Technology", "id" : "abcdef", "address" : { "country" : "NL", "street_name" : "Groene Loper", "street_number" : "3", "zipcode" : "5612 AE", "town_location" : "Eindhoven" } }' from your example input into STDIN. The result was: '"Could not decode JSON (\"Error in $: not enough input\"), please try again"'. Note the malformed error message, and the fact that I'm not getting what was promised either... I also tried just giving '{}' as the input (empty JSON object), same error. So it's definitively not a syntax error in the input. 3) I made one tiny modification to your build system, setting 'enable: false' in stack.yaml. After that, I could kind-of build on Debian stable just using 'stack build' (without NixOS installed). It still insisted on re-installing (!) the same version (!) of ghc, so I'm still not happy with the build system as the current state is not reasonable for creating Debian packages, but that's something "for later". |
|
|
4) The project has some insane dependencies. Like crypton, building Twofish and other cryptographic primitives. An HTTP client library. CBOR. ASN1. Socks5 support. iproute. blaze-html, zlib. In the end, you have a 53 MB binary (plus external C code) for 3000 lines of code! This is just wrong on many levels, impossible supply chain. I understand type-safety is easily confused with "safe dependency", but this is too much by far for what the project needs. 5) Adding "system-ghc: true" to stack.yaml seems to convince it to use the local compiler. ;-) |
|
|
6) Compiler warning: kycheck/app/Main.hs:76:85: warning: [GHC-18042] [-Wtype-defaults] • Defaulting the type variable ‘a0’ to type ‘Integer’ in the following constraints (Show a0) arising from a use of ‘show’ at app/Main.hs:76:85-88 (Integral a0) arising from a use of ‘floor’ at app/Main.hs:76:92-96 • In the first argument of ‘($)’, namely ‘show’ In the second argument of ‘(++)’, namely ‘(show $ floor $ diffUTCTime start (UTCTime age 0))’ In the second argument of ‘($)’, namely ‘"Seconds since epoch: " ++ (show $ floor $ diffUTCTime start (UTCTime age 0))’ | 76 | Just age -> print $ "Seconds since epoch: " ++ (show $ floor $ diffUTCTime start (UTCTime age 0)) | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-08-09 20:29 | Christian Grothoff | New Issue | |
| 2024-08-09 20:29 | Christian Grothoff | Status | new => assigned |
| 2024-08-09 20:29 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2024-08-19 09:01 | Christian Grothoff | Target Version | 0.14 => 1.0 |
| 2024-08-23 00:24 | Christian Grothoff | Target Version | 1.0 => 1.0 stretch goals |
| 2024-08-24 10:40 | Christian Grothoff | Summary | add support for sanction lists => add support for sanction lists [5d] |
| 2024-09-14 00:57 | Christian Grothoff | Priority | urgent => high |
| 2025-01-05 16:24 | Christian Grothoff | Note Added: 0023938 | |
| 2025-01-05 16:24 | Christian Grothoff | Summary | add support for sanction lists [5d] => add support for sanction lists [4d] |
| 2025-01-05 23:22 | Christian Grothoff | Note Edited: 0023938 | |
| 2025-01-12 09:17 | Christian Grothoff | Note Edited: 0023938 | |
| 2025-04-17 22:21 | Christian Grothoff | Tag Attached: compliance | |
| 2025-05-07 16:51 | Florian Dold | Summary | add support for sanction lists [4d] => add support for automated sanction list processing [4d] |
| 2025-05-09 09:23 | Christian Grothoff | Note Added: 0024860 | |
| 2025-05-29 15:56 | Christian Grothoff | Note Added: 0025052 | |
| 2025-05-29 16:15 | Christian Grothoff | Note Added: 0025053 | |
| 2025-05-29 16:16 | Christian Grothoff | Note Added: 0025054 |
