View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7934 [Taler] exchange minor have not tried 2023-09-05 11:51 2023-09-29 13:31
Reporter: javier.sepulveda Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.4  
    Target Version: 0.9.4  
Summary: ToS program, can't be executed from anywhere but from the .rst file is located + Other improvents
Description:
Program: taler-terms-generator

https://git.taler.net/exchange.git/tree/contrib/taler-terms-generator.in

### When using the taler-terms-generator program from the outside of the $TOS_PATH (check in deployment.git/sandcastle: docker-compose.yml + images/exchange/scripts/startup.sh), it doesn't work.

cd $TOS_PATH
taler-terms-generator -i file # works

taler-terms-generator -i /path/to/file # doesn't work

Proposed improvement:
------------------------
1) Include the ".rst" type file, as part of the file name.

i.e : taler-terms-generator -i file.rst

2) Please check line 29

For the sake of readability, maybe it is better to use the equal symbol as delimiter, instead of a slash symbol : 's=/=\\/=g'



Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020561)
Christian Grothoff   
2023-09-29 13:31   
3fa3a7da..74c56c62 modifies the code to make it run from any location. I don't see the need to fix the sed-escaping, but also don't fundamentally oppose.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7945 [Taler] documentation text always 2023-09-26 17:51 2023-09-26 17:51
Reporter: lewi Platform:  
Assigned To: Stefan OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Broken link in the taler-merchant-manual
Description: A link in the merchant manual is broken.
https://docs.taler.net/taler-merchant-manual.html#transfers

This link to the documentation on the Taler Bank Merchant HTTP API is broken:
https://docs.taler.net/taler-bank-merchant-http-api

It produces the error 404 not found
Tags:
Steps To Reproduce: Open https://docs.taler.net/taler-bank-merchant-http-api
Additional Information:
Attached Files: grafik.png (5,292 bytes) 2023-09-26 17:51
https://bugs.gnunet.org/file_download.php?file_id=1401&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7943 [GNUnet] util library minor have not tried 2023-09-25 14:24 2023-09-25 20:50
Reporter: schanzen Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.21.0  
Summary: vfork deprecated
Description: ../src/util/os_priority.c:439:9: warning: 'vfork' is deprecated: Use posix_spawn or fork [-Wdeprecated-declarations]
  ret = vfork ();
        ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1: note: 'vfork' has been explicitly marked deprecated here
__deprecated_msg("Use posix_spawn or fork")
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
        #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
                                                      ^
1 warning generated.

https://web.archive.org/web/20150924082249/gnunet.org/vfork

Can we just use fork() and accept the issue or what do we do?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020547)
Christian Grothoff   
2023-09-25 14:34   
(Last edited: 2023-09-25 14:36)
I don't care about vfork() being deprecated. It is precisely what we need here. Without it, you will see very hard to diagnose problems with processes not terminating / hanging, I really would not touch this part. It works, it is correct, and fork is incorrect. Some idiots deprecating vfork() doesn't change that.
(0020554)
schanzen   
2023-09-25 20:46   
well. we should care when it is removed, which is what this indicates.
Considering that this is an ifdef for portability _right now_ in order to preserve portability, we need a plan b.
(0020555)
Christian Grothoff   
2023-09-25 20:50   
No, deprecation doesn't necessarily indicate impending removal for a syscall. It could take a decade or more, as doing so breaks legacy applications. Let's do the plan B when they *actually* remove it. And: my original post does spell out a complex plan B with pipes, just that is horribly inefficient by comparison.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7844 [Taler] libeufin-bank feature have not tried 2023-05-17 20:11 2023-09-25 15:49
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: libeufin-sandbox tool should allow creating accounts
Description: Even if registering new accounts is disabled via the Web interface, there should still be a way to create new accounts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020552)
MS   
2023-09-25 15:49   
After internal discussion, this can be closed after the new SPA will offer a "admin"-mode
where only the admin can register new accounts, when the self-registration is disabled.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7812 [Taler] libeufin-bank major have not tried 2023-04-22 18:19 2023-09-25 14:53
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: demobank account registration sometimes fails because IBAN already exists
Description: It looks like the sandbox just generates a random IBAN but then gives up if it's already used. Instead, it must try harder to find a fresh one!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020366)
MS   
2023-07-24 11:10   
(Last edited: 2023-07-24 11:12)
This waits 0007890 to be solved and the delivery of NLnet task 5. The dependency is not technical but based on priority.
(0020549)
MS   
2023-09-25 14:53   
Lowering the priority to normal, as now IBANs get a bigger size.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7902 [Taler] documentation minor have not tried 2023-08-03 20:43 2023-09-25 14:51
Reporter: MS Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Document the NetzBon installer.
Description: The shell script that installs Taler for NetzBon needs a manual. The manual should be written in Sphinx and served under docs.taler.net.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020548)
MS   
2023-09-25 14:51   
This document should be written like it's suggested in 0007831, therefore not exclusively for NetzBon,
but rather targeted for any organization that wants to setup a local currency. 0007831 can be then resolved
at the same time when this gets resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7831 [Taler] documentation text have not tried 2023-05-02 08:41 2023-09-25 14:47
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Create section about setting up a regional currency.
Description: One NLnet suggestion was to have a documentation section about how
to _completely_ setup a regional currency, therefore with ALL the Taler
components.

And before publishing it, any tool (e.g. shell scripts) should have general names
that do NOT mention any particular regional currency, and the source code as well
should NOT hard-code any value related to one particular regional currency.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7942 [Taler] libeufin-nexus minor have not tried 2023-09-25 13:02 2023-09-25 13:02
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Design multiple bank accounts handling.
Description: Camt reports MAY account for multiple bank accounts that are owned by the user at one financial institution.

Nexus at the moment lacks any handling of such situation, because it assumes that the client has always
one, and only one bank account at the financial institution serving the requests.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7462 [Taler] libeufin (general) minor have not tried 2022-11-16 10:31 2023-09-25 12:09
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: HTTP traffic on Unix domain socket fails due to wrong file permissions.
Description: This was observed when Nginx tried to use the Unix domain socket opened by LibEuFin:

11:42:34.310 [main] DEBUG tech.libeufin.util - Listening on /home/demo/sockets/bank.http ..
16:08:56.861 [epollEventLoopGroup-3-1] INFO ktor.test - Autoreload is disabled because the development mode is off.
16:08:56.868 [epollEventLoopGroup-3-1] INFO ktor.test - Application started in 0.057 seconds.
16:08:57.142 [DefaultDispatcher-worker-1] DEBUG tech.libeufin.sandbox - 404 Not Found, GET /bad-request - thread (id/name/group): 23/DefaultDispatcher-worker-1/main
16:08:57.149 [epollEventLoopGroup-3-1] DEBUG tech.libeufin.sandbox - Application stopping: io.ktor.application.Application@3b430b91
16:08:57.149 [epollEventLoopGroup-3-1] DEBUG tech.libeufin.sandbox - Application stopped: io.ktor.application.Application@3b430b91
16:08:57.158 [epollEventLoopGroup-3-1] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
java.lang.NullPointerException: null
    at io.netty.buffer.Unpooled.wrappedBuffer(Unpooled.java:156)
    at LibeufinHttpHandler$channelRead0$1.invoke(UnixDomainSocket.kt:108)
    at LibeufinHttpHandler$channelRead0$1.invoke(UnixDomainSocket.kt:72)
    at io.ktor.server.testing.TestEngineKt$withTestApplication$1.invoke(TestEngine.kt:68)
    at io.ktor.server.testing.TestEngineKt$withTestApplication$1.invoke(TestEngine.kt:66)
    at io.ktor.server.testing.TestEngineKt.withApplication(TestEngine.kt:49)
    at io.ktor.server.testing.TestEngineKt.withApplication$default(TestEngine.kt:41)
    at io.ktor.server.testing.TestEngineKt.withTestApplication(TestEngine.kt:66)
    at LibeufinHttpHandler.channelRead0(UnixDomainSocket.kt:72)
    at LibeufinHttpHandler.channelRead0(UnixDomainSocket.kt:67)
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
    at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:280)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
    at io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:829)

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020543)
MS   
2023-09-25 12:08   
The following file should be checked to address this problem:
https://git.taler.net/libeufin.git/tree/util/src/main/kotlin/UnixDomainSocket.kt?id=f5e670cc0bb8dc8424eb1aa891fc0161064395ca

In particular, the Unix domain socket open to accept HTTP traffic seems to lack the group permission to let Nginx use it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7739 [Taler] libeufin-nexus minor have not tried 2023-03-04 16:48 2023-09-25 11:54
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Creating background tasks should be idempotent.
Description: Now it responds with 400, which is not even suitable for a name conflict.

The "POST ../schedule" call is responsible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019951)
MS   
2023-03-10 14:56   
Agreed that background tasks should be just overridden by the owner, without any idempotent behavior.
(0020367)
MS   
2023-07-24 11:10   
(Last edited: 2023-07-24 11:11)
This waits 0007890 to be solved and the delivery of NLnet task 5. The dependency is not technical but based on priority.
(0020525)
Christian Grothoff   
2023-09-23 15:01   
Well, with new architecture we may not have background tasks configured via REST anymore anyway. Should we keep this open as a reminder that background tasks need to be re-done, or mark "won't fix"?
(0020539)
MS   
2023-09-25 11:50   
Was it agreed that Nexus will have in-Kotlin background tasks?

IIRC a designer has proposed to have CRON(8) managing Nexus repetitive tasks. That would for sure cut on complexity.
(0020540)
Christian Grothoff   
2023-09-25 11:54   
Yes, I think for the new design we proposed for the "background" tasks to be (separate) commands that can be invoked "at will". That said, there could be 3 variants:
- one-shot: runs the repetitive task once, next time again via cron/systemd
- long-poller: runs the repetitive task repeatedly, internally uses long-polling/notifications to wake up on-demand so things still appear "instantly"
- sleep loop: runs the repetetive task in a while (1) { work; sleep; }-loop, so started only once to avoid high-cost of startup

Which one(s) is best may depend on the task, but modulo long-polling complexity begin implemented, they can probably be all done by the same command with minor command-line option variations.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6907 [Taler] wallet-core minor have not tried 2021-06-22 13:14 2023-09-23 16:47
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: operations should support cancellation tokens
Description: The wallet implementation currently doesn't handle cancellation and timeouts nicely. Most operations should take a cancellation token and pass that to other operations that are invoked.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018985)
Florian Dold   
2022-08-02 18:10   
To clarify: When the user clicks "Delete" on a transaction, any asynchronous work related to that transaction in wallet-core should be cancelled. This is not strictly needed for correctness, but is overall nicer behavior.
(0020052)
sebasjm   
2023-04-10 15:50   
this issue needs to be reviewed.

I think is covered by DD 37


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6979 [Taler] wallet-core minor have not tried 2021-08-04 21:24 2023-09-23 16:47
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: wallet should handle timeouts better
Description: The wallet currently doesn't handle timeout elegantly. Instead of some ad-hoc timeout parameter, we should use cancellation tokens, especially for HTTP requests.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020311)
Florian Dold   
2023-06-28 11:27   
To cancel things nicely, we should have some map from "taskid => cancellationToken".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7520 [Taler] libeufin-bank feature have not tried 2022-12-12 17:33 2023-09-23 16:45
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Implement policy to abort non confirmed cashout operations.
Description: A configurable time span should instruct libeufin sandbox to abort the cashout
operations that were never confirmed with the TAN.

This is not part of the API yet, and it should only be implemented after a first
deployment of Libeufin in the context of a local currency.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020060)
MS   
2023-04-11 10:40   
Not relevant for the Postfinance integration.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7781 [Taler] libeufin-bank feature have not tried 2023-03-29 14:51 2023-09-23 16:42
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: sandbox demobank should have endpoint for transaction volume / statistics info
Description:
from chat:
> But at least for the bank we should be able to show both
> # bank transactions (per day/week/month/year) and
> # <CURRENCY> transacted in total (per day/week/month/year).
>
> It should be displayed in SPA as an HTML table with a CSV-export might do as well.

So there should be endpoint for the SPA (returns json) but also content-type = csv
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020535)
Christian Grothoff   
2023-09-23 16:42   
This could probably also be done easily by Antoine. MS: maybe you can just write the REST API spec, and leave the rest to Antoine and Sebastian?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7694 [Taler] libeufin-bank feature have not tried 2023-02-14 13:23 2023-09-23 16:40
Reporter: MS Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: set currency conversion rates and fees in the configuration
Description: as opposed to have the hard-coded, as in the current version.

This however should be done after 0007527 and 0007515.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020533)
Christian Grothoff   
2023-09-23 16:40   
Sounds like an easy first coding task for Antoine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7734 [Taler] libeufin-bank minor have not tried 2023-02-28 17:06 2023-09-23 16:31
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Track used IBANs.
Description: In order to avoid that one IBAN gets reassigned after a user removal, the bank has to keep track of all the IBANs
that were assigned to any bank account.
Tags:
Steps To Reproduce:
Additional Information: At a later stage, the bank may employ a policy to recycle those used IBANs.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7780 [Taler] taler-harness feature have not tried 2023-03-28 20:23 2023-09-23 16:26
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: taler-harness lint should check exchange ToS markdown syntax
Description: We require that there is at least one top-level section defined, and the linter should complain if not.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7118 [Taler] other minor have not tried 2021-12-01 11:25 2023-09-23 16:23
Reporter: ms-mantis Platform:  
Assigned To: dvn OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: merchant demos doesn't install all dependencies
Description: Namely, 'babel' and 'uwsgi' should be included as dependencies.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020531)
Christian Grothoff   
2023-09-23 16:23   
dvn: I assume you could easily fix this one, right?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7868 [Taler] wallet-core minor have not tried 2023-06-20 15:58 2023-09-23 16:23
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: recoup transaction not spec'ed in DD37
Description: We have the recoup transaction that results from the exchange revoking denominations.

It's not yet specified in DD37, nor is the implementation DD37-conformant.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7886 [Taler] wallet-core minor have not tried 2023-07-11 18:37 2023-09-23 16:23
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: consider adding log categories instead of file-based log tags
Description: This might make debugging for UI developers a bit easier, since it's easier to filter by a few categories than by file names.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7467 [Taler] sandcastle (containerized demo deployment) feature always 2022-11-17 18:01 2023-09-23 16:22
Reporter: sebasjm Platform:  
Assigned To: javier.sepulveda OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: have more than one exchange in demo
Description: after wallet ui can show different fee structure

that will help the wallet user why can they choose the exchange.

---
The exchanges in demo need to have a bank account in the sandbox bank to allow manual withdraw

Both exchange must have different fee structure and STEFAN parameters.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7426 [Taler] Web site(s) minor have not tried 2022-11-03 09:18 2023-09-23 16:22
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: assigned Product Version: 0.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: "public-accounts" link points at bank's homepage
Description: The landing Website offers a link to the "public-accounts" page at the bank. The
link however doesn't show a dedicate page of public accounts, but rather the bank's
homepage.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019362)
Christian Grothoff   
2022-11-06 23:18   
When I click the link inside of the SPA header, I get a message saying that there are no public accounts. Also, I don't know what the deep link to get the public account page would even be right now.

We should fix the demo to have the public accounts setup, fix the link inside the SPA, and have a way to get to the public accounts page from the outside. Maybe the public accounts page should even not be the main SPA but some separate page/SPA served under a different URL?
(0019363)
Christian Grothoff   
2022-11-06 23:19   
Maybe we should disable the links (landing page, bank header) until this is fixed? Not sure how long it'll take...
(0019366)
sebasjm   
2022-11-07 12:16   
The navigation should be made based on URI (fragment is usually used so the SPA can be serve from an unique location) instead of localStorage state.
I will take a look
(0019380)
sebasjm   
2022-11-07 16:44   
fixed at 3eafb649
(0019381)
MS   
2022-11-07 16:57   
The links on the demo navigation bar should now be adapted to this new change.
(0020166)
MS   
2023-04-27 08:54   
Fixed in taler-merchant-demos.git at 6fa8d80b8d6873935ab14956b4ba62932bdd2a14. The "?lang=en" part is also gone from the link, as suggested by Sebastian.
(0020167)
MS   
2023-04-27 08:55   
(Last edited: 2023-04-27 08:56)
Setting to feedback and assigning to Javier to be ultimately checked after the next demo deployment.
(0020377)
MS   
2023-07-24 12:30   
Now tried to give feedback, but bank.demo.taler.net responds with a Nginx landing page. Same for demo.taler.net itself.
(0020378)
Christian Grothoff   
2023-07-24 14:06   
Works fine for me and dvn. Try again?
(0020380)
MS   
2023-07-24 20:47   
To get the page, the URL needs to start with "https" (trailing s)

Additionally, the link discussed in this issue does not even point to the bank anymore, but rather to the landing page itself.
(0020402)
javier.sepulveda   
2023-08-03 12:48   
The link still doesn't work , as it still pointing to itself : https://demo.taler.net/en/

But I assign this to NOBODY, as I am not able to fix this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6376 [Taler] libeufin-nexus tweak have not tried 2020-06-11 09:39 2023-09-23 16:22
Reporter: Florian Dold Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: test against all samples given by the German standard supplement
Description: https://www.ebics.de/de/datenformate/ergaenzende-dokumente

We should test against the camt5x documents in particular.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017381)
Florian Dold   
2021-01-21 02:15   
We mainly should make sure that the parser doesn't crash, and that we have the JSON that we generated as a reference file in a test case.
(0017391)
MS   
2021-01-22 17:07   
This gets delayed, as now the parser targets only one particular Camt style.
(0017392)
MS   
2021-01-25 15:56   
From commit: 5b536593b9d84a9bb5ea2908aa2ab259d9199308, libeufin-tests.git contains samples from ebics.de and the UBS testing platform.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6715 [Taler] libeufin-bank minor have not tried 2021-01-22 16:32 2023-09-23 16:21
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sandbox should not "activate" EBICS subscriber keys by default
Description: Instead, there should be a separate step where a request is made to the sandbox to activate the keys.

This allows us to test the behavior of Nexus *before* keys were activated by the bank (but after they were uploaded electronically).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6381 [Taler] libeufin-nexus minor have not tried 2020-06-14 17:19 2023-09-23 16:20
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: implement and test transaction identification matching for INFO->PENDING->BOOKED transition
Description: Currently we don't support a transaction transitioning between these states.

In order to do this, a transaction should be marked with a foreign key column "supersededBy" that points to the newer "version" of the same transaction with a different status.

By default, the superseded transaction shouldn't be returned in the transactions list anymore. The superseded and current transaction must share some common transaction identifier.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020062)
MS   
2023-04-11 10:54   
If one transaction gets from PENDING to BOOKED (becoming therefore superseded),
then this bug suggests that such transaction shows up in the list only as long as is pending.

Then, once it gets superseded by the new booked status, it won't show anymore?

If yes, why would the booked status NOT be interesting?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7336 [Taler] wallet (WebExtension) tweak always 2022-09-08 20:24 2023-09-23 16:16
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: ToS language "wrong"
Description: During the UX study, a user complained that the ToS were in English.
One issue is that we may not have them translated yet, but even if they were, we use the platform language, which the user may or may not have set properly. So giving the user an easy way to change to other *available* ToS languages would be nice.
Tags:
Steps To Reproduce:
Additional Information: This will require some protocol extension to tell the wallet in which other languages the ToS are available.
System Description
Attached Files:
Notes
(0019405)
Christian Grothoff   
2022-11-13 10:42   
2650fea..44f5e5c (docs.git) documents the new "Acceptable-Languages" HTTP header returned by the exchange (and other /terms and /pp handlers) which now specifies the list of alternative languages in which the ToS/PP are available. UIs should make use of this information to allow users to switch to another language.

Note that when downloading the ToS/PP in an alternative language, the client MUST NOT set the ETag header after varying the Accept-Language (or Accept-Encoding) header, otherwise the service will just return a "304 Not Modified".
(0019406)
Christian Grothoff   
2022-11-13 11:25   
IMO wallet-core should now add support to expose the list of supported languages to the UIs, and then we can add a ToS/PP language switcher to UIs. Not urgent, of course.
(0020417)
MarcS   
2023-08-17 13:43   
Hmm, for such new features which are not implemented in any of our frontends, we probably need a new Mantis category. After all, the issue is solved only after _all_ frontends implemented it...
(0020530)
Christian Grothoff   
2023-09-23 16:16   
MarcS: You could create child-bugs for each wallet-UI and have this be the parent bug.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7733 [Taler] wallet-core minor have not tried 2023-02-27 17:28 2023-09-23 16:15
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: runIntegrationTest should also do p2p payments, tips, etc.
Description: This makes it easier to test the UIs.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020011)
Florian Dold   
2023-04-04 16:02   
It does P2P payments now. It doesn't do tip payments, yet, because the demo doesn't reliably/automatically top up the tipping reserve yet.
(0020301)
Florian Dold   
2023-06-26 10:31   
Moving this to 0.9.4, since it requires tips working reliably in sandcastle.
(0020456)
Florian Dold   
2023-08-29 14:06   
Assigning this to Javier, since he's working on the rewards in the sandcastle.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5059 [Taler] wallet-core minor have not tried 2017-06-04 17:47 2023-09-23 16:15
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: handle cases where an exchange's key changes, but the base URL stays the same
Description: Currently the wallet gets confused by this and may refuse some operations until you reset the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017954)
Florian Dold   
2021-06-15 19:05   
This is implemented now, but needs a test case.
(0020483)
Christian Grothoff   
2023-09-03 15:21   
Bumping to 0.9.4, testcase is not RC.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7434 [Taler] wallet (WebExtension) trivial have not tried 2022-11-04 20:14 2023-09-23 16:15
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: icons in transaction history unclear
Description: Compared to the Android wallet, we don't have very clear icons for the type of transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019361)
Christian Grothoff   
2022-11-06 23:15   
We should use exactly the same icons for both. If needed, I can find some from the Noun project. Let me know (but first try to re-use those from Android wallet).
(0019375)
sebasjm   
2022-11-07 15:38   
Repo for assets created https://git.taler.net/taler-assets.git

We should start pushing assets there.
(0019399)
sebasjm   
2022-11-10 15:02   
WDYT about these

refresh https://thenounproject.com/icon/refresh-5288481/
https://thenounproject.com/icon/money-exchange-4186527/

transfer send https://thenounproject.com/icon/email-1046268/
invoice send https://thenounproject.com/icon/email-2629312/
invoice pay https://thenounproject.com/icon/payment-1105241/

deposit https://thenounproject.com/icon/bank-4186525/
withdraw https://thenounproject.com/icon/dollar-4186544/

tip https://thenounproject.com/icon/donation-1087354/

payment ok https://thenounproject.com/icon/trolly-2116221/
payment refunded https://thenounproject.com/icon/trolly-2116213/
refund https://thenounproject.com/icon/trolly-2116212/
payment pending https://thenounproject.com/icon/trolly-2116210/
(0019537)
sebasjm   
2022-12-23 14:32   
cc @marc
(0019548)
sebasjm   
2023-01-02 14:27   
moved icons into taler-assets repo
(0019625)
sebasjm   
2023-01-10 15:37   
moving this to 9.2 since it will not bring major improvement and still some discussion left in emails


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7547 [Taler] wallet-core feature have not tried 2022-12-30 12:59 2023-09-23 16:13
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: implement some basic dev-experiments
Description: As we now have the basic infrastructure for dev-experiments, we now should provide some first, simple dev-experiments to populate the wallet with interesting transactions.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019621)
Florian Dold   
2023-01-09 20:31   
Another important one: Simulate the "payment pending" response for confirmPay


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7698 [Taler] qtart minor have not tried 2023-02-16 13:04 2023-09-23 16:13
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: qtart should support opening a unix domain socket for the daemonized wallet
Description: Right now we can only run the one-shot wallet under qtart. We need some extra bindings in quickjs-libc to open unix domain sockets.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7605 [Taler] deployment and operations minor have not tried 2023-01-23 18:07 2023-09-23 16:12
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: put sync service into a separate container
Description: It's was part of the merchant container (which doesn't make much sense), and caused problems, so it got disabled.

We should re-deploy it as a separate container.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7573 [Taler] deployment and operations feature have not tried 2023-01-12 21:36 2023-09-23 16:12
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: split up sandcastle containers
Description: Currently, the merchant container has too many unrelated services.

While we can't do one process per container, we should do ~one logical service per container.

The current "merchant" container should be split up into:
- "merchant-backend" with just the merchant backend
- "frontend-blog", "frontend-shop", "frontend-survey" with the respective frontend services
- "sync" with the sync service
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7561 [Taler] qtart feature have not tried 2023-01-10 15:35 2023-09-23 16:12
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: make taler-wallet-cli runnable under qtart
Description: Some small helpers are still missing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019851)
Florian Dold   
2023-02-16 13:59   
Almost done, it works but the native taler-wallet-cli should still be added as an optional build target to the quickjs-tart build system.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7452 [Taler] wallet-core feature have not tried 2022-11-14 02:58 2023-09-23 16:02
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: extend GetExchangeTos wallet operation to be reuse for backup or auditor
Description: Wallet will be accepting ToS from other service, it will be useful to reuse the same logic.

Currently I need something similar for backup providers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019986)
Florian Dold   
2023-03-28 20:28   
I actually do not think that these operations are sufficiently similar enough to abstract them out.

The exchange ToS is human-readable text with an Etag, while the sync ToS is structured JSON without any versioning.
(0020001)
sebasjm   
2023-04-01 16:53   
What is the difference between the ToS that backup service provider and auditor uses?

Can we make a standard way of creating, serving, querying and displaying ToS for every service so we no need to build particular solutions for every service?

I think that the exchange implementation is good enough to be replicated, and we can reuse the same logic in the wallet (and ui)
(0020004)
Florian Dold   
2023-04-03 19:19   
The main problem here is that the ToS of different services (exchange vs. auditor vs. sync) do not share a lot of structure:

* auditor: do we even have ToS here yet?
* exchange: multi-language, multi-format human-readable document, ETag for version tracking
   (also, we might want to stop storing the ToS document, and only store which ETag was accepted by the user, as there's not a real need to review the exchange ToS while offline)
* sync: JSON format to explain fees of the service, unversioned

In general it's not a good idea to create an abstraction over things that are too different.
(0020042)
Christian Grothoff   
2023-04-09 21:46   
I'm confused by Florian's comment: the ToS of the different services use *exactly* the same code server-side, and should follow the same structure. Sure, the auditor doesn't yet have a ToS, but that's likely a matter of time. exchange, sync, merchant & anastasis, all use the same logic with ETag and support returning in format requested by the client. They are also all versioned, so the same abstraction makes sense client-side.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7518 [Taler] wallet (WebExtension) feature have not tried 2022-12-11 04:10 2023-09-23 15:59
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: search transaction
Description: add a search bar

maybe in the first version just search fee text on transaction content
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7835 [Taler] challenger feature N/A 2023-05-07 01:47 2023-09-23 15:59
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: 0.9.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: exchange does not support challenger service yet
Description: Primarily, the initial authorized setup step is not supported by our existing OAuth 2.0 plugin.

Plus, we should probably test the integration ;-).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020193)
Christian Grothoff   
2023-05-13 17:07   
ff1a2831..c9ed524b adds support for /setup. Still needs testing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7848 [Taler] wallet-core minor have not tried 2023-05-23 18:25 2023-09-23 15:59
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: wallet-core should return maximum expiration time for purse based on available points
Description: That allows the UIs to disable later expiration times.

Otherwise, purses might expire *before* coins expire.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7807 [Taler] documentation text have not tried 2023-04-21 15:04 2023-09-23 15:59
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: document conventions/guidelines for source-level dependencies (i.e. prebuilt branches and submodules)
Description: We currently handle this slightly different across subprojects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7859 [Taler] wallet-core minor have not tried 2023-06-06 11:56 2023-09-23 15:58
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: have (more) integration tests for DD37 transitions and notifications
Description: We should have more tests to make sure that the implementation and spec are aligned.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7854 [Taler] qtart minor have not tried 2023-06-02 16:22 2023-09-23 15:58
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: strip absolute pathname from stacktraces
Description: When we pre-compile a JS file, we should strip or at least sanitize the absolute path.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7321 [Taler] wallet-core minor have not tried 2022-09-05 15:47 2023-09-23 15:58
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: "pnpm install" complains about unmet peer dependencies
Description: I've temporarily made peer dependency errors non-strict via .npmrc. However, we should still sort out these peer dependency issues:

Here's the log:

 ERR_PNPM_PEER_DEP_ISSUES  Unmet peer dependencies

packages/anastasis-webui
└─┬ eslint-plugin-header 3.1.1
  └── ✕ missing peer eslint@>=7.7.0
Peer dependencies that should be installed:
  eslint@>=7.7.0

packages/taler-wallet-webextension
├─┬ @linaria/react 3.0.0-beta.4
│ └── ✕ missing peer react@>=16
├─┬ @linaria/webpack-loader 3.0.0-beta.4
│ └─┬ @linaria/webpack5-loader 3.0.0-beta.7
│ └── ✕ missing peer webpack@>=5
└─┬ babel-loader 8.2.3
  └── ✕ missing peer webpack@>=2
Peer dependencies that should be installed:
  react@>=16 webpack@>=5.0.0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019209)
sebasjm   
2022-10-10 18:14   
I was not able to reproduce the issue with

$ pnpm --version
7.13.3

and

$ pnpm --version
6.32.24

I have removed the .npmrc file, could you please tell me how to reproduce this? Maybe a special pnpm version?

I think the solution may be adding this to the package.json
{
  ...
  "pnpm": {
    "peerDependencyRules": {
      "ignoreMissing": ["react","webpack"]
    }
  }
}
(0019323)
Florian Dold   
2022-11-01 13:47   
@sebastian: You need to start with an empty repo for this.

Please add the "ignoreMissing" settings where appropriate. I think it's an okay fix.
(0019388)
sebasjm   
2022-11-07 22:17   
After cloning a new repo and building from scratch, still can't reproduce

Full output

$ pnpm --version
7.14.2
$ rm -rf wal2/ ; git clone wallet-core/ wal2; cd wal2; pnpm install
Cloning into 'wal2'...
done.
Scope: all 13 workspace projects
Lockfile is up to date, resolution step is skipped
Packages: +2394
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: /home/sebasjm/.local/share/pnpm/store/v3
  Virtual store is at: node_modules/.pnpm
Progress: resolved 2394, reused 2232, downloaded 0, added 2394, done

devDependencies:
+ @babel/core 7.13.16
+ @linaria/esbuild 3.0.0-beta.23
+ @linaria/shaker 3.0.0-beta.23
+ esbuild 0.15.13
+ nx 15.0.1
+ prettier 2.7.1

packages/idb-bridge prepare$ tsc
└─ Done in 5.5s
packages/pogen prepare$ tsc
└─ Done in 3.5s
packages/taler-util prepare$ tsc
└─ Done in 5.6s
packages/anastasis-core prepare$ tsc
└─ Done in 4.6s
packages/taler-wallet-core prepare$ tsc
└─ Done in 6.2s
packages/anastasis-webui prepare$ pnpm compile
│ > @gnu-taler/anastasis-webui@0.2.99 compile /home/sebasjm/Work/taler/wal2/packages/anastasis-webui
│ > tsc
└─ Done in 7s
packages/taler-wallet-cli prepare$ tsc && rollup -c

│ lib/index.js → dist/taler-wallet-cli.mjs...
│ (!) Circular dependency
│ ../taler-wallet-core/lib/operations/exchanges.js -> ../taler-wallet-core/lib/operations/withdraw.js -> ../taler-wallet-core/lib/o
│ created dist/taler-wallet-cli.mjs in 5.4s
└─ Done in 14.4s
packages/taler-wallet-webextension prepare$ pnpm compile
│ > @gnu-taler/taler-wallet-webextension@0.9.0 compile /home/sebasjm/Work/taler/wal2/packages/taler-wallet-webextension
│ > tsc && ./build-fast-with-linaria.mjs
└─ Done in 18.4s
Done in 36.7s
(0020409)
Florian Dold   
2023-08-03 21:00   
After deleting the lockfile and doing "pnpm install", I'm getting this:

 WARN  Issues with peer dependencies found
packages/merchant-backend-ui
└─┬ @linaria/webpack-loader 3.0.0-beta.22
  └─┬ @linaria/webpack5-loader 3.0.0-beta.23
    └── ✕ unmet peer webpack@^5.0.0: found 4.46.0

packages/merchant-backoffice-ui
└─┬ html-webpack-plugin 5.5.3
  └── ✕ unmet peer webpack@^5.20.0: found 4.46.0

The integrity of 8807 files was checked. This might have caused installation to take longer.
Done in 1m 14.8s


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7115 [Taler] other minor have not tried 2021-11-30 18:01 2023-09-23 15:58
Reporter: ms-mantis Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: survey site lacks "goodbye" page.
Description: The survey site keeps showing the QR code page, even after the wallet has
successfully collected the tip, leaving the visitor a bit doubtfully. Ideally, it
should inform the visitor about the operation's outcome.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6987 [Taler] other feature have not tried 2021-08-07 20:16 2023-09-23 15:58
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wirewatch should use long polling
Description: While not supported yet by libeufin, it might be a good idea for taler-exchange-wirewatch to do long-polling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018110)
Christian Grothoff   
2021-08-12 13:18   
10d8342f..f174781b adds support for longpoll_ms to libtalerbank. fakebank still needs long polling support. Not sure about libeufin...
(0018112)
Christian Grothoff   
2021-08-17 10:05   
Fakebank now has long-polling support.
(0018115)
Christian Grothoff   
2021-08-18 10:22   
Exchange logic should be complete, now it's up to LibEuFin to finish this.
(0019958)
MS   
2023-03-13 11:01   
Implemented at this libeufin.git tag: long-polling-twg.

Sandcastle-Libeufin needs to switch to Postgres, to help testing.
(0020458)
Florian Dold   
2023-08-29 16:24   
Javier: Once the next libeufin-sandbox iteration is out, please update the sandcastle config to use postgres.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7600 [Taler] libeufin (general) minor have not tried 2023-01-18 23:11 2023-09-23 15:57
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Consider reducing 'util' file number.
Description: The Util package grew with >20 files, according to which feature the
function(s) in one file offer(s). However, some function may ambiguously
be appropriate to more than one file, resulting in this fine grained division
not being helpful (and therefore only creating more scaffolding).

On top of that, the files aren't placed under a path that matches their
package definition, with the IDE constantly warning about this.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020137)
Florian Dold   
2023-04-23 23:37   
Is this still relevant?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7715 [Taler] sandcastle (containerized demo deployment) minor have not tried 2023-02-23 00:27 2023-09-23 15:52
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: provide info page / documentation where which APIs are running
Description: Especially with libeufin, it's really difficult to know the right endpoints that are served by demo. We should summarize this somewhere.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6588 [Taler] wallet-core tweak have not tried 2020-09-08 16:48 2023-09-23 15:52
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: wallet-core should support range queries for the transactions list
Description: This might require some additional indices to be faster!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020188)
Florian Dold   
2023-05-07 16:43   
Main thing to discuss here: How do we actually do the pagination? What do we use as the "cursor"?

A transaction ID is not sufficient, as it doesn't efficiently allow querying transactions before or after it. So maybe a timestamp? But what if timestamps are not unique?

Probably the cursor should be a (timestamp, txid) tuple.
(0020271)
sebasjm   
2023-06-06 19:53   
Is even possible to have the same timestamp for two tx since there is no multithread in the wallet?
(0020299)
Florian Dold   
2023-06-21 18:26   
We've decided on an API:

getTransactions({ filterStates, limit}) -> { results, cursor }
=> Start a new paginated query
getTransactions({ cursor, limit}) -> { results, cursor }
=> Get more results (cursor encodes filter as well)

(where limit can be negative/positive to go back/forwards in history)
(0020490)
MarcS   
2023-09-04 19:42   
IMHO we need three groups:
• "done", which might be thousands of transactions over the years if the user doesn’t delete them.
• "waiting" == dialog (the user needs to confirm) plus pending (the other party needs to confirm)
• all others (expired, failed, aborted, aborting, suspended, suspended-aborting). Could be named "uncompleted" or "unsuccessful".

The result (list of transactions) should be sorted chronologically (newest first).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7572 [Taler] deployment and operations feature have not tried 2023-01-12 21:33 2023-09-23 15:51
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: migrate sandcastle containers to use systemd
Description: ... instead of using some shell script as pid 1 inside the container.

This allows nicer logging and restarts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020496)
javier.sepulveda   
2023-09-05 11:17   
Florian as we spoke yesterday, please give a try to this, to see if you come up with feasible idea on how to implement this.

Please check these links, to have some additional information about this:

- https://lwn.net/Articles/676831/ (please also read comments)

- https://www.virtuozzo.com/company/blog/container-types/

- https://earthly.dev/blog/lxc-vs-docker/

- https://canonical.com/blog/lxd-vs-docker

You can also do some research about system containers vs application containers.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7548 [Taler] deployment and operations tweak have not tried 2023-01-02 13:48 2023-09-23 15:51
Reporter: Florian Dold Platform:  
Assigned To: dvn OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: buildbot workers should have one and only one entry point script
Description: Instead of using multi-step recipes in workers, there should be one and only one entry-point script.

This makes it easier to see what's actually going on.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020375)
Christian Grothoff   
2023-07-24 11:55   
dvn: I believe you've already (largely?) addressed this, please confirm and resolve if so.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7684 [Taler] merchant backend API (HTTP specification) feature N/A 2023-02-13 15:14 2023-09-23 15:51
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: report exchange AML issues in merchant REST API
Description: https://docs.taler.net/core/api-merchant.html#get--instances-$INSTANCE-private-kyc should report AML status from
600fc4f645286d30cc8446bec1aac466a27a8ec3 (docs.git); GET /deposits/ endpoint of the exchange.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020044)
Christian Grothoff   
2023-04-10 10:48   
79b2673..837416e updates the spec.
(0020045)
Christian Grothoff   
2023-04-10 10:48   
677ac4a5..090c532b modifies the exchange to return the AML status together with the KYC status.
(0020046)
Christian Grothoff   
2023-04-10 11:19   
31babe5..208dbea modifies the merchant to expose the AML status in its API. Untested!
(0020063)
Christian Grothoff   
2023-04-11 11:01   
ad925cc..feaf7ba adds a test.
(0020064)
Christian Grothoff   
2023-04-11 11:02   
Last step is to add support to the SPA to show a pending/frozen AML state to let the user know why they might not be getting any money ;-). => Assigning to sebasjm.
(0020151)
sebasjm   
2023-04-25 04:46   
fixed 2f8de9ea8..00f108b9d

if (kyc url !== undefined) => kyc (1)
else if (aml === 1) => AML pending (2)
else => AML frozen (3)

text:
1.- Pending KYC process, click here to complete
2.- There is an anti-money laundering process pending complete
3.- The account is frozen due to the anti-money rules. Contact the exchange service provider for instructions.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7721 [Taler] sandcastle (containerized demo deployment) minor have not tried 2023-02-23 23:32 2023-09-23 15:50
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Do not use pip3 with --break-system-packages
Description: Instead we should install what we need as a system package or set up a virtualenv.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7726 [Taler] sandcastle (containerized demo deployment) minor have not tried 2023-02-24 02:08 2023-09-23 15:50
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: sandcastle should run services on unix domain sockets instead of ports
Description: Ingress via HTTP(s) should then be managed by nginx or by a separate ingress container.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7507 [Taler] libeufin-nexus minor have not tried 2022-12-01 16:58 2023-09-23 15:48
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: EBICS management spans two API routes.
Description: Sandbox serves EBICS calls at both "/admin/ebics/*" and "/demobanks/default/ebics/subscribers".

Should all the endpoints be moved into only one route?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020528)
Christian Grothoff   
2023-09-23 15:48   
Are we killing this API entirely with the new design?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6400 [Taler] libeufin-nexus minor have not tried 2020-06-21 14:18 2023-09-23 15:47
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: consider doing faster re-tries for some scheduled operations
Description: When the daily bank statement download fails, should LibEuFin retry before the next scheduled execution?

For most tasks, a faster re-try doesn't make sense though.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6723 [Taler] libeufin-nexus minor have not tried 2021-01-26 14:51 2023-09-23 15:46
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: unify responses format styles
Description: Right now Nexus uses *4* different flavors to respond:

1) JSON for exceptions.
2) Plain text for the fallback route.
3) a empty JSON for *some* successful requests.
4) plain text for some other successful requests.

Those should be unified under two JSONs formats: one for errors, and one for 200 OK responses.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020148)
MS   
2023-04-24 22:40   
(Last edited: 2023-04-24 22:41)
libeufin-keyrotation now breaks because of the format Nexus responds to "/fetch-transactions". The failing check is now commented out (see FIXME in the source file), and should be enabled after this bug gets fixed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7592 [Taler] documentation text have not tried 2023-01-15 20:30 2023-09-23 15:45
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: libeufin-sandbox implementation of Taler Bank Access API may omit HTTP status codes.
Description: Research about which HTTP status codes should appear in the spec.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7681 [Taler] sandcastle (containerized demo deployment) feature have not tried 2023-02-12 20:46 2023-09-23 15:45
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: demo doesn't have any KYC checks
Description: The demo should support those to demonstrate KYC.

Maybe with a second exchange?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020198)
Christian Grothoff   
2023-05-21 21:42   
Marc has been asking for a 2nd KUDOS exchange with different fees. Sounds like a good target for this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6439 [Taler] wallet-core feature N/A 2020-07-24 12:09 2023-09-23 15:06
Reporter: Christian Grothoff Platform: i7  
Assigned To: avalos OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should support Anastasis
Description: This is kind-of a meta-bug, as it is about both wallet-core support and support in the various wallet user interfaces.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7799 [Taler] wallet-core feature always 2023-04-11 16:04 2023-09-23 15:03
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: implement DD48-style exchange entry management in wallet-core
Description: This allows wallet-core to be more lazy with downloading exchange /keys

Downloading and validating the /keys response is resource-hungry when we have many built-in exchanges.

Also, it makes network requests without direct user interaction, see https://gitlab.com/fdroid/fdroiddata/-/issues/2964
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7551 [Taler] wallet-core minor have not tried 2023-01-05 17:23 2023-09-23 15:03
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: need test(s) to ensure that wallet DB schema is backwards-compatible or properly migrated
Description: Right now, it's too easy to introduce breaking changes without noticing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020365)
Florian Dold   
2023-07-24 10:52   
Before we can meaningfully add tests here, I want to make some (backwards-compatible) adjustments to the DB value serialization format ("structured serialization for storage"). This will be done as part of the sqlite3 DB backend work.
(0020443)
Florian Dold   
2023-08-25 14:19   
Sqlite3 backend is now done and merged, but I still want to do some changes to the DB that'll simplify some code (unify status code ranges for operations, always use same currency format, coin selection data structure, ...).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7300 [Taler] bank API (C) tweak always 2022-08-16 10:03 2023-09-23 15:02
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: immediate OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Taler bank access API does not follow conventions
Description: https://docs.taler.net/core/api-bank-access.html has camelCase in field names while we use only snail_style in the rest of our APIs.
Furthermore, a date is listed as a string using "// YYYY-MM-DD ending with 'Z'" for the format, which is NOT the date format we use in Taler. And the /config endpoint for API versioning is absent :-(.

Changing this will require coordinated changes to fakebank, libeufin, and cashier.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019134)
MS   
2022-09-15 09:27   
As privately discussed, /config now responds at: /demobanks/default/integration-api/config
(0019557)
grote   
2023-01-03 15:31   
Latest cashier is using this strange URL now. Not sure what else is left here to do.
(0019723)
grote   
2023-01-31 18:59   
Is there anything left to do for this ticket?
(0019734)
Christian Grothoff   
2023-02-02 00:23   
I still see camel-case: "accountLabel" and "publicAccounts" and "paytoUri" in the API specs (and more further down). So clearly the camelCase has not been addressed yet. And there is also still "date: string; // milliseconds since the Unix epoch", which isn't _exactly_ how we usually do dates in our API.
(0020484)
Christian Grothoff   
2023-09-03 15:38   
docs.git:: 898e0199..8df41796 fixes the *specification* to address this issue, but NOT libeufin. Marcello: please fix libeufin ASAP.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7473 [Taler] wallet (Android App) minor always 2022-11-17 18:20 2023-09-23 15:00
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: The app should navigate to the article after payment: (I need manually go back)
Description: Current behavior:
1.- open shop.test.taler.net on mobile browser
2.- go to an article
3.- pay it with wallet

expected: the user wanted to see the article
behavior: the user is redirected to the transaction list

proposal:
 * redirect the user to the article (which webex does but controversial)
 * show the the transaction details with a clear indication of the fulfillment url (it should be obvious that this is the next step that the user need to take)

worth mention that this issues was reported by email and there is a video that explain the situation
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019435)
grote   
2022-11-17 18:33   
I am not sure I understand. The quoted text says "we shouldn't auto-navigate here at all", but you want to auto-navigate after payment?
(0019438)
sebasjm   
2022-11-17 20:03   
The comment is describing a scenario when the QR code is scanned from the android wallet but the article is going to be read in the desktop.

So, from the desktop:
 - go the shop
 - try to read an article
 - the qr code is shown
 - pay it with the mobile wallet
 - after being paid the wallet should show the tx is completed
 - the shop in the desktop browser should detect that the order has been pay and render the article

Here the article is not shown in the mobile browser.

Alternative scenario is when the article is being accessed from the mobile browser, pay and the the wallet should redirect again to the article.
(0019440)
grote   
2022-11-17 20:41   
So you want after all payments that the Android wallet opens the fullfillment Uri without asking?
(0019443)
sebasjm   
2022-11-18 16:37   
You mean like "you are going to be redirected to" type of question?

Maybe, I'm not sure. In the first scenario (when the redirect needs to be made, reading from mobile and paying with the same device) the user is coming FROM the article to the wallet to pay. It sounds reasonable that the user will want to go back to the article and the fulfillment url will redirect the user to that.
(0019583)
grote   
2023-01-05 21:27   
OK, but how do we reliably detect that the user is coming from an article they want to go back to? On Android, we don't get informed by the browser where the user is coming from, so we only see the taler:// Uri. Maybe there's something in that Uri that indicates the desire to auto-go-back to fulfillment?

Btw. a feature like this could have security implications as you can force the user to visit a certain site.
(0019593)
Christian Grothoff   
2023-01-06 14:58   
I see. Yes, I guess we should add an argument to the taler://-URI that tells the mobile phone that it scanned a QR code on an 'external' system and thus should not navigate back itself. Something like "?nav=yes" would do, right? The QR code is where we need things to be compact, so there I would leave it out. I think the merchant can easily be modified to append such an argument when offering a link for clicking.

All agree?
(0019605)
sebasjm   
2023-01-07 14:59   
I prefer not to add an extra parameter in QR more, there should be a default behavior that cover both use cases in a good enough experience.

My suggestion:
 * after payment is done we add a successful payment screen with
  -- "ok" button (go back to the wallet)
  -- "close" (close the wallet)
  -- "continue to" (follow the fulfillment url)

That I think solve what grote raise as security issue (we are not redirecting without user consent)
Also, in the use-desktop-pay-with-mobile scenario the user will see the successful screen, the browser will reload showing the article, and can use the "close" button (since the wallet is just being summoned for the payment)
If the scenario is navigating-with-mobile-and-payment, the "continue to" button or link will redirect to the article using the fulfillment url

The "ok" button there if the user want to check balance before closing.

What about that? (main idea: convention over configuration)
(0019606)
Christian Grothoff   
2023-01-07 17:24   
Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error. So telling the wallet that the payment is for an article on another device (media-break) is an important hint to drive the right UX.

I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-).

Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile. Here, we'll need to open the browser, the browser will trigger the wallet, and then the wallet's repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser.

Still, with my extra taler://-URI argument, all of this is possible and we don't show the user 'strange' paths that don't work.
(0019607)
sebasjm   
2023-01-07 22:35   
> Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error.
Well, this is bad.
AFAIK the merchant front-office has a volatile session that is used to bound the payment with the article, if that session is lost the user will need to pay again?

If I ever payed for an article I would like to go back again even if I lost the session, isn't? That would mean that fulfillment URL should work in any setup. Like carrying the orderId and a prove of ownership in the request params (session-less)

> Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile.
This seems equal to the "continue to" plus a delay before clicking.

> I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-)

Sending a user to another app or external site (other than the wallet) should be warned.
Merchant input should be considered untrusted from the wallet perspective and this lead to open-redirect issues
https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

> repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser
I don't have very clear how the repurchase work. Is this some missing feature what you are describing?
(0019608)
Christian Grothoff   
2023-01-07 23:01   
Repurchase detection is exactly the feature you are looking for, and is implemented. Basically, if you did already pay for an article, but in a different session, you are first asked to pay again. But once you try, the wallet detects that you did already pay before, and simply proves to the merchant that you paid before, and asks the merchant to change the session ID on the purchase to the current session. BUT what this means is that if the user switches devices, they will get asked to pay again first, and have to scan the QR code with the wallet (or see some jumping around if the browser can auto-trigger the wallet) to allow the wallet to see the repurchase and rebind the session.
(0020025)
Florian Dold   
2023-04-05 17:35   
I don't think that Christian's approach can work. How would the merchant decide whether it is a "media break" or not?
When I click on an article in the blog demo, the merchant doesn't know whether I'm gonna pay with the browser wallet or the phone wallet.

I'm proposing a different user experience: When going to the fulfillment URL, the merchant checks if there is a session mismatch.
If the session matches, the article is rendered.
On a mismatch, it offers to instead view the article in this browser. It then shows the QR code page.

That's one more step, but it IMHO makes the user experience much clearer.

And maybe the wallet can also add additional information to the fulfillment URL to make clear that this is a repurchase.

IMHO we need to go back to the drawing board for the blog shop article, because it's currently both horribly complicated *and* not fully working.
(0020339)
sebasjm   
2023-07-05 15:17   
I have updated the description and since the original video was reported to android, I moving this issue to android but it should also be considered for iOS
(0020346)
MarcS   
2023-07-08 13:28   
iOS has the same problem as Android: it cannot detect whether the user tapped on a link in Mobile Safari (on the phone) or used the built-in camera app (not its own Scan QR Dialog) to scan the QR code and pass the decoded link to the app. In both cases, the app only gets a taler:// URI to open.
Only if the user taps the app's own Scan QR button it is clear that the user is scanning another device, and wouldn't want to open the fullfillment URI on the iPhone after payment.

However, if the user tapped the link on the phone to switch from Safari to our app, then iOS itself shows a very small button in the top left corner reading "Safari", which brings the user right back to the web page where the link was tapped. And every iOS user knows this...

Thus, this is a non-issue for iOS. Either the fullfillment is on another device, or the user can tap the small "Safari" button in the top left corner to go back to the merchant website where the payment link originated.
(0020347)
MarcS   
2023-07-08 13:39   
I had my 15year old nephew here last week to try the iOS app for the very first time. He had absolutely no problems switching between
a) bank and wallet app after having solved the math puzzle on the bank website
and b) wallet app and shop after payment finished. He saw that the payment sheet vanished and the balance updated, and immediately switched to the shop to notice he could now read the paid article.

So I won't show a fulfillment button on iOS - it's not necessary. Users know how to switch back to the browser where they started the payment process.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7677 [Taler] wallet-core minor have not tried 2023-02-11 14:39 2023-09-15 21:16
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: consider having a recovery mode for the wallet
Description: Original suggestion by Sebastian in 0007609.

For me, the reason to have a recovery mode is that instead of the wallet saying "oops, I can't start" and the user not being able to do *anything*, we allow the user some very limited functionality (such as exporting the DB and error diagnostics). Or maybe first doing some export and then deleting offending records, etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7940 [Taler] merchant backoffice SPA minor always 2023-09-14 21:32 2023-09-14 21:32
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: template when fixed summary is set to empty string it should remove the fixed property
Description: actually is setting the empty string as fixed summary so the summary remains fixed
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7939 [Taler] merchant frontend (blog) major always 2023-09-14 21:21 2023-09-14 21:21
Reporter: davidak Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: refund of article fails
Description: Error encountered
Item not refundable (anymore)

Backend response:

{'wire_reports': [], 'exchange_code': 0, 'exchange_http_status': 0, 'exchange_ec': 0, 'exchange_hc': 0, 'deposit_total': 'KUDOS:0', 'contract_terms': {'amount': 'KUDOS:0.5', 'extra': {'article_name': 'The_Problems_with_older_versions_of_the_Apple_Public_Source_License_-APSL-'}, 'fulfillment_url': 'https://shop.demo.taler.net/en/essay/The_Problems_with_older_versions_of_the_Apple_Public_Source_License_-APSL-', 'public_reorder_url': 'https://shop.demo.taler.net/en/essay/The_Problems_with_older_versions_of_the_Apple_Public_Source_License_-APSL-', 'summary': 'Essay: The Problems with older versions of the Apple Public Source License (APSL)', 'wire_transfer_deadline': {'t_s': 1694717108}, 'products': [], 'h_wire': 'TNZNZM4NSTGEJWPSMV8D00R8S5B6TMBKKHAWP956RTQB0KA3TAP99CWB5JGMVJJNPDK7T812VWPFHR2P3DWCZMPZQDDQSSG3MHWEQH8', 'wire_method': 'iban', 'order_id': '2023.257-0147QNSQMAYYP', 'timestamp': {'t_s': 1694716658}, 'refund_deadline': {'t_s': 1694716778}, 'pay_deadline': {'t_s': 1694720258}, 'max_wire_fee': 'KUDOS:1', 'max_fee': 'KUDOS:1', 'wire_fee_amortization': 1, 'merchant_base_url': 'https://backend.demo.taler.net/instances/blog/', 'merchant': {'name': 'GNU Taler', 'address': {}, 'jurisdiction': {}}, 'merchant_pub': 'F59GRTB78ZAX0AS77WMQWFSDKT0Z4ST5GVA86ZN9JS8DY39PXKXG', 'exchanges': [{'url': 'https://exchange.demo.taler.net/', 'priority': 1024, 'master_pub': '1SQ43RNRCB80YH58YYEH8KQKXMZNEMPA2J2CZSQN4XSWJZ40675G'}], 'nonce': 'AKH4ECWVVRNXQ9RKA1JCNQZQPHEJ8VB7RQ5ND96QN6MAN19694WG'}, 'order_status': 'paid', 'refunded': False, 'wired': False, 'refund_pending': False, 'refund_amount': 'KUDOS:0', 'wire_details': [], 'refund_details': [], 'order_status_url': 'https://backend.demo.taler.net/instances/blog/orders/2023.257-0147QNSQMAYYP?session_id=f2fa84b8-71af-4988-ad5a-02f8e1aaa040&h_contract=R0NF5B8W89383106KXRNZ2MMGC4636MD1KCSJYZ3WZGR06T3WQ083ZK1HHTMC0V7FC3WQTY9E9P93H4YGV6F9KX209AVQWFWCTD6DCG'}
Tags:
Steps To Reproduce: 1. buy essay in demo store
2. click refund
3. the refund fails

when i open the article again, it says:

Taler allows merchants to offer refunds to customers. This article can't be refunded anymore.

---

i tried it again with another article:

same steps. but the error looks different (see second screenshot)

Digital cash refund
Could not load the status of the term of service

Wallet operation "startRefundQueryForUri" failed
  
less info
{
  "context": [],
  "cause": {
    "details": {
      "code": 7001,
      "when": {
        "t_ms": 1694718914655
      },
      "hint": "unexpected exception (message: no purchase found, can't refund)",
      "stack": "Error: no purchase found, can't refund\n at chrome-extension://millncjiddlpgdmkklmhfadpacifaonc/dist/background.js:26437:13\n at Generator.next (<anonymous>)\n at fulfilled (chrome-extension://millncjiddlpgdmkklmhfadpacifaonc/dist/background.js:48:24)"
    }
  }
}

the article page says it got refunded, but i did not get the money back

GIVE ME MY MONEY BACK!!! (*angry customer noise*)
Additional Information: the error message is not very useful for the average user
Attached Files: Screenshot from 2023-09-14 21-13-23.png (115,027 bytes) 2023-09-14 21:21
https://bugs.gnunet.org/file_download.php?file_id=1397&type=bug
Screenshot from 2023-09-14 21-16-23.png (92,708 bytes) 2023-09-14 21:21
https://bugs.gnunet.org/file_download.php?file_id=1398&type=bug
Screenshot from 2023-09-14 21-17-38.png (108,884 bytes) 2023-09-14 21:21
https://bugs.gnunet.org/file_download.php?file_id=1399&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7938 [Taler] merchant frontend (blog) minor have not tried 2023-09-14 21:11 2023-09-14 21:11
Reporter: davidak Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: refund button not readable
Description: light gray on white is not readable

Tags:
Steps To Reproduce: 1. buy article in essay shop https://shop.demo.taler.net/en/
2. click refund at the bottom
3. see button with unreadable text

(my browser uses dark mode by default)
Additional Information: maybe create new design and UI for the demos that look professionally like the company page? consider accessibility and UX from the start, so such issues don't happen
Attached Files: Screenshot from 2023-09-14 20-39-32.png (137,797 bytes) 2023-09-14 21:11
https://bugs.gnunet.org/file_download.php?file_id=1396&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7937 [Taler] wallet-core feature always 2023-09-14 15:11 2023-09-14 16:43
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should be able to convert lower denom coins into high denom coins
Description: in an acceptable exchange smaller coins have higher relative fee than big denoms
this will impact the user after some time: it will perceive higher fees

some things to consider to make the scenario less probable:
 * since fee is in the order of cents, reducing the tx fee for the customer makes this scenario less probable (STEFAN curves)
 * if the merchant accepts to pay some fee then the wallet has a margin to use smaller coins

Still, using the wallet for a long period will lead to small coins due to random prices and change.

what the wallet could do is send all the fresh-and-small coins to the exchange for the exact amount of a bigger coin and receive one new fresh coin.

this operation:
 * is not something interesting for the customer (no need to show as a tx)
 * should trigger automatically (maybe before doing a payment)
 * is naturally limited, it can't be done indefinitely many time since is always converting from lower to higher denoms and converge to the highest denom (it can be potentially for free)



Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020511)
Christian Grothoff   
2023-09-14 15:17   
I disagree, this should not be necessary if the coin does reasonable coin selection on payments.
(0020512)
Christian Grothoff   
2023-09-14 15:18   
Furthermore, it is dangerous as it may create (even accidentally!) a link between transactions.
(0020513)
sebasjm   
2023-09-14 16:36   
* exchange: denoms $1 and $0.1 , all fee zero except deposit fee 0.01
 * wallet withdraws 9 coins of $1
 * merchant sells at $0.9

 * after buying 9 times, the wallet will have `$0.1 * 9` coins
 * the 10th payment will cost 10% in fee instead of 1%
(0020514)
Christian Grothoff   
2023-09-14 16:43   
Only because of the *extreme* denomination structure of demo. Try the same with the canonical binary distribution of denominations.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5953 [Taler] libeufin (general) minor have not tried 2019-10-29 10:08 2023-09-05 13:12
Reporter: Florian Dold Platform:  
Assigned To: dvn OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: generate code documentation with Dokka
Description: See https://kotlinlang.org/docs/reference/kotlin-doc.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020499)
Christian Grothoff   
2023-09-05 13:12   
I believe Dokka is a tool like doxygen or JavaDoc to convert existing source code annotations into HTML. So this is really about installing the tool (possibly inside some CI/CD) and then setting up some folder / subdomain / location where we render the HTML. I guess we can put this on dvn first for the CI/CD part.
Devan: low-priority...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7935 [Taler] wallet-core minor have not tried 2023-09-05 12:11 2023-09-05 12:11
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: make sure refresh transactions refresh remaining amount if requested amount is not available anymore
Description: When a refresh transaction tries to, say, refresh coin1 for KUDOS:2 and coin2 for KUDOS:1.5, but the coins only have KUDOS:1 and KUDOS:1 left respectively, the wallet should still do the refresh with the "lowered" amount.

We don't have a test for this yet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7839 [Taler] libeufin (general) minor have not tried 2023-05-09 16:37 2023-09-05 11:48
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: CLI installation should check dependencies
Description: Following is one example where the CLI misses python3-click and the installation didn't detect it beforehand.

$ libeufin-cli sandbox --sandbox-url "${SANDBOX_URL}" demobank register
Traceback (most recent call last):
  File "/home/taler/bin/libeufin-cli", line 5, in <module>
    import click
ModuleNotFoundError: No module named 'click'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7827 [Taler] libeufin-bank minor have not tried 2023-04-27 14:57 2023-09-05 11:47
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Refund invalid attempts of withdrawing the regional currency.
Description: Incoming payments to the association's fiat bank account are expected to have a valid reserve public key. The conversion service for now ignores invalid payments, letting them stay in the association's fiat bank account. Such payments should instead be refunded to the original sender.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7925 [Taler] merchant backoffice SPA minor always 2023-08-24 20:11 2023-09-05 11:40
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: add support for x-talerbank
Description: 1) The SPA doesn't like x-taler-bank payto:// URIs. You should probably
add support.


should support x-taler-bank and iban methods

error msg should be
"The method `$METHOD` returned in payto://-URI by server is not supported."
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7899 [Taler] libeufin-nexus minor always 2023-08-03 00:13 2023-09-05 11:39
Reporter: Windfisch Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: libeufin longpolling does not work (never returns early)
Description: Hi,

i just stumbled about a problem that causes delays of up to a minute when withdrawing money into the wallet: The long-polling support in libeufin-nexus does not work: It does not return early on change, but always waits for the full waittime.

The symptoms look like this: in taler-exchange-wirewatch logs, I see lines like these:

2023-08-02T21:42:25.732836+0000 taler-exchange-wirewatch-958 INFO Requesting credit history at `http://libeufin_nexus:5017/facades/taler-facade/taler-wire-gateway/history/incoming?delta=1012&start=12&long_poll_ms=60000'
2023-08-02T21:43:25.793958+0000 taler-exchange-wirewatch-958 INFO Requesting credit history at `http://libeufin_nexus:5017/facades/taler-facade/taler-wire-gateway/history/incoming?delta=1012&start=12&long_poll_ms=60000'
2023-08-02T21:44:25.907327+0000 taler-exchange-wirewatch-958 INFO Requesting credit history at `http://libeufin_nexus:5017/facades/taler-facade/taler-wire-gateway/history/incoming?delta=1011&start=13&long_poll_ms=60000'
2023-08-02T21:44:25.950741+0000 taler-exchange-wirewatch-958 INFO Requesting credit history at `http://libeufin_nexus:5017/facades/taler-facade/taler-wire-gateway/history/incoming?delta=1010&start=14&long_poll_ms=60000'
2023-08-02T21:45:26.020468+0000 taler-exchange-wirewatch-958 INFO Requesting credit history at `http://libeufin_nexus:5017/facades/taler-facade/taler-wire-gateway/history/incoming?delta=1010&start=14&long_poll_ms=60000'

You can see that the minute is steadily increasing, but the seconds part always stays the same, despite me doing transactions at random points in time.

Setting the -f, --longpoll-timeout=DELAY option on taler-exchange-wirewatch to 1 second improves the delay, so i suspect this is a problem in nexus (or maybe the libeufin demobank behind)

The long-polling in taler-exchange-http appears fine, see logs below.
Tags:
Steps To Reproduce: Run the setup at https://github.com/Windfisch/taler-podman, but remove the --longpoll-timeout option in taler-exchange-insecure/entrypoint.sh. (This will be online as of 2023-08-03 17:00 CEST, haven't pushed it yet)

Make a couple of withdrawals and note how takes up to a minute for the coins to arrive in the wallet.

Note how it's always the same second they arrive.
Additional Information:
Attached Files: libeufin-nexus.txt (4,700 bytes) 2023-08-03 00:14
https://bugs.gnunet.org/file_download.php?file_id=1390&type=bug
libeufin-sandbox.txt (4,700 bytes) 2023-08-03 00:14
https://bugs.gnunet.org/file_download.php?file_id=1391&type=bug
taler-exchange-httpd.txt (4,850 bytes) 2023-08-03 00:14
https://bugs.gnunet.org/file_download.php?file_id=1392&type=bug
taler-exchange-wirewatch.txt (16,388 bytes) 2023-08-03 00:14
https://bugs.gnunet.org/file_download.php?file_id=1393&type=bug
Notes
(0020399)
Windfisch   
2023-08-03 00:14   
logs


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7707 [Taler] wallet-core minor have not tried 2023-02-19 18:02 2023-09-05 05:15
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should not allow certain operations if offline
Description: When the wallet notices that the device does not have internet connectivity, certain operations (say, starting a peer push payment) should not be allowed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020492)
avalos   
2023-09-05 05:15   
Ideally, we should have a proper error code for this, so that the app can render it nicely.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7174 [Taler] other text have not tried 2022-02-10 20:57 2023-09-04 02:58
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: document conventions for HTTP Content-Type, consider allowing (or requiring?) document type versioning
Description: Most Taler services don't consistently enforce checks for the Content-Type header value. We just tend to assume that it's JSON.

We probably want to be more strict with this.

Generally, "application/json" should be appropriate, but doesn't allow versioning.

We could consider always requiring the following Content-Type header (and also consistently using it in the content negotiation for other requests):

  application/vnd.taler.$SERVICE+json;version=$CURRENT_VERSION"

The MIME type follows RFC 6839 (https://datatracker.ietf.org/doc/html/rfc6839).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018704)
Christian Grothoff   
2022-02-19 22:03   
I've filed an application for application/vnd.gnu.taler.exchange and application/vnd.gnu.taler.merchant with IANA at
https://www.iana.org/form/media-types -- let's see what they say.
(0018720)
ttn   
2022-02-25 09:23   
Where would such documentation live?
(0018754)
Christian Grothoff   
2022-03-01 00:23   
We've now registered the media types:
http://www.iana.org/assignments/media-types

ttn: I think the documentation for them should probably go into core/api-common.rst, as this is something across REST API calls.
(0018759)
ttn   
2022-03-01 19:02   
@Christian Grothoff
IIUC the new types have required parameter "version".
To properly document this, i need to understand:
- What happens when that parameter is omitted?
- What happens when "version" is "too high" or "too low" (two different cases)?
- I assume that the vnd.gnu.taler.exchange is for communication w/ Exchange,
  while vnd.gnu.taler.merchant is for Merchant. Is that correct? Are there
  situations where both need to be involved at the same time?

I'm happy to look at source code if you have a pointer handy.
(0018760)
Christian Grothoff   
2022-03-01 20:07   
Omitted: should be 400 Bad request.
Wrong range: I'd go for 501 Not implemented.
Yes, either merchant or exchange, never both. We may in the future request additional types for the auditor, sync and Anastasis.

Oh, and this is NOT implemented, we document -first- and then implement usually. So please document it, and then this bug should remain open until it is implemented!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7932 [Anastasis] General feature always 2023-09-03 23:21 2023-09-03 23:21
Reporter: avalos Platform: Intel  
Assigned To: OS: Parabola GNU/Linux  
Priority: normal OS Version: N/A  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Feature to regenerate unpaid Taler orders
Description: I partially paid an Anastasis backup (using anastasis-gtk) that consisted of three Taler orders. I paid two of them successfully, but when I paid the third, I got an “insufficient balance” error. I had enough KUDOS, but maybe they were expired, so I reset the wallet database, withdrew more KUDOS from the bank, and tried to pay again, but the order had been claimed by the deleted wallet, so it was now impossible to pay it, thus making it impossible to finish the backup. The money already paid went to waste.

For situations like this, we should have a mechanism in Anastasis to regenerate specific orders of a backup.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7755 [libmicrohttpd] digest authentication (HTTP) major always 2023-03-08 10:13 2023-09-03 19:16
Reporter: akermen Platform:  
Assigned To: Christian Grothoff OS:  
Priority: urgent OS Version:  
Status: confirmed Product Version: 0.9.72  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Digest authentication nonce uniqueness
Description: Digest authentication is working for simple requests bu fails for requests sent concurrently (almost all of if requests are send within a second).

The issue appears to be “nonce” value of the authentication header being not unqiue for each (independent) request. This behavior seems to be not compliant with RFC2617 https://datatracker.ietf.org/doc/html/rfc2617#section-3.2.1 and RFC7616 https://datatracker.ietf.org/doc/html/rfc7616#section-3.2 both state “nonce" values should be uniquely generated each time a 401 response is made while the values generated by libmicrohttpd are only unique for each second (by the “MHD_monotonic_sec_counter" function).

Digest authentication implementation for popular frameworks (for Flask from https://flask-httpauth.readthedocs.io/en/latest, for Node.js from https://www.npmjs.com/package/http-auth, for httbin from https://hub.docker.com/r/kennethreitz/httpbin) they all seem to produce unique “nonce” values and handle concurrent requests without any issue.

This issue report is follow up from the mailing list thread "https://lists.gnu.org/archive/html/libmicrohttpd/2022-01/msg00000.html".

Tags:
Steps To Reproduce: Follow the steps at the "https://github.com/akermen/digest-nonce-test" repository that was specifically created for reproducing this issue.
Additional Information: To make values unique, I experimented with basic "mutex wrapped counter mechanism" which appears to working for very limited test scope, but not sure about performance and effect on other parts of the library:

/* global scope */
static int make_digest_unique = 1;
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

/* at "MHD_queue_auth_fail_response" function */
/*…*/
pthread_mutex_lock(&mutex);
make_digest_unique = make_digest_unique + 1;
pthread_mutex_unlock(&mutex);
/*…*/
calculate_nonce ((uint32_t) MHD_monotonic_sec_counter() + make_digest_unique,
    connection->method,
    connection->daemon->digest_auth_random,
    connection->daemon->digest_auth_rand_size,
    connection->url,
    realm,
    nonce);
/*…*/
Attached Files:
Notes
(0020470)
Christian Grothoff   
2023-09-03 00:42   
I see the code is now exclusively using monotonic_msec_counter(), which is better, but not good enough IMO as it would seem to be monotonic but not *strictly* monotonic. Evgeny: I think we should introduce a MHD_strictly_monotonic_msec_counter(), internally there ensure that each value returned is larger than the previous (and possibly guard with a lock or use an atomic increment-and-return instruction) and use that strictly monotonic version for nonce computations. WDYT?
(0020474)
Karlson2k   
2023-09-03 09:58   
This bug was the main reason for major rewrite of MHD authentication framework.
The new version, which is currently in git master, should not have such bug.

The new implementation uses several techniques:
* by default (MHD_OPTION_DIGEST_AUTH_NONCE_BIND_TYPE is MHD_DAUTH_BIND_NONCE_NONE) client's address (the IP + port) is used together with monotonic_msec_counter() and other values to avoid clashes of generated nonces. Also realm is used for nonce generation.
* if the new nonce is already in the list of generated nonces (or has conflict with another generated nonce in the same slot and another nonce is not yet expired) then weak random number is used to apply some small negative shift in the timestamp to generate new unique nonce.
It is not ideal, but thinks to "retry" mechanism should work even if client is non-IP and for the client generating two requests on the same TCP/IP connection within a single millisecond for the same realm. The better solution would be a proper implementation of weak and strong random generators in MHD, which is already partially implemented in my private branches.
See code for calculate_add_nonce_with_retry() and calculate_nonce().

A special test test_digestauth_concurrent was added in testcurl to check for this bug.
(0020475)
Karlson2k   
2023-09-03 09:59   
(Last edited: 2023-09-03 09:59)
If I not missed something, everything should work fine and the bug could be closed.
(0020479)
Christian Grothoff   
2023-09-03 11:47   
We now keep a list of generated nonces!??? That seems very inefficient. And like we need to hold a lock for an undue long time. What would suffice is a strong PRNG once (and we could have the application pass such a seed value into our initialization) and then a strictly monotonic counter. That way, we'd not even need the current time *or* a list of previously used nonces. Just NONCE=HKDF(seed, ctr++). HKDF could be done trivially re-using the existing hash function logic.
(0020489)
Karlson2k   
2023-09-03 19:16   
We keep generated nonces in hashed list. It is not possible to check for "nonce counter" ('nc') reuse without it. It was the same for the long time.
The list is locked just for update, which is quick, no lock held for any long time.

Monotonic counter is definitely possible now, with git master implementation with default settings. The current version with MHD_OPTION_DIGEST_AUTH_NONCE_BIND_TYPE set to anything except MHD_DAUTH_BIND_NONCE_NONE and the old version (behave like MHD_DAUTH_BIND_NONCE_URI) require nonce to be reproducible, so monotonic counter could not be used in such cases.

In new version we should implement atomic variables with increment and decrement and with implementation by native atomic or fallback to non-atomic variable + lock.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7931 [Taler] wallet (iOS App) minor have not tried 2023-09-03 18:29 2023-09-03 18:30
Reporter: MarcS Platform:  
Assigned To: MarcS OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: offline indicator
Description: Let the user know that the wallet is offline if an operation failed because of connection error.
Tags:
Steps To Reproduce:
Additional Information: This is possible after we implemented Native Networking. At the moment, the iOS UI has no idea whether wallet-core is online or not. And IMHO it doesn’t make sense that wallet-core tries to implement this, since it just won’t get the data from iOS when using socket-based networking.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6120 [Taler] libeufin (general) minor have not tried 2020-03-09 16:44 2023-09-03 18:24
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Incapsulate marshall/unmarshall exceptions inside UtilError
Description: Right now Nexus and Sandbox code must explicitly install a exception handler for marshall/unmarshall errors, making the code more verbose. Ideally, the util layer should hide such details and just raise a UtilError().
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015900)
Marcello Stanisci   
2020-05-15 18:17   
Confirming that this is STILL open!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6085 [Taler] libeufin-nexus minor have not tried 2020-02-10 12:52 2023-09-03 18:24
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: abstract out ebics version
Description: The util library probably should not "leak" the version of the EBICS protocol we're using to the nexus and the sandbox. We should abstract out the details of EBICS 2.5 and EBICS 3 into data structures describing their content in a version-independent way that does not expose the underlying XML too much.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015337)
Marcello Stanisci   
2020-02-10 19:02   
Could you point to the function / class that causes this?
(0015338)
Florian Dold   
2020-02-10 19:03   
Let's discuss this tomorrow in person, after I've committed my rather large change.
(0015906)
Marcello Stanisci   
2020-05-15 18:37   
Still pending.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5972 [Taler] libeufin-nexus minor have not tried 2019-11-18 19:28 2023-09-03 18:23
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Avoid sending signed data before key exchange
Description: The Nexus should check if their keys were accepted by the bank (via INI / HIA) before performing any operation using those.

This is useful because some banks may simply respond "signature invalid" without telling what the real cause is.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015917)
Marcello Stanisci   
2020-05-15 19:19   
This happens here (1) for example, where the 'makeEbicsHpbRequest()' function just
makes the message without checking the state of the key used to sign the message.

But possibly, this is not a real problem. If errors are nicely reported, then the user
will be correctly warned about the impossibility of the attempted operation.

[1] https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/Main.kt?id=4f0af79c3cde2b71f8a3607d5310aaf375d011eb#n87
(0020067)
MS   
2023-04-11 11:14   
(Last edited: 2023-04-11 11:22)
This can be closed after testing how Postfinance reacts to such scenario,
but using keys that were never shared with the bank should be avoided.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6080 [Taler] libeufin-nexus minor have not tried 2020-02-06 15:28 2023-09-03 18:23
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: understand format of pain.002
Description: The pain.002 is the bank's way of telling us the result (error/success) of submitting a pain.002 message, and we should understand the content of it.

One possible way to do this is by playing around with the GLS client (making a payment, then requesting the payment status).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015905)
Marcello Stanisci   
2020-05-15 18:36   
This got slowed down because GLS does not respond to the EBICS CRZ message type.
The issue was reported already to the GLS responsible department.
(0020369)
Christian Grothoff   
2023-07-24 11:41   
Does the PostFinance API/sandbox help here? Just wondering... Ok to move to 0.9.4, of course.
(0020376)
MS   
2023-07-24 12:22   
It does.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6122 [Taler] libeufin-nexus minor have not tried 2020-03-10 15:13 2023-09-03 18:23
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: EBICS error responses should be correctly parsed.
Description: The current Nexus responds with a "invalid XML" message whenever the bank gives it a EBICS error response. Such message is wrong, and should be adapted to reflect what happens.

The real responsible is the util module, where the actual parsing happens, therefore this one should be adapted to tolerate EBICS error responses. One example is the function: "parseAndDecryptEbicsKeyManagementResponse()"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015911)
Marcello Stanisci   
2020-05-15 19:05   
It doesn't look like that applies anymore, but I would defer solving this to when
we will be testing faulty requests along the integration tests.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7662 [Taler] libeufin-bank minor always 2023-02-07 15:34 2023-09-03 18:21
Reporter: sebasjm Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: error does not provide the field where the validation is made
Description: Some validation show the field where the error is, but for the username looks like not. It will be nice to have the some kind of error that help fixing the problem.

Also, I couldn't find documentation of this validations.

curl 'https://sandbox-libeufin.taler.ar/demobanks/default/circuit-api/accounts' -d '{"username":"1","password":"1","name":"the name","contact_data": {},"cashout_address":"payto://iban/DE123123"}' -v

  "error" : {
    "type" : "util-error",
    "description" : "Invalid resource name. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit."
  }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6696 [Taler] documentation text have not tried 2021-01-13 23:50 2023-09-03 18:18
Reporter: Florian Dold Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: discuss better structure for LibEuFin docs
Description: The LibEuFin docs are currently pretty chaotic. We should come up with a better structure.

I guess there are three different target audiences for the docs:
* Operators of LibEuFin (who want to use it with Taler)
* Developers who want to use the LibEuFin API
* Core Developers of LibEuFin ("internal stuff, documented in public")
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017449)
ttn   
2021-01-29 19:42   
Well, the HOWTO (tutorial) is clearly targeted at the Operator audience. I don't know what the distinction is between the other two audience groups are, however.
(0017490)
ttn   
2021-02-02 21:34   
Applicable not just to Libeufin, but all Taler documentation:
https://documentation.divio.com/
(0018093)
ttn   
2021-08-11 04:55   
Please see recent commits in docs.git/libeufin/*.rst --
the "target audience" can be "operator", "developer", "core developer".
(Feel free to add/correct my guesses.)
(0018632)
ttn   
2022-01-12 02:25   
Just managed to "manually" build/install libeufin. When i tried to run libeufin-cli, i saw an error:

 ModuleNotFoundError: No module named 'click'

This makes sense since i don't have that module installed on my system (yet).
Anyway, we should probably document these runtime dependencies, and additionally
make sure the Debian packaging declares them so that they are installed automatically.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7147 [Taler] documentation text have not tried 2022-01-11 11:04 2023-09-03 18:18
Reporter: ttn Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: libeufin-{sandbox,nexus,cli} needs a manpage
Description: Question: Should it be part of the other Taler manpages?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: command-line-possibilities (4,652 bytes) 2022-01-11 13:26
https://bugs.gnunet.org/file_download.php?file_id=1136&type=bug
Notes
(0018628)
ttn   
2022-01-11 13:26   
I've made a preliminary distillation of the command-line possibilities for libeufin-cli (attached).
Please take a look. I'll convert it to a proper manpage once it gets your approval.
(0018637)
ttn   
2022-01-17 18:07   
Actually, it would be nice to have manpages for all libeufin programs, i.e., libeufin-{sandbox,nexus,cli}.
(0018640)
ttn   
2022-01-19 11:15   
I've started the libeufin-sandbox manpage:

https://git.taler.net/docs.git/commit/?id=bcd5adae13a2f0c94f98dc25c73c6dbcadf7d35d

@MS PTAL when you get a chance.
(0018641)
ttn   
2022-01-19 11:18   
I'm looking to clarify the libeufin-sandbox interaction model.
When you have a moment, could you take a look at the new (wip) manpage and let me know if i'm on the right track?
(0018642)
ttn   
2022-01-19 13:20   
@MS Another question:

https://git.taler.net/docs.git/commit/?id=edec0fdc0134da59e4293421f7bce37e392b8103
(0018663)
ttn   
2022-01-25 00:22   
I've just pushed the manpage for libeufin-sandbox(1).

Here are the relevant commits:
5adcf79 2022-01-24 New manpage: libeufin-sandbox(1)
01281b4 2022-01-24 add FIXME for ‘make-transaction’ and ‘camt053tick’
fcf97f5 2022-01-24 write ‘camt053tick’ description, including example
41f40cc 2022-01-24 fix typo: s/that/for/
45b63d0 2022-01-24 write ‘make-transaction’ description
4dc26e1 2022-01-24 replace question to MS w/ blurb on Control-C
a41b104 2022-01-24 replace FIXME w/ libeufin-cli
4432884 2022-01-24 mention direct-access operation mode
21f1f6b 2022-01-24 document automagic ‘default’ demobank creation for ‘make-transaction’ and ‘serve’
8de9a0e 2022-01-24 write ‘default-exchange’ description, including example
7bfee7b 2022-01-24 write ‘config’ description, including example
d6d3763 2022-01-24 reorder command ‘config’ before ‘default-exchange’
f770a37 2022-01-19 s/core banking system/banking system core/g
edec0fd 2022-01-19 describe ‘serve’ in libeufin-sandbox(1)
5c02597 2022-01-19 describe ‘reset-tables’ in libeufin-sandbox(1)
bcd5ada 2022-01-19 new WIP manpage: libeufin-sandbox(1)

Feedback welcome!

Now on to libeufin-nexus(1)...
(0018671)
ttn   
2022-01-26 12:21   
The libeufin-nexus(1) manpage is now available:

- https://git.taler.net/docs.git/commit/?id=65a9b2dc88c4756f10c8287347d33b01bb1ec9c4
- https://docs.taler.net/manpages/libeufin-nexus.1.html

Now on to the big one: libeufin-cli(1)!
(0018677)
ttn   
2022-02-02 06:25   
After some discussion w/ MS, i've come to a better understanding (maybe) of the Access API as it
relates to the LIBEUFIN_SANDBOX_URL env var. To help the documentation effort, i've pushed:

- https://git.taler.net/libeufin.git/commit/?h=dev/ttn/refactoring&id=4caed8388d11701da995cf368c21a6b742e2b628

IIUC, non-Acess-API commands will go away at some point. So, i wonder if it makes sense to document
them at all. My question is: Is there a timeframe planned for their removal?
(0018678)
ms-mantis   
2022-02-02 07:39   
I'd discourage to document those: both in the manpage and in various tutorials.
They'll be removed once TypeScript tests (at wallet-core.git) won't use them anymore.
No defined timeframe but now reported here: 0007168
(0018692)
ttn   
2022-02-10 10:37   
OK, i'm taking a detour from the libeufin-cli(1) manpage to fix up the "configuring the sandbox" section in the Nexus tutorial:

- https://git.taler.net/docs.git/tree/libeufin/nexus-tutorial.rst#n130

Currently, here are the libeufin-cli sandbox commands used in that section:
  - cli sandbox check
  - cli sandbox ebicshost create
  - cli sandbox ebicshost list
  - cli sandbox ebicssubscriber create
  - cli sandbox ebicssubscriber list
  - cli sandbox ebicsbankaccount create
  - cli sandbox bankaccount generate-transactions
  - cli sandbox bankaccount simulate-incoming-transaction
  - cli sandbox bankaccount transactions

Of these, i'm trying to determine which are "old" commands (to be replaced by 'libeufin-cli sandbox demobank' commands, perhaps).
I guess the "... create" commands are "old", but the "... list" commands are going to stay. Is that correct?
My question generally is: Which of those are "old"?
(0019055)
Christian Grothoff   
2022-08-25 21:30   
MS: can you please try to help ttn with this?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7821 [Taler] libeufin (general) major always 2023-04-25 23:10 2023-09-03 18:16
Reporter: Christian Grothoff Platform: i7  
Assigned To: Antoine A OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implementation of basic-auth on server is wrong
Description: Which is why it works with curl but not with wget. wget doesn't like it because the server does not return a proper challenge when requesting authorization.

This applies to nexus and sandbox.

When giving a 401, WWW-Authenticate should always be properly specified by the server.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020157)
Christian Grothoff   
2023-04-25 23:11   
Passing "--auth-no-challenge" to wget works around the issue, but this is a bug in the HTTP server logic and should be fixed there.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7414 [Taler] libeufin-bank major N/A 2022-10-23 15:20 2023-09-03 18:16
Reporter: Christian Grothoff Platform: i7  
Assigned To: Antoine A OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: 0.9.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: [security] Demonstration SPA stores password in plaintext in localstorage
Description: Nora reports:

The SPA currently stores the login details on the client in LocalStorage as backend-state.username & backend-state.password in plaintext.

We should instead serve authentication tokens which would be stored in place of a password, at a bare minimum.

Something like a simple randomized string that would get invalidated after some time should be sufficient, however something similar to RFC7519 should also work. Either way, we should not store the password (in an unhashed form) anywhere, neither on the client, nor the server.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7588 [Taler] libeufin-nexus major have not tried 2023-01-14 10:56 2023-09-03 18:15
Reporter: MS Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: /admin/add/incoming has hard-coded credentials
Description: This call is offered in the Taler facade. It is used for testing and forwards the request
to fund the caller to their own bank account at the Sandbox. The Sandbox credentials
now are hard-coded in the facade, but should be specified via another mechanism.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6380 [Taler] libeufin-nexus minor have not tried 2020-06-14 15:53 2023-09-03 18:14
Reporter: Florian Dold Platform:  
Assigned To: Antoine A OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: more extensive integration test cases for TWG are required
Description: We currently test very little. What we need to add is:

* transactions that are returned due to missing reserve pub
* transactions that don't even have a debtor account (needs sandbox support)
* transactions that
* ... and probably many more!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017219)
MS   
2020-12-20 13:58   
The mapping between (a) and (b) needs to be tested.

(a) transaction indexes that are known natively (= no facade involved) by the nexus.
(b) the transaction indexes as viewed by the Taler facade.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7587 [Taler] libeufin (general) minor have not tried 2023-01-14 10:04 2023-09-03 18:14
Reporter: MS Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: General pass to potentially switch "200 OK" to "204 No Content".
Description: The Taler Wire Gateway API got already changed here: 0676e25980a8b..

This report contiues: 0007301.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020099)
Florian Dold   
2023-04-17 11:04   
What's the rationale for this? It's clearly not a performance issue, why are we complicating the API with different types of responses (empty list vs. 204) to indicate zero transactions?
(0020133)
Florian Dold   
2023-04-23 19:36   
Discussed with Christian: The idea is that 204 indicates that there are no new transactions *and the client should go into long-polling*, while we expect 200 only when transactions are present.

While I still think that this is an over-optimization, we should still consistently apply what we've agreed on.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7797 [Taler] libeufin-bank minor have not tried 2023-04-10 14:24 2023-09-03 18:11
Reporter: MS Platform:  
Assigned To: Antoine A OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Integration API has the wrong error format.
Description: Error handling happens, but responds with the wrong format. Starting with the Integration API part,
and Ideally ending with all LibEuFin, the following format should be used:
this format: https://docs.taler.net/core/api-common.html#tsref-type-ErrorDetail

The original bug report follows:

> $ curl "
> https://bank.demo.taler.net/demobanks/default/integration-api/withdrawal-operation/b1155bcf-4550-497f-be0e-ff6948b03194"
> -d '{"reserve_pub":"123123"}'
> {
> "error" : {
> "type" : "sandbox-error",
> "description" : "Selecting a different reserve from the one already
> selected"
> }
> }
>
> The response doesn't contain error code, it follows another format.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7243 [Taler] bank API (C) feature always 2022-05-17 20:19 2023-09-03 18:11
Reporter: sebasjm Platform:  
Assigned To: Antoine A OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: long polling for checking reserved key status
Description: when the wallet is doing the withdrawal the operation can be completed from a mobile phone

wallet should check (with long polling) the status of the reserve even before the used confirmed the operation since it may be completed from other wallet

from the wallet webextension we want to show a QR code in the withdrawal process to be completed in the mobile phone, and this feature is a blocker
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7273 [Taler] exchange feature N/A 2022-07-05 13:05 2023-09-03 18:10
Reporter: Christian Grothoff Platform: i7  
Assigned To: Antoine A OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: taler-bank-benchmark should be able to launch libeufin
Description: Right now, taler-bank-benchmark only works with the C fakebank. But we will (eventually) want to benchmark libeufin. So taler-bank-benchmark should be modified to support launching libeufin (sandbox+nexus). FIXME exists in the code.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7458 [Taler] demobank feature always 2022-11-15 15:55 2023-09-03 18:10
Reporter: sebasjm Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: allow configuration of another BIC number other than SANDBOXX
Description: should this be done on account creation?
(CustomerRegistration needs a "val bic: String?" that can be used on /register)

it will be better to set a default value on sandbox config.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6992 [Taler] libeufin-nexus feature N/A 2021-08-15 11:55 2023-09-03 18:10
Reporter: Christian Grothoff Platform: i7  
Assigned To: Antoine A OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: need new "generic-credit" facade
Description: For Anastasis, we need a new Facade of LibEuFin where we can _only_ poll for incoming credits into the account.
In contrast to the existing taler-exchange facade, the wire transfer subjects can be arbitrary strings and not only reserve public keys.

Please implement the respective facade and specify a REST API for it (based on the existing exchange facade API). The main difference should be that it returns an unrestricted "const char */String" for the wire subject.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018138)
Christian Grothoff   
2021-08-27 23:15   
I think this is fixed, at least I'm happy with what I got ;-). Marcello: unless the facade is completely fake and only works with sandbox, you should probably 'resolve' this one :-)
(0020092)
Christian Grothoff   
2023-04-13 20:43   
We may want to rename it from anastasis to 'generic-credit' or something like that?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6269 [Taler] libeufin-bank minor have not tried 2020-05-29 08:48 2023-09-03 18:09
Reporter: Florian Dold Platform:  
Assigned To: Antoine A OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sandbox should emit c52/c53 more like real banks do
Description: Right now we generate a fresh c53 statement for every request.

Banks would return the same message on every request. They basically emit c5x messages regularly, and EBICS just allows you to download them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015980)
Florian Dold   
2020-05-29 09:25   
A major problem right now is that the MsgId of messages emitted by the sandbox is always zero. This doesn't mesh well with the assumptions made in the nexus (and that are presumably true for all real banks).
(0015981)
Florian Dold   
2020-05-29 09:26   
Setting this to higher prio, as Heng Yeow needs this for testing his UI stuff
(0015983)
MS   
2020-05-29 13:33   
bf5ae27..01c8396 is a quick fix that gives more entropy to the message id.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7309 [Taler] demobank-ui tweak always 2022-08-25 16:52 2023-09-03 18:07
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: improve language switcher integration
Description: Right now, the SPA is launched via /demobanks/default and then always starts with English.
We should support passing "/demobanks/default?language=$LANG" ($LANG=en/de/it/...) and then automatically switch the SPA into the respective language on load, instead of relying on the user (again) setting the language via the language switcher.

The demo.site of nginx is currently configured to replace https://bank/$LANG/ with https://bank/demobanks/defaults, and should be updated to not throw away $LANG but instead pass it via language=$LANG.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7847 [Taler] wallet-core feature unable to reproduce 2023-05-23 17:24 2023-09-03 14:54
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: DoS when all wallet try to refresh coins at the same time
Description: Instead of wallet doing refresh exactly 3 months before expiration time, it should refresh based on a random value close to 3 months


From email

> The refresh transaction is automatically triggered by the wallet software 3 months before the end of the validity of a coin. Especially if Exchange
> operators charge refresh fees, the fact that a fee may automatically be charged in the background without user interaction is likely particularly
> difficult to explain.

> But that also means that "3 months before the end of the validity of a coin" will be the same for every wallet since the beginning,
> isn't this a self-DOS waiting for us?
> I mean, all the wallet with all those coins will try to refresh at the same time.
> Maybe refresh time should random time based in a normal distribution with mean expiration_time - 2 month and std_dev 1 month
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7757 [libmicrohttpd] libmicrohttpd API major always 2023-03-09 07:06 2023-09-03 12:05
Reporter: fengyingjie Platform: linux  
Assigned To: Christian Grothoff OS: centos  
Priority: immediate OS Version: 7.4.1708  
Status: resolved Product Version: 0.9.75  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version:  
Summary: MHD_add_response_header set by MHD_create_response_from_callback continues to execute MHD_queue_response and cannot continue to
Description: MHD_add_response_header set by MHD_create_response_from_callback continues to execute MHD_queue_response and cannot continue to modify the response after receiving the callback asynchronously header

 
Tags:
Steps To Reproduce: // Create the service instance

1. MHD_start_daemon



2. struct MHD_Response *response = MHD_create_response_from_callback(MHD_SIZE_UNKNOWN,

500, &janus_http_response_callback, msg, NULL);



// The callback to get the response data and copy the body of the callback into the pyload of the response

janus_http_response_callback



/* Suspend the connection */

3. MHD_suspend_connection(msg-> connection);



/* add response header */

4. MHD_add_response_header(response, "Content-Type", "application/json");



/* add cors header */

5. janus_http_add_cors_headers(msg, response);



// Queue the response for transmission to the client as soon as possible, but only after MHD_AccessHandlerCallback returns. This function checks if it is legal to queue a response for a given connection at this time. It also increments the internal reference counter of the response object (the counter is automatically decremented once the response is transmitted).

6. ret = MHD_queue_response(msg-> connection, MHD_HTTP_OK, response);



// Destroy the response object and associated resources (decrement the reference count)

7. MHD_destroy_response(response);





The callback is received to process send_messages

Assign the received response_text to the response's pyload



/* resume the connection */

9. MHD_resume_connection(msg-> connection);


10. View the microhttpd library source At step 6, the connection-> state is set from MHD_CONNECTION_HEADERS_PROCESSED to MHD_CONNECTION_FOOTERS_RECEIVED, In MHD_CONNECTION_FOOTERS_RECEIVED the thread copies the header into the header of the sent packet

So at step 8, there is no way to change the header information by reruning steps 4 and 6.

 
Additional Information:
Attached Files:
Notes
(0019939)
fengyingjie   
2023-03-09 07:55   
At step 6, there is no way to change the header information by reexecuting steps 3 and 6. In step 6, the header is updated again; calling MHD_queue_response causes a deadlock.
(0020466)
Christian Grothoff   
2023-09-03 00:22   
You're not allowed to call MHD_queue_response() outside of the access handler callback, and you write above that you called it just after returning from it. That's an API violation. Alas, we should guard against this instead of deadlocking. I'm adding a few lines to ensure MHD_queue_response() returns MHD_NO instead of allowing you to queue a response at an "illegal" time.
(0020467)
Christian Grothoff   
2023-09-03 00:25   
Fix committed to master branch.
(0020468)
Christian Grothoff   
2023-09-03 00:26   
Fix pushed in 8586d919..eb21a977. Note that now the MHD_queue_response() will simply fail (return MHD_NO), it will not allow your code to "work".
(0020477)
Karlson2k   
2023-09-03 10:14   
We already have similar connection->in_idle. Shouldn't it be reused instead of new connection->in_access_handler?
(0020478)
Christian Grothoff   
2023-09-03 11:43   
in_idle is about preventing recursion on the idle function, and it would not be nearly as tight as it is set at times when we are not in the access handler callback at all. I think we can afford an extra bit to make the check tight.
(0020480)
Christian Grothoff   
2023-09-03 12:05   
efc136b4..c690b40e fixes the introduced regression.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7772 [libmicrohttpd] performance minor always 2023-03-24 15:24 2023-09-03 10:10
Reporter: newtec_mh Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 0.9.75  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version:  
Summary: Upgraded connection in threaded context is starved of memory
Description: I'm experiencing an issue with upgraded connections running libmicrohttpd with a thread per connection. What seemingly happens is that after receiving the headers, the connections read buffers are shrunk, and the write buffer is afterwards increased to the full size of the memory pool.

This is never "undone" meaning that *if* a connection is upgraded, the memory pool is "empty" and the upgraded connection then starts using the emergency buffer (e_buf) which by default has a size of 8 bytes, 4 is allocated to write, 4 to read.

This means suddenly all communication between the application and the library and again between the library and the upgraded connection socket is segmented into 4 byte reads/writes.

Now as such, this doesn't necessarily post a "big" problem, besides it for sure isn't intended functionality, however if the connections are https based, each 4 byte "chunk" is now encrypted, causing a massive overhead (in my case each 4 byte chunk is then encrypted a 26 byte chunk).

The seemingly "obvious" choice I found for "easily" fixing this, at least in my case, was to reenable the disabled function "connection_shrink_write_buffer" and call if after the headers have been sent, just before upgrading the connection. I've attached a patch for reference that fixes it in one case at least. I have not determined other possible code paths that might trigger the same problem.
Tags:
Steps To Reproduce: 1. Create server with MHD_USE_THREAD_PER_CONNECTION and MHD_ALLOW_UPGRADE.

2. Connect WebSocket to server.

3. Observe the buffer size used in the connection handler thread (through GDB for instance). Read/write buffers are 4 bytes each, as the e_buf "emergency buffer" is used, which defaults to 8 bytes in size.
Additional Information:
Attached Files: avoid-upgraded-connection-memory-starvation.patch (1,035 bytes) 2023-03-24 15:24
https://bugs.gnunet.org/file_download.php?file_id=1365&type=bug
Notes
(0020471)
Christian Grothoff   
2023-09-03 00:50   
Sorry for the huge delay with this one. Fixed exactly as suggested in 438c3ee2..fabafbaa.
(0020476)
Karlson2k   
2023-09-03 10:10   
Actually it was reported in mailinglist and was fixed previously by da42f22c64357179f3869594ca4001c7525a2a1f
https://lists.gnu.org/archive/html/libmicrohttpd/2023-04/msg00001.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7889 [libextractor] plugins major always 2023-07-19 09:29 2023-09-03 00:55
Reporter: wiz Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version: 1.11  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.12  
    Target Version: 1.12  
Summary: exiv2 0.28 breaks exiv2_extractor.cc
Description: The exiv2 project has changed the API in the 0.28 release, breaking the exiv2 plugin.

I noticed it in libextractor 1.11, but I tried building libextractor git head to confirm the problem is still there and see:

```
libtool: link: ( cd ".libs" && rm -f "libextractor_archive.la" && ln -s "../libextractor_archive.la" "libextractor_archive.la" )
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/include -I../../src/common -I/usr/pkg/include -g -O2 -MT exiv2_extractor.lo -MD -MP -MF .deps/exiv2_extractor.Tpo -c -o exiv2_extractor.lo exiv2_extractor.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/include -I../../src/common -I/usr/pkg/include -g -O2 -MT exiv2_extractor.lo -MD -MP -MF .deps/exiv2_extractor.Tpo -c exiv2_extractor.cc -fPIC -DPIC -o .libs/exiv2_extractor.o
exiv2_extractor.cc:233:25: error: 'AutoPtr' in 'class Exiv2::BasicIo' does not name a type
  233 | virtual Exiv2::BasicIo::AutoPtr temporary () const;
      | ^~~~~~~
exiv2_extractor.cc:129:14: error: conflicting return type specified for 'virtual long int ExtractorIO::write(Exiv2::BasicIo&)'
  129 | virtual long write (Exiv2::BasicIo &src);
      | ^~~~~
In file included from /usr/pkg/include/exiv2/exiv2.hpp:8,
                 from exiv2_extractor.cc:30:
/usr/pkg/include/exiv2/basicio.hpp:92:18: note: overridden function is 'virtual size_t Exiv2::BasicIo::write(Exiv2::BasicIo&)'
   92 | virtual size_t write(BasicIo& src) = 0;
      | ^~~~~
exiv2_extractor.cc:175:18: error: conflicting return type specified for 'virtual long int ExtractorIO::tell() const'
  175 | virtual long int tell (void) const;
      | ^~~~
In file included from /usr/pkg/include/exiv2/exiv2.hpp:8,
                 from exiv2_extractor.cc:30:
/usr/pkg/include/exiv2/basicio.hpp:203:32: note: overridden function is 'virtual size_t Exiv2::BasicIo::tell() const'
  203 | [[nodiscard]] virtual size_t tell() const = 0;
      | ^~~~
exiv2_extractor.cc:216:21: error: conflicting return type specified for 'virtual std::string ExtractorIO::path() const'
  216 | virtual std::string path () const;
      | ^~~~
In file included from /usr/pkg/include/exiv2/exiv2.hpp:8,
                 from exiv2_extractor.cc:30:
/usr/pkg/include/exiv2/basicio.hpp:221:44: note: overridden function is 'virtual const string& Exiv2::BasicIo::path() const'
  221 | [[nodiscard]] virtual const std::string& path() const noexcept = 0;
      | ^~~~
exiv2_extractor.cc: In member function 'virtual int ExtractorIO::getb()':
exiv2_extractor.cc:323:18: error: 'BasicError' is not a member of 'Exiv2'; did you mean 'strError'?
  323 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~~~~~~~
      | strError
exiv2_extractor.cc:323:29: error: expected primary-expression before 'char'
  323 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~
exiv2_extractor.cc: In member function 'virtual void ExtractorIO::transfer(Exiv2::BasicIo&)':
exiv2_extractor.cc:382:16: error: 'BasicError' is not a member of 'Exiv2'; did you mean 'strError'?
  382 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~~~~~~~
      | strError
exiv2_extractor.cc:382:27: error: expected primary-expression before 'char'
  382 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~
exiv2_extractor.cc: In member function 'virtual Exiv2::byte* ExtractorIO::mmap(bool)':
exiv2_extractor.cc:431:16: error: 'BasicError' is not a member of 'Exiv2'; did you mean 'strError'?
  431 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~~~~~~~
      | strError
exiv2_extractor.cc:431:27: error: expected primary-expression before 'char'
  431 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~
exiv2_extractor.cc:435:1: warning: no return statement in function returning non-void [-Wreturn-type]
  435 | }
      | ^
exiv2_extractor.cc: In member function 'virtual std::string ExtractorIO::path() const':
exiv2_extractor.cc:523:16: error: 'BasicError' is not a member of 'Exiv2'; did you mean 'strError'?
  523 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~~~~~~~
      | strError
exiv2_extractor.cc:523:27: error: expected primary-expression before 'char'
  523 | throw Exiv2::BasicError<char> (Exiv2::kerDecodeLangAltQualifierFailed);
      | ^~~~
exiv2_extractor.cc:527:1: warning: no return statement in function returning non-void [-Wreturn-type]
  527 | }
      | ^
exiv2_extractor.cc: At global scope:
exiv2_extractor.cc:555:17: error: 'AutoPtr' in 'class Exiv2::BasicIo' does not name a type
  555 | Exiv2::BasicIo::AutoPtr
      | ^~~~~~~
exiv2_extractor.cc: In function 'void EXTRACTOR_exiv2_extract_method(EXTRACTOR_ExtractContext*)':
exiv2_extractor.cc:740:10: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
  740 | std::auto_ptr<Exiv2::BasicIo> eio (new ExtractorIO (ec));
      | ^~~~~~~~
In file included from /usr/include/g++/bits/locale_conv.h:41,
                 from /usr/include/g++/locale:43,
                 from /usr/include/g++/iomanip:43,
                 from exiv2_extractor.cc:26:
/usr/include/g++/bits/unique_ptr.h:57:28: note: declared here
   57 | template<typename> class auto_ptr;
      | ^~~~~~~~
exiv2_extractor.cc:740:59: error: invalid new-expression of abstract class type 'ExtractorIO'
  740 | std::auto_ptr<Exiv2::BasicIo> eio (new ExtractorIO (ec));
      | ^
exiv2_extractor.cc:42:7: note: because the following virtual functions are pure within 'ExtractorIO':
   42 | class ExtractorIO : public Exiv2::BasicIo
      | ^~~~~~~~~~~
In file included from /usr/pkg/include/exiv2/exiv2.hpp:8,
                 from exiv2_extractor.cc:30:
/usr/pkg/include/exiv2/basicio.hpp:82:18: note: 'virtual size_t Exiv2::BasicIo::write(const byte*, size_t)'
   82 | virtual size_t write(const byte* data, size_t wcount) = 0;
      | ^~~~~
/usr/pkg/include/exiv2/basicio.hpp:111:19: note: 'virtual Exiv2::DataBuf Exiv2::BasicIo::read(size_t)'
  111 | virtual DataBuf read(size_t rcount) = 0;
      | ^~~~
/usr/pkg/include/exiv2/basicio.hpp:124:18: note: 'virtual size_t Exiv2::BasicIo::read(Exiv2::byte*, size_t)'
  124 | virtual size_t read(byte* buf, size_t rcount) = 0;
      | ^~~~
/usr/pkg/include/exiv2/basicio.hpp:230:16: note: 'virtual void Exiv2::BasicIo::populateFakeData()'
  230 | virtual void populateFakeData() = 0;
      | ^~~~~~~~~~~~~~~~
exiv2_extractor.cc:741:19: error: 'AutoPtr' is not a member of 'Exiv2::Image'
  741 | Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open (eio);
      | ^~~~~~~
exiv2_extractor.cc:742:14: error: 'image' was not declared in this scope
  742 | if (0 == image.get ())
      | ^~~~~
exiv2_extractor.cc:744:5: error: 'image' was not declared in this scope
  744 | image->readMetadata ();
      | ^~~~~
exiv2_extractor.cc:825:31: error: expected unqualified-id before '&' token
  825 | catch (const Exiv2::AnyError& e)
      | ^
exiv2_extractor.cc:825:31: error: expected ')' before '&' token
  825 | catch (const Exiv2::AnyError& e)
      | ~ ^
      | )
exiv2_extractor.cc:825:31: error: expected '{' before '&' token
exiv2_extractor.cc:825:33: error: 'e' was not declared in this scope; did you mean 'ec'?
  825 | catch (const Exiv2::AnyError& e)
      | ^
      | ec
exiv2_extractor.cc:831:3: error: expected primary-expression before 'catch'
  831 | catch (void *anything)
      | ^~~~~

```
Tags:
Steps To Reproduce: Build libextractor from git against exiv2 0.28.0
Additional Information:
Attached Files:
Notes
(0020358)
wiz   
2023-07-19 09:34   
The Arch project has a patch for libextractor 1.11 here:
https://gitlab.archlinux.org/archlinux/packaging/packages/libextractor/-/blob/main/exiv2-0.28.patch
Additionally, libexiv2 now needs C++11.
(0020472)
anonymous   
2023-09-03 00:54   
Fix committed to master branch.
(0020473)
Christian Grothoff   
2023-09-03 00:54   
Thanks for pointing me to the patch, applied to Git master now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7928 [libmicrohttpd] documentation minor always 2023-08-27 13:05 2023-09-03 00:30
Reporter: kisaragi-hiu Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9.75  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: Git master  
Summary: Incorrect direntry in libmicrohttpd-tutorial.texi making it unaccessable from Info directory
Description: The direntry of libmicrohttpd-tutorial is

  * libmicrohttpdtutorial: (libmicrohttpd). A tutorial for GNU libmicrohttpd.

But this will cause Info to open the file "libmicrohttpd", which is the manual, not the tutorial.

It should be

  * libmicrohttpdtutorial: (libmicrohttpd-tutorial). A tutorial for GNU libmicrohttpd.

instead.
Tags:
Steps To Reproduce: - Open Info
- Press C-s and search for libmicrohttpd
- Use C-n and C-p to navigate to the line for the tutorial
- Press RET to open it
- Notice it opened the manual, and not the tutorial

You can also use the command `info "(libmicrohttpd-tutorial)Top"` to verify that the tutorial indeed exists, and it's just an error with the dir entry.
Additional Information:
Attached Files:
Notes
(0020469)
Christian Grothoff   
2023-09-03 00:29   
Fix committed to master branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6564 [Taler] wallet-core feature have not tried 2020-09-03 19:30 2023-08-31 14:25
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet-core API and UX design for auditor management needed
Description: We had some partially working, totally unusable implementation of this in an ancient version of the web extension.

Now that the requirements are more clear, we should properly re-design this based on the desired user experience, and then implement an API for it in wallet-core.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018130)
belen   
2021-08-25 13:05   
Where can I find those requirements? Are they documented somewhere? And if not, who should I talk to about them?
(0019828)
Florian Dold   
2023-02-13 20:04   
Waiting for feedback on DD35 now.
(0020007)
Florian Dold   
2023-04-04 12:02   
Seems like everyone agrees on DD35, we need to spec the corresponding wallet APIs now.
(0020192)
Florian Dold   
2023-05-11 14:39   
As noted by Marc, we should also have functionality to delete a known exchange (and the balance associated with that).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7484 [Taler] wallet (WebExtension) tweak N/A 2022-11-18 15:26 2023-08-30 13:55
Reporter: Emmanuel Platform:  
Assigned To: MarcS OS:  
Priority: low OS Version:  
Status: assigned Product Version: 0.9.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Usability problem with Bitcoin amounts
Description: Bitcoin amounts are normally in mBTC (milliBTC) to be of normal length. (100$ = 7mBTC).
It would be convenient to have the prices having a lot of zeros in mBTC.
BITCOINBTC 0.00001
could be displayed mBTC 0.01
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019441)
Christian Grothoff   
2022-11-18 15:28   
(Last edited: 2022-12-06 12:50)
IMO we can do the "m" prefix by detecting a 0.00-prefix in the amount automatically, possibly for *all* currencies, not just BTC.

Similarly, *IF* we detect that the exchange offers 'tiny' amounts, we could allow the user to change the currency from BTC to mBTC in a drop-down when entering amounts.
(0019524)
sebasjm   
2022-12-20 14:46   
The currency dropdown is implemented ,
I'm not sure if we want this to be always possible or just based on some conditions.

My proposal:

1.- Build a currency-decimal map from the denominations configuration
interface CurrencyDecimalMap {
 [currency: string]: {
    maxFracDigit: number;
    maxIntDigit: number;
    current: number;
  }
}

2.- If maxFracDigit - maxIntDigit > 3 show the currency dropdown to allow the selection of different unit with a prefix in the currency

prefix:

k = kilo
M = mega
G = Giga
T = Tera
P = Peta

m = millis
μ = micro
n = nano
p = pico
f = femto
(0019531)
Christian Grothoff   
2022-12-21 00:09   
That sounds reasonable to me. But we won't need nano/pico/femto: we only allow up to 10^-8.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7915 [Taler] wallet-core feature N/A 2023-08-11 16:32 2023-08-30 08:34
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: pass currency_fraction_digits to wallet UIs
Description: This is the desired number of digits amounts in this currency should typically be rendered in. As per castle discussion with Florian and Marc. The parameter is already supported in the latest exchange (defaults to 0).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020420)
Florian Dold   
2023-08-21 15:21   
In order for UIs to validate cached info about currencies, wallet-core should also emit a "currency-info-change" notification whenever currency info changes.
(0020427)
MarcS   
2023-08-23 10:40   
Please set the default for numFractionalDigits to 2 (€, $, most other currencies), as 0 is only used by ¥.
(Some arabic currencies use 3 - I don't know any "global" currency using other values than 0, 2 or 3)
Set the default for numTinyDigits to 0.
(0020428)
Christian Grothoff   
2023-08-23 10:48   
4a64d721..32659fe7 sets the default to 2 (in the exchange). Note that numTinyDigits should not have a default at all, it MUST be "computed" by the wallet based on the actual denominations offered by the exchange.
(0020429)
MarcS   
2023-08-23 11:02   
"computed by the wallet" - does this mean wallet-core does this when it adds an Exchange, and whenever denominations change, but the result is rather a constant for the frontend (cached, with notification from wallet-core when changed)?
Or does the frontend need to compute this for every transaction?
(0020430)
Christian Grothoff   
2023-08-23 11:25   
Wallet-core should (re)compute it whenever it gets a new /keys response. (count maximum number of fractional digits encountered in all denominations).
(0020438)
sebasjm   
2023-08-24 20:29   
if the currency is official then we MUST use ISO 4217 table https://en.wikipedia.org/wiki/ISO_4217

what is the purpose or the user case for numTinyDigits ?
(0020462)
MarcS   
2023-08-30 08:34   
Use case for numTinyDigits is to be able to specify e.g. fractions of a cent like gas filling stations do (1,23⁴ or 0.78⁹).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7930 [Taler] wallet-core minor always 2023-08-29 15:10 2023-08-29 15:10
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wallet user should have a clear workaround if the exchange keys are no longer offered by the exchange
Description: I found in a situations that I had enough amount to pay but unluckily from denoms that are not longer offered by the exchange.

the problems is that the error reported by the wallet is confusing: no enough balance and feeGapEstimate equal to requested amount.

Maybe when denoms are marked as not usable anymore (since they are not depositable) wallet should create a tx record to inform that the wallet has lost money and do not count that coins into the general amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Selection_216.png (22,668 bytes) 2023-08-29 15:10
https://bugs.gnunet.org/file_download.php?file_id=1395&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7433 [Taler] wallet-core feature N/A 2022-11-04 16:20 2023-08-29 14:03
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet does not support invoicing with non-zero purse fees
Description: It is currently unable to pay for the purse creation with its coins, even if it has coins.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6914 [Taler] wallet-core minor always 2021-07-06 16:26 2023-08-29 09:50
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: "annual fee for sync service" gets paid by another wallet, original wallet does not update provider status
Description: Setup a sync service with wallet webextension
If the order gets paid by another wallet (like the wallet-cli) then the webextension can use the service but reports unpaid provider.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020449)
Florian Dold   
2023-08-29 09:50   
Scheduled post-1.0, because sync itself is post-1.0.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7927 [GNUnet] other major always 2023-08-25 23:40 2023-08-25 23:40
Reporter: f00 Platform: Rapsberry pi  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: 11  
Status: new Product Version: 0.13.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: does not save the logs
Description: does not save the logs
Tags:
Steps To Reproduce: $ gnunet-core -m -L DEBUG
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6253 [Taler] libeufin-nexus text have not tried 2020-05-21 09:16 2023-08-25 14:25
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: adjust and document JSON formats for account information
Description: This includes:
 * information about the account itself (should include payto URI!)
 * information about a prepared payment
 * information about a transaction

These formats are currently barely documented.

We also should try to make the terms match more commonly accepted terminology, like creditorAccount and debitorAccount instead of "counterpart".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020446)
Florian Dold   
2023-08-25 14:25   
Unassigning, since it's unclear we need this with the nexus restructuring.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7658 [Taler] qtart feature have not tried 2023-02-03 14:55 2023-08-25 14:20
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: support threaded crypto workers
Description: Right now, qtart doesn't support running wallet-core with threaded crypto workers, because wallet-core doesn't yet understand the Worker API that QuickJS-libc offers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020444)
Florian Dold   
2023-08-25 14:20   
De-prioritizing this, since the crypto is not the bottleneck in the qtart-based wallet.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7926 [Taler] demobank-ui minor have not tried 2023-08-24 20:13 2023-08-24 20:13
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: all webapps should save erros in a map and remove them there problems fix itselfs
Description: 3) I believe the "Unexpected error" (also bad) remains from a previous
502 request. You should definitively clear such errors once a subsequent
request (especially of the same type, but probably in general) has
succeeded instead of leaving them on-screen until the user presses 'clear').
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7924 [Taler] merchant backoffice SPA major always 2023-08-24 20:06 2023-08-24 20:06
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: all spa should query /config (and other stuffs)
Description: the error handling of
the SPA is bad: it gets a 404 (see rightmost screen) but in the UI there
is no error shown at all --- just the 'register' button doesn't do
anything. I can click it, but nothing happens!

1) Please make sure that *all* errors of *all* network requests by the
SPA are consistently handled.

2) All (!) SPAs (bank, merchant, anastasis) should do a "/config"
request early on to determine whether your configuration is sound.

2a) If not, instead of even showing a login/initial form show one big
error message that you are not configured correctly (suggesting the user
should "try again later by reloading the page with F5" or whatever will
sufficiently reload the cached configuration).

2b) Better, you could then try to force-reload your configuration
periodically (if the SPA has one that is downloaded via HTTP) in the
background once per minute and go to the login/initial screen once
/config works...).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7814 [Taler] wallet-core minor have not tried 2023-04-23 20:47 2023-08-24 16:38
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: DD37: handle funky deposit txn case where aborting(refresh) might still need to do a refund
Description: If the refund request fails because the deposit request did not arrive *yet*, the refresh will *also* fail if the refresh arrives after the deposit request is finally handled.

To resolve this, refresh groups should learn the ability to try to a refund request once if the refresh on that particular coin fails.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6800 [Taler] wallet-core feature have not tried 2021-03-10 19:06 2023-08-24 16:38
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should support link protocol (for double spend error recovery after restore from backup)
Description: The wallet should run the link protocol if it gets a double spend error that indicates the coin has been melted, and the new coin isn't known to the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7316 [Taler] wallet-core feature have not tried 2022-09-01 22:11 2023-08-24 16:33
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Get the 'taler' URI scheme into the HTML spec safe-list
Description: Other relatively recent protocols like "matrix" or "openpgp4fpr" got in there.

Maybe we can get in there as well? This would allow the web extension to register itself as a taler:// protocol handler.

https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019077)
sebasjm   
2022-09-02 13:52   
for future reference

https://github.com/effigies/openpgp4info

https://github.com/whatwg/html/issues/5343

matrix:
https://github.com/whatwg/html/pull/6320
https://bugs.chromium.org/p/chromium/issues/detail?id=1169258
https://bugzilla.mozilla.org/show_bug.cgi?id=1688030
(0019402)
Christian Grothoff   
2022-11-11 15:27   
https://datatracker.ietf.org/doc/draft-grothoff-taler/ is now a thing.

IETF uri-review request posted today, too.
(0019417)
Christian Grothoff   
2022-11-14 13:50   
Once we get provisional, we need to file bugs against Chrome and Mozilla, similar to
https://bugs.chromium.org/p/chromium/issues/detail?id=1169258 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1688030 against this (draft) pull request:
https://github.com/whatwg/html/pull/8503
(0019426)
Christian Grothoff   
2022-11-16 16:27   
(Last edited: 2022-11-16 16:27)
Submitted now for provisional registration to IANA; [IANA #1261076]
(0019450)
Christian Grothoff   
2022-11-18 21:37   
Provisional registration accomplished:

https://www.iana.org/assignments/uri-schemes/prov/taler
Registry: https://www.iana.org/assignments/uri-schemes
(0019453)
Christian Grothoff   
2022-11-18 23:21   
Bug filed on against Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1801423
(0019454)
Christian Grothoff   
2022-11-18 23:27   
Bug filed on Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=1386255
(0019915)
sebasjm   
2023-03-01 15:59   
we should monitor also this issue:

https://github.com/whatwg/html/issues/8596

>I hope registerProtocolHandler() can support native apps' behavior. When users click the link, fire an event with the link information in service worker, then the website(web app) can handle it in service worker, and the >current page stay there.

>This approach is more flexible for developers, and the current page does not navigate to other page. For example, in service worker, developers can open a new tab or popup window, or active(focus) an already opened page >or popup window to handle it.
(0019976)
Christian Grothoff   
2023-03-27 05:50   
Bug filed on WebKit;

https://bugs.webkit.org/show_bug.cgi?id=254497
(0020319)
sebasjm   
2023-06-28 20:27   
I'm setting this priority to normal and target POST 1.0 since we now have a workaround


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7869 [Taler] wallet-core minor have not tried 2023-06-20 19:16 2023-08-24 16:32
Reporter: MarcS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: If the very first transaction of a new wallet is P2P, then the ToS of the exchange needs to be accepted first
Description: Usually the very first transaction of a new wallet is a withdrawal, and the user always needs to accept the ToS first before actually being able to confirm the withdrawal.
However, the very first transaction could also be P2P. Currently it is not specified that the user should accept the ToS first, but of course this is necessary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5947 [Taler] libeufin-bank minor have not tried 2019-10-24 20:13 2023-08-24 16:32
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: spec and implement proper generation of EBICS Host "OrderID"
Description: The element "ebicsKeyManagementResponse/header/mutable/orderID" is currently set to a mock value, but it must contain a meaningful identificator.
Tags:
Steps To Reproduce:
Additional Information: The responsible object is generated in KeyManagementResponse.kt.
Attached Files:
Notes
(0015024)
Florian Dold   
2019-10-25 11:02   
See "Order Number" in the glossary (https://docs.taler.net/libeufin/ebics.html#ebics-glossary) for more info about the order ID.

The number must be unique per subscriber and order type. I'd suggest keeping a counter per subscriber and incrementing that in the same (SQL) transaction where the (EBICS) transaction is created.
(0015025)
Florian Dold   
2019-10-25 14:58   
Also, there needs to be some additional logic to "recycle" order IDs, since the space of order IDs is very small.

An order ID can be reused if the corresponding order is completely processed (e.g., there are no pending VEUs).
(0019818)
MS   
2023-02-13 18:19   
not fitting into the regional currencies setup, since Sandbox will not _serve_ EBICS. Removing the 0.9.2 target.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7719 [Taler] wallet (WebExtension) minor always 2023-02-23 15:50 2023-08-24 16:31
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: withdraw call to action should check if mobile withdrawal has been initiated
Description:  * set "Automatically open wallet based on page content"
 * initiate a withdrawal
 * choose "withdraw to a mobile phone"

Complete the withdrawal with the mobile

webex should update and move to the bank confirmation page.

When the confirmation is done with the browser, mobile app should then be updated (do not ask again for "confirm with the bank")
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020051)
sebasjm   
2023-04-10 15:40   
this will be fixed with the implementation of DD 037

there is no polling in the withdrawalgroup (to the bank status) because there is not transaction/operation yet in the wallet.
(0020335)
sebasjm   
2023-07-04 15:27   
I propose moving this to 1.0

if the user needs to complete the operation with other wallet then the current operation can be cancelled and started again without any drawback


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6558 [Taler] wallet-core feature have not tried 2020-09-03 12:34 2023-08-24 16:31
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: transaction item for "lost coins due to expiration" needed
Description: In some cases, the auto-refresh comes to late and the wallet loses coins. The wallet has to show an appropriate item in the transactions list for that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016824)
Florian Dold   
2020-09-03 17:27   
According to the discussion in 0006561, we also need to make sure that coins can be "revived" from this state when they were marked as expired because of a wrong system time setting.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7298 [Taler] wallet-core feature have not tried 2022-08-09 18:30 2023-08-24 16:30
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should allow optionally specifying (and remembering) sender information for p2p payments
Description: For PUSH payments, a checkbox

  [ ] Include my name

should be implemented. When checked, the user can provide their name, and the wallet can remember the last name provided.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020019)
Florian Dold   
2023-04-04 19:36   
We currently don't use sender names. We should probably wait with this kind of feature until taldir/mailbox and keep the simplicity of the P2P payments UI.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7920 [Taler] wallet-core feature have not tried 2023-08-21 13:16 2023-08-24 16:30
Reporter: MarcS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Support for multiple accounts (private KYC, business KYB)
Description: A user should be able to use the GNU Taler app on a smartphone for both their business and for private payments.
Tags: Wallet
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7866 [Taler] wallet-core minor always 2023-06-19 13:29 2023-08-24 16:30
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: transactions should keep some history data
Description: when a user see a transaction in the UI it would be nice to se the the state where the tx was and where the tx is going to be.

past states: wallet core can keep a timestamp of when the tx reach that point
future states: the ui can choose to show future happy path, nothing required from wallet core since it returns the graph already

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020302)
Florian Dold   
2023-06-26 11:26   
From a duplicate bug report:
"""
Some transactions can have a more complex history, such as a payment where we re-select a coin after we find out it has been already spent.
The wallet currently does this destructively, and there is no way to find out the history of what happened and where money potentially was lost.
Thus, for some transactions it would make sense to record some more history data.
"""


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7850 [Taler] wallet-core feature N/A 2023-05-26 15:14 2023-08-24 16:29
Reporter: MarcS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: aborting: "revive" or "resurrect" back to pending
Description: As long as no irrevocable actions within "aborting" happened, it should be possible for the user to "revive" or "resurrect" the dying (aborting) transaction back to "pending".
s.e.
Once the dying (aborting) transaction is finally dead, this is no longer possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Transaction common states 2 abort is final.png (112,440 bytes) 2023-05-26 15:14
https://bugs.gnunet.org/file_download.php?file_id=1379&type=bug
Transaction common states 3 aborting can revive.png (115,411 bytes) 2023-05-26 15:43
https://bugs.gnunet.org/file_download.php?file_id=1381&type=bug
Notes
(0020203)
MarcS   
2023-05-26 15:43   


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7582 [Taler] wallet-core feature have not tried 2023-01-13 02:27 2023-08-24 16:29
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement user-initiated p2p kyc / KYCed reserve management
Description: This might include the ability for users to initiate opening a KYC account (=KYCed reserve).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7581 [Taler] wallet-core feature have not tried 2023-01-13 02:26 2023-08-24 16:28
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement soft KYC for balance limits
Description: The wallet should request a KYC check when the balance exceeds a threshold
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6077 [Taler] wallet-core feature N/A 2020-02-04 22:13 2023-08-24 16:27
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sync support needed in wallet core
Description: The operations that should be provided (here described as command-line options for the CLI wallet) are:

0) sync --info-by-url $URL: obtain fee structure and other high level terms (warranty, etc.)
1) sync --create $URL: setup a new sync account (and pay for it!)
2) sync --info: show meta data of current account (fees, paid until, warranty, etc.)
3) sync --show: display a URI (taler://sync/$URL/$SECRET) with the information needed to join a sync group / download a backup
4) taler-wallet-cli taler://sync/$URL/$SECRET: join the sync group (download, merge, upload to notify other members of join)
5) sync [nothing]: synchronize NOW with the active sync/backup service (try upload, if fail download, merge, upload)
6) sync --reserve $AMOUNT: reserve $AMOUNT money (in the respective currency) for *this* wallet
7) sync --leave ($AMOUNT)* leave the sync group, taking $AMOUNT funds out of the joint funds. $AMOUNT may be
   specified multiple times for different currencies.

Let me know if something is unclear, or extend/add to the list in case I missed something.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0016834)
Florian Dold   
2020-09-04 09:06   
The CLI for this looks mostly good to me (modulo questions below). Except that the "--..." options should actually subcommands. But that's a pervasive usability problem in many binaries of GNUnet and Taler, because the library we use in C for CLI parsing doesn't handle subcommands nicely </rant>.

Regarding starting the implementation of sync: what we actually need is primarily the wallet-core JSON API for all those things. I'll write these docs after we've clarified some other issues. The CLI will follow from that.

# 1. Balances

1.1 How does this affect the balance, both in terms of API and UI? WIll we only show the "reserved" amount?
1.2 Do balances now need to include some timestamp(s) that show how current they are? Sync otherwise might lead users into thinking they have more money than they actually do ...
1.3. How does this affect the coin selection for payments? What happens if the current wallet's reserved balance is too low, but the sync group's balance is high enough to pay?

# 2. Funds reservation

2.1 Does the funds reservation imply a sync, or is it only done locally? Do other devices somehow acknowledge the reservation?

# 3. Device identifiers and encryption

3.1. I'm assuming in the first implementation, a "rogue" device won't be able to be kicked out of the sync group, right? So we don't do any encryption with the some per-device key, we just use the sync key.

# 4. Payments

4.1. Does the user need to confirm the payment to create the sync group? What if the contract terms contain a different amount than what's advertised by the sync server?
4.2. Does the user need to confirm subsequent payments for the sync server to extend the service duration?
4.3. What happens if two wallets in a sync group pay to extend the sync service? Will the 402 always give the same order (=> other wallets receive "order already claimed)?
(0016836)
Christian Grothoff   
2020-09-04 10:06   
1.1: sync may cost money, if it does, it's a purchase.
1.2: I'd say no. We could store the # devices in the sync group, and if >1 we could do a GET request against the sync service at a reasonable frequency (say on Wallet start, unless started "just before"?). I'd not show a timestamp.
1.3: We grab from the sync group and POST to sync as soon as possible (but after the payment)
(0016837)
Florian Dold   
2020-09-04 11:38   
Regarding 1.1: This question wasn't related to how the *payment* for sync will show up, but how being in a sync group will affect the balance that is shown. Or to rephrase the question: How will reserving funds from the sync group affect the balance display?

Will it even affect the balance display / API response, or is it an internal thing completely transparent to the user, and just used to reduce (not completely prevent!) spending conflicts?
(0016838)
Christian Grothoff   
2020-09-04 12:55   
1.1: I'd say not at all. We should show the overall balance, sync groups should be managed "behind the scenes".
(0016849)
Christian Grothoff   
2020-09-04 14:49   
2.1: Funds reservation is 'soft' anyway, it just means that a wallet will preferentially spend certain coins over others. So I would say any wallet in a sync group can 'grab' a coin (or even assign it to another wallet in the sync group, i.e. on withdrawal), and the latest grab counts (so grabs must have: coin_pub + wallet_id + timestamp). I'd treat grabs like any other wallet-operation (withdraw, pay, refresh) in terms of sync behavior: randomized reduction in the time to the next backup per operation might be a reasonable strategy.

3.1: Why not have a header (encrypted with sync key) that has a list of all participating wallets and then a backup key encrypted *to* all wallet private keys, followed by the actual wallet data encrypted with the backup key? Sounds not too hard, and why not do it right immediately?

4.1a: Yes, but simply have the normal dialog contain the word "confirm payment" in the button and the amount next to it. No need for a 'full' regular pay dialog IMO.
4.1b: That's a protocol violation. Treat it as such and tell the user the sync server failed to respond properly.

4.2: I'd have a checkbox 'auto-renew'. If payment is not possible OR if auto-renew is off, 1 month before expiration we should have an alert on the main screen about the impending expiration of the backup enabling manual renewal.

4.3: We should always force a sync between auto-renew claiming and payment to prevent this. The sync server cannot tell if you want to extend by +1 year, so it will create a fresh order. So simply claim, sync, and if you do not find another claimed order in the DB, then pay (or pay the earliest claimed order in the freshly sync'ed DB).
(0016856)
Florian Dold   
2020-09-04 16:34   
2.1. brings me to the crypto. Why not just use a HKDF and libnacl/libsodium crypto_(secret)box? Pulling in AES (and using it in what mode? ;-) ) will add more, potentially unaudited dependencies and is *much* easier to use incorrectly.
(0016862)
Christian Grothoff   
2020-09-05 00:14   
2.1: nothing against HKDF+cryptobox for the 'inner layer', but we need some 'outer layer' to allow adding/removing wallets from the sync group, including telling a wallet that it has been removed. So I don't think we can do without some DH between each group member's private key and some ephemeral key chosen by the last wallet to publish the backup.
(0016958)
Florian Dold   
2020-09-10 08:09   
After thinking about it some more: How would the per-wallet key work with Anastasis? Isn't that fundamentally incompatible?
(0016959)
Christian Grothoff   
2020-09-10 09:19   
(Last edited: 2020-09-10 09:22)
Easy solution: Imagine W1 / W2 / W3 are the per-wallet keys and A is the Anastasis key (A_priv in Anastasis) and the actual symmetric encryption key of the main wallet state is K.

Then, we could store W1_pub, W2_pub, W3_pub, A_pub and an _encrypted_ K in the sync data preamble encrypted with DH(W1,A), DH(W2,A), DH(W3,A).

Note that K can here not change on every encryption, so we'd need an additional IV (or IMO better: salt and KDF via salt) before encryption with traditional AEAD/GCM.

Kicking a wallet out of the device group requires changing K, and so a new Anastasis policy upload. But that is rare and thus should be Anastasis-compatible.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7818 [Taler] wallet-core feature always 2023-04-24 07:49 2023-08-24 16:27
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: fractionalBaseDigits of currencies
Description: Most currencies in the world have two digits after the decimal point/comma - but some have three (most arabian countries: Bahraini Dinar, Iraqi Dinar, Jordanian Dinar, Kuwaiti Dinar, Libyan Dinar, Rial Omani, Tunisian Dinar) and some have none (Indonesian Rupiah, Japanese Yen, South-Korean Won, Vietnamese New Dong, Cape Verdi Escudo, Paraguay Guarani, and a few african and caribbean countries).

When querying for exchanges, the data returned should not only tell the name of the currency:
    var exchangeBaseUrl: String
    var currency: String?
but also the fractionalBaseDigits:
    var fractionalBaseDigits: UInt?

There are 3 possible wallet-core calls where that information could be returned:
1) ListExchangesOp
2) GetExchangeDetailedInfoOp
3) ListCurrenciesOp

Sebastian wrote about using denominations to find out what amount might be possible to send, but fractionalBaseDigits are needed to display amounts correctly in balances and transaction views, especially whole numbers which might still need to be shown with decimal delimiter and fractional digits (.00, .000, ...).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7598 [Taler] wallet-core minor have not tried 2023-01-18 18:34 2023-08-24 16:25
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: review and revise backup APIs
Description: Points to discuss:

* It's unclear whether the "provisional" state of providers makes sense. Instead of a provisional "addBackupProvider", should we have some "checkBackupProvider" that just returns the fees and is state-less regarding the wallet DB?

* It's not clear whether the semantics current return type of addBackupProvider makes sense. The operation should either be successful or not, but it currently returns whether the provider requires a payment. It also internally tries to start a first backup cycle, which I'm not sure makes sense, especially since it is waiting for the backup cycle to complete *before* addBackupProvider even returns a response
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6614 [Taler] wallet-core tweak have not tried 2020-10-01 15:21 2023-08-24 16:25
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: consider using JSON-RPC instead of custom, slightly different format
Description: We are currently using a format for the wallet-core RPC that is *almost* the same as JSON-RPC. There are very few syntactic differences.

Maybe it's worth to iron out these differences and use the JSON-RPC naming conventions?

https://en.wikipedia.org/wiki/JSON-RPC
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6505 [Taler] wallet-core text have not tried 2020-08-21 17:50 2023-08-24 16:24
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: define UX and API for "global errors/notifications"
Description: Global errors/notifications are events that need user attention and/or that aren't displayed in a transaction list item.

Examples:
* backup/sync failed (with >N retries)
* money lost due to recoup
  * (Should this be a transaction instead?! => it could *also* be a transaction)
* refresh (after pay) fails for too long
 * (Should maybe also be a transaction? => no)
* Exchange master public key changes, so refresh becomes impossible unless the new public key is audited or directly trusted/accepted.
* Wallet DB state inconsistencies that indicate some bug / corruption

To prevent spammy notifications / thrashing, every global error/notification should get some ID based on the type of the problem and the underlying resource.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019178)
sebasjm   
2022-09-23 20:56   
Is this the same as WebEx pending operations? They are shown as a header on the top of the wallet popup.

It is designed to hold up to 3 elements of any type and clicking them will lead you to the pending transaction (or maybe the screen to solve the problem / find more information). I'm worried that 3 elements may not be enough.
(0019192)
Florian Dold   
2022-09-27 19:23   
I think the answer is "it depends". For refreshes, I can see that we can integrate them into the pending transactions.

However, for stuff like "your backup isn't working", this is not really a transaction. It doesn't have a currency and amount associated with it. But it should probably be rendered "in the vicinity" of where we show pending transactions. Or maybe even more prominently? I'm not sure!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6582 [Taler] wallet-core feature have not tried 2020-09-07 11:53 2023-08-24 16:24
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: checking for refunds of a purchase should be possible from within the wallet
Description: ... and not just from the merchant's QR code page.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7297 [Taler] wallet-core feature always 2022-08-09 17:13 2023-08-24 16:24
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: add extension enabled into exchange info/database
Description: Maybe in `updateExchangeFromUrlImpl()` and add info to `ExchangeDetailsRecord`

interface ExchangeDetailsRecord {
 ...
 extensions: Extension[]
}

using the definition of extension from
https://docs.taler.net/design-documents/006-extensions.html

This will allow the wallet WebEx to know if it should render the ageRestriction selectBox or not based on the exchange capabilities.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019003)
sebasjm   
2022-08-10 16:37   
nice to have, but not yet needed


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6039 [Taler] wallet-core tweak have not tried 2020-01-07 21:33 2023-08-24 16:23
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: consider using underscores for the "public API" exposed by wallet-core
Description: To make naming conventions consistent with other Taler JSON formats, we should consider moving to underscores in the history and pending operations.

Historically the JSON generated by the wallet uses camelCase, since that's the most common convention for writing JavaScript code.

Maybe we can take the route used by GSON (the JSON mapping library for Java (not JavaScript!)) and map to underscores only when (de-)serializing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020009)
Florian Dold   
2023-04-04 15:51   
Migration cost at this point is too high.

Maybe later we can add some automated conversion like some Java JSON binding libraries do.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7922 [Taler] wallet-core major have not tried 2023-08-22 19:16 2023-08-23 09:59
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: processPeerPullDebitAbortingRefresh: logic invariant failed
Description: 2023-08-22T13:37:25.570Z wallet.ts INFO running task peer-pull-debit:5GXR5P1E76YAEEDSSGDJ7Q1EQ9QRYYR7RAG03VQFJJ7PDR4CH5DG

Possibly unhandled promise rejection: Error: BUG: logic invariant failed

    at checkLogicInvariant (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:15380)

    at processPeerPullDebitAbortingRefresh (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:32210)

    at processPeerPullDebit (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:32255)


2023-08-22T13:37:25.580Z operations/common.ts ERROR Uncaught exception: BUG: logic invariant failed

2023-08-22T13:37:25.580Z operations/common.ts ERROR Stack: at checkLogicInvariant (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:15380)

    at processPeerPullDebitAbortingRefresh (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:32210)

    at processPeerPullDebit (/Users/ms/Developer/gnuTaler/quickjs-tart/taler-wallet-core-qjs.mjs:32255)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020425)
Florian Dold   
2023-08-22 19:17   
Likely a logic issue in the abort code path of peer-pull-debit transactions.
(0020426)
MarcS   
2023-08-23 09:59   
This DB was last used 2 weeks ago, the aborting p2p transaction was set to 1 week expiration so it was now already expired, too.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7903 [Taler] wallet-core minor have not tried 2023-08-03 20:54 2023-08-21 18:09
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: expose details about the amount lost (or final effective cost) after aborting transactions
Description: Currently when aborting transactions, the effective and raw amounts don't change. That doesn't reflect reality.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020421)
Florian Dold   
2023-08-21 18:09   
Discussed at the retreat: There should be a amountEffectiveFinal that reflects the actual effect on the balance after the transaction is in a final state.

The amountEffective will still reflect the amountEffective that was initially shown to the user when they confirmed the transaction.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7917 [Taler] exchange feature N/A 2023-08-11 16:40 2023-08-11 16:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: none OS Version: squeeze  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: change applicablility of refresh fees
Description: We may want to consider only charging a refresh fee if the target denomination is for the same amount, effectively waiving the refresh fee when getting change or refunds. This would make the STEFAN proposal (DD47) more effective and fees more predictable. This will require non-trivial changes to the exchange and auditor. There is zero impact on production systems as long as they use a refresh fee of 0 (as suggested for now).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7916 [Taler] wallet-core feature N/A 2023-08-11 16:37 2023-08-11 16:37
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: support STEFAN parameters
Description: The exchange /keys response now contains stefan_abs, stefan_log and stefan_lin as per DD47. The wallet (core) should compute fees according to the STEFAN curve and pass the values to the UIs.

The wallet should also add code to compute default STEFAN curve values from the fee structure. A CLI command should output these values given an exchange base URL. The exchange configuration documentation should be updated to explain when and how to run the tool.

The computation could also be used by the UIs if a user requests a fee comparison to protect users against exchanges with dishonest STEFAN values. However, the computation MAY be to expensive to run on a regular basis by the wallet (TBD). Exchanges MAY also be configured with higher STEFAN values than those obtained from the wallet directly.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7904 [GNUnet] messenger service minor N/A 2023-08-06 14:54 2023-08-06 22:20
Reporter: Blackadder Platform: x86_64  
Assigned To: thejackimonster OS: Linux  
Priority: normal OS Version: 5.14.21  
Status: assigned Product Version: 0.19.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Flathub: GNUnet Messenger (Messenger-GTK) flatpak is still v0.7.0
Description: The "GNUnet Messenger" flatpak offered at flathub is still based on Messenger-GTK v0.7.0, although Messenger-GTK v0.8.0 was already released 6 months ago:

https://flathub.org/en/apps/org.gnunet.Messenger
Tags: flathub, flatpak
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020413)
thejackimonster   
2023-08-06 22:20   
The issue is only visually because flathub.org and the store use file under "resources/org.gnunet.Messenger.appdata.xml" from the repository to show metadata of the package as well as the version. However I didn't update that file before tagging the release of 0.8.0. So the file still shows 0.7.0.

The flatpak however does still contain all changes from the release 0.8.0. Next release hopefully I don't mess up the process. ^^'


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7404 [GNUnet] namestore service tweak have not tried 2022-10-19 09:09 2023-08-06 19:03
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Namestore REST DELETE whole zone
Description: We may want to permit DELETE /namestore/$ZONE as well, to delete the
entire zone.

Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7403 [GNUnet] namestore service tweak have not tried 2022-10-19 09:07 2023-08-06 19:03
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Fix NAMESTORE REST POST/PUT and add PATCH
Description: GET /namestore/$ZNAME

Should return an ETag set to the hash of the record set (see below).


POST /namestore/$ZNAME

is not ideal, as it doesn't allow the client to ensure that it didn't
accidentally (!) change an existing record. I would use POST only to create a
new resource (and fail with 409 conflict if the given name already exists).
You could also just use POST /namestore/$ZONE/$LABEL for this and not have the
label in the record set. Then, for updates, we should use PATCH
/namestore/$ZONE/$LABEL. PATCH should use If-not-modified with the ETag from
the GET to make the operation atomic: if someone else did a PATCH since the
GET, the PATCH would fail. A client could then set the If-not-modified header
to ensure atomic updates, or omit it to override whatever record is there
without worrying about atomicity. PATCH without If-not-modified would then
also give you UPSERT (update and if not exists insert)
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7199 [GNUnet] hostlist daemon minor have not tried 2022-03-18 23:19 2023-08-06 19:03
Reporter: schanzen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0.0  
Summary: Hostlist requests should include compatible hello version
Description: We have a hostlist URL mess with unclear naming convention there. e.g. the handbook says v10.gnunet.org/hostlist

Plan:
Move hostlist default config and peer setup to
http://gnunet.org/hostlist?hello_version=<hello_version>
Or maybe put the hello version in a header a la
GNUnet-HelloVersion: Int

Services (should at some point) negotiate compatible versions.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7198 [GNUnet] hello library minor have not tried 2022-03-18 23:16 2023-08-06 19:02
Reporter: schanzen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0.0  
Summary: Implement versioning for HELLOs
Description: e.g.

#define GNUNET_PROTOCOL_VERSION 15

The versions can then be used in the hostlist lookup as well.
The version numbers should be independent of the gnunet version
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7589 [GNUnet] DHT service major always 2023-01-15 06:20 2023-08-06 19:02
Reporter: ulfvonbelow Platform: x86-64  
Assigned To: schanzen OS: Guix System  
Priority: normal OS Version: Jan 5 2023  
Status: assigned Product Version: 0.19.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.20.0  
Summary: gnunet-service-dht is constantly at 100% CPU utilization
Description: While gnunet is running, 'top' reports 100% CPU utilization for gnunet-service-dht. This persists even after I leave it running for a day, so it doesn't seem to be something that only happens when the peer is first created. I don't know how related it is, but 'top' also reports '20t' as the virtual memory usage for every gnunet service, which seems rather strange.

Quote shamelessly taken out of context from the testbed documentation: "On a single affordable computer, it should be possible to run around tens of peers without drastically increasing the load on the system."
Tags: bug, ngi-entrust-2022-08-104, performance
Steps To Reproduce: 1. Get a guix checkout from around Jan 5 on a running guix system
2. Apply the attached patches
3. Reconfigure system with a gnunet service with the attached gnunet.conf (adjust to indicate your own external IP)
4. Run 'top'
5. Observe that gnunet-service-dht is hogging the CPU like mad
Additional Information: My /etc/gnunet.conf seems relatively normal, I've attached it with some minor redactions. Basically just setting up some paths, and logging, selecting tcp, http_client, and https_client as the transport plugins to use, specifying HOLE_EXTERNAL, and disabling IPv6.

My guix repository includes some extra commits on top of guix master that I rebase every once in awhile - I last rebased on January 5. I modified the gnunet package definition and added a gnunet service to try to enable full functionality. I'll include the relevant patches on top of guix to get that package and service definition. Noteworthy is that I didn't enable the test suite because 0.19.2 and the past 10 versions or so I've tried all have tests that make assumptions that fail in guix's build environment in relation to network namespaces. It's only usually one test, though. I'm currently using Linux 6.1.2 from the nonguix channel, though I don't think that makes much difference compared to linux-libre in this case.

My CPU is an AMD A10-5800k from 2012 or so. I think this fits within the realm of devices gnunet should be able to run decently on.
Attached Files: 0001-gnu-setuid-add-setuid-program-base-perms-field-to-se.patch (4,432 bytes) 2023-01-15 06:20
https://bugs.gnunet.org/file_download.php?file_id=1297&type=bug
update-gnunet-and-add-service.patch (14,913 bytes) 2023-01-15 06:21
https://bugs.gnunet.org/file_download.php?file_id=1298&type=bug
gnunet.conf (609 bytes) 2023-01-15 06:22
https://bugs.gnunet.org/file_download.php?file_id=1299&type=bug
gdb-backtraces (18,246 bytes) 2023-01-17 03:28
https://bugs.gnunet.org/file_download.php?file_id=1303&type=bug
Notes
(0019666)
ulfvonbelow   
2023-01-15 06:21   
Apparently I can only upload one file per post, so here's 2/3
(0019667)
ulfvonbelow   
2023-01-15 06:22   
3/3
(0019678)
Christian Grothoff   
2023-01-16 09:41   
What does
$ gnunet-statistics -s dht
say?
Ideally report twice, with a few minutes wait in between. Maybe the DHT is indeed processing tons of requests? I'm not seeing excessive DHT load on my end, but if someone is currently importing millions of records into GNS (say all of ".fr") and few peers are running, some might be hit with a bit much signature verification work. At least that's one possible theory, but would be good to first identify the source of the high CPU load on your system.

Attaching gdb and getting a few stack traces (to the process with the high CPU load) or generating a flamegraph could all also help to find out where the load is coming from. On my systems, load right now is not very high at all.
(0019679)
Christian Grothoff   
2023-01-16 10:42   
I just checked, and it looks like we're currently importing 250k records from ".se" into GNS/DHT. This alone results (for some reason, likely the frequency is excessively high due to configuration failures or bugs) in 38 million (!) DHT PUT operations per day. I suspect your older CPU is not quite able to validate it's share of cryptographic signatures, hence the 100% CPU load. The real bug is probably related to the logic or configuration for importing ".se".
(0019680)
schanzen   
2023-01-16 13:46   
Isn't the real bug that our server is DoSing this client??
(0019681)
schanzen   
2023-01-16 13:48   
Oh and can you open another issue for the packagin packages please with detailed descriptions on what they do? We are happy to include packaging stuff.
(0019686)
ulfvonbelow   
2023-01-17 03:28   
$ gnunet-statistics -s dht && sleep 60 && echo && gnunet-statistics -s dht
          dht # P2P GET bytes received: 1912
          dht # PUT requests received from clients: 5
          dht # P2P PUT requests received: 4436
          dht # Local PUT requests not routed: 5
          dht # GET requests given to datacache: 2
          dht # Entries added to routing table: 7
          dht # P2P HELLO lookup requests processed: 3
          dht # P2P GET requests received: 7
          dht # peers connected: 5
          dht # FIND PEER messages initiated: 1
          dht # P2P PUT bytes received: 2250912
          dht # requests TTL-dropped: 24
          dht # ITEMS stored in datacache: 4441
          dht # PUT messages queued for transmission: 2484
          dht # P2P GET requests ONLY routed: 2
          dht # REPLIES ignored for CLIENTS (no match): 4441
          dht # messages dropped (underlays busy): 1927
          dht # GET messages queued for transmission: 8
          dht # PUT requests routed: 4441
          dht # Peer selection failed: 2311
          dht # GET requests routed: 8
          dht # RESULT messages queued for transmission: 3
          dht # DHT requests combined: 1
          dht # Network size estimates received: 3

          dht # P2P GET bytes received: 2148
          dht # PUT requests received from clients: 5
          dht # P2P PUT requests received: 10400
          dht # Local PUT requests not routed: 5
          dht # GET requests given to datacache: 2
          dht # Entries added to routing table: 8
          dht # P2P HELLO lookup requests processed: 3
          dht # P2P GET requests received: 8
          dht # peers connected: 5
          dht # FIND PEER messages initiated: 1
          dht # P2P PUT bytes received: 5302720
          dht # requests TTL-dropped: 24
          dht # ITEMS stored in datacache: 10405
          dht # PUT messages queued for transmission: 7068
          dht # P2P GET requests ONLY routed: 3
          dht # REPLIES ignored for CLIENTS (no match): 10405
          dht # messages dropped (underlays busy): 6362
          dht # GET messages queued for transmission: 9
          dht # PUT requests routed: 10405
          dht # Peer selection failed: 4354
          dht # GET requests routed: 9
          dht # RESULT messages queued for transmission: 3
          dht # DHT requests combined: 1
          dht # Network size estimates received: 3

It looks like that comes out to around 99.4 PUT requests received per second. If you're putting out 38 million per day, that's 439 per second, so a little under 1/4 of them (not taking other PUTers into account) are ending up at my peer. Small world so far, I guess.

I don't know how to generate that flame graph you mentioned, so I've attached a random sampling of a few gdb backtraces.
(gdb) bt
#0 0x00007fb1da22b034 in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#1 0x00007fb1da2acb04 in free ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#2 0x00007fb1d98ef198 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#3 0x00007fb1d99ad12a in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#4 0x00007fb1d99ad4d3 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#5 0x00007fb1d99b4437 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#6 0x00007fb1d99b7156 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#7 0x00007fb1d998054d in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#8 0x00007fb1d9979aa9 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#9 0x00007fb1d9900832 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#10 0x00007fb1d98ec9ae in gcry_pk_verify ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#11 0x00007fb1d9c4ee01 in GNUNET_CRYPTO_ecdsa_verify_ (purpose=15,
    validate=0x61200005c2c0, sig=0x62f000006d28, pub=0x62f000006d08)
    at crypto_ecc.c:682
#12 0x00007fb1d577a3b9 in GNUNET_GNSRECORD_block_verify (block=0x62f000006d00)
    at gnsrecord_crypto.c:708
#13 0x00007fb1d57b9dde in block_plugin_gns_check_block (cls=0x0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000006d00, block_size=368)
    at plugin_block_gns.c:197
#14 0x00007fb1da0351da in GNUNET_BLOCK_check_block (ctx=0x60300000b1d0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000006d00, block_size=368)
    at block.c:329
#15 0x0000559ffd8991f1 in handle_dht_p2p_put (cls=0x606000232b80,
    put=0x62f000006c28) at gnunet-service-dht_neighbours.c:2000
#16 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x7ffdd3e4a890,
    mh=0x62f000006c28) at mq.c:242
#17 0x0000559ffd8a10eb in GDS_u_receive (cls=0x60b000004a80, tctx=0x60800000ed20,
    sctx=0x608000009020, message=0x62f000006c28, message_size=584)
    at gnunet-service-dht_neighbours.c:2836
#18 0x00007fb1d571baab in handle_core_message (cls=0x60800000ed20,
    msg=0x62f000006c24) at plugin_dhtu_gnunet.c:515
#19 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x6060002b2d40,
    mh=0x62f000006c24) at mq.c:242
#20 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000042880,
    mh=0x62f000006c24) at mq.c:192
#21 0x00007fb1da198b0d in handle_notify_inbound (cls=0x60c000000a00,
    ntm=0x62f000006c00) at core_api.c:574
#22 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x610000001540,
    mh=0x62f000006c00) at mq.c:242
#23 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000000b80,
    mh=0x62f000006c00) at mq.c:192
#24 0x00007fb1d9be6f06 in recv_message (cls=0x60d0000006c0, msg=0x62f000006c00)
    at client.c:347
#25 0x00007fb1d9ca44d4 in GNUNET_MST_from_buffer (mst=0x60400000f990, buf=0x0,
    size=0, purge=0, one_shot=0) at mst.c:222
#26 0x00007fb1d9ca5e84 in GNUNET_MST_read (mst=0x60400000f990,
    sock=0x60300000d9f0, purge=0, one_shot=0) at mst.c:367
#27 0x00007fb1d9be8784 in receive_ready (cls=0x60d0000006c0) at client.c:447
#28 0x00007fb1d9cf7663 in GNUNET_SCHEDULER_do_work (sh=0x606000007be0)
    at scheduler.c:2107
#29 0x00007fb1d9cf9fa0 in select_loop (sh=0x606000007be0, context=0x7ffdd3e4af90)
    at scheduler.c:2412
#30 0x00007fb1d9ce8649 in GNUNET_SCHEDULER_run (
    task=0x7fb1d9d01f94 <service_main>, task_cls=0x7ffdd3e4b240) at scheduler.c:710
#31 0x00007fb1d9d105c1 in GNUNET_SERVICE_run_ (argc=11, argv=0x7ffdd3e4bab8,
    service_name=0x559ffd8a6180 "dht", options=GNUNET_SERVICE_OPTION_NONE,
    service_init_cb=0x559ffd885b78 <run>,
    connect_cb=0x559ffd8739b0 <client_connect_cb>,
    disconnect_cb=0x559ffd873af5 <client_disconnect_cb>, cls=0x0,
    handlers=0x7ffdd3e4b820) at service.c:2136
#32 0x0000559ffd88694f in main (argc=11, argv=0x7ffdd3e4bab8)
    at gnunet-service-dht.c:540
(gdb) continue
Continuing.
  C-c C-c
Program received signal SIGINT, Interrupt.
0x00007fb1da22ef3c in ?? () from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
(gdb) bt
#0 0x00007fb1da22ef3c in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#1 0x00007fb1da22f3e6 in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#2 0x00007fb1da22f59f in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#3 0x00007fb1da22b363 in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#4 0x00007fb1da2acb04 in free ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#5 0x00007fb1d98ef198 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#6 0x00007fb1d99ad12a in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#7 0x00007fb1d99ad4d3 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#8 0x00007fb1d99b57b7 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#9 0x00007fb1d99b7137 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#10 0x00007fb1d998057c in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#11 0x00007fb1d9979aa9 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#12 0x00007fb1d9900832 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#13 0x00007fb1d98ec9ae in gcry_pk_verify ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#14 0x00007fb1d9c4ee01 in GNUNET_CRYPTO_ecdsa_verify_ (purpose=15,
    validate=0x60d00001a1e0, sig=0x62f000006968, pub=0x62f000006948)
    at crypto_ecc.c:682
#15 0x00007fb1d577a3b9 in GNUNET_GNSRECORD_block_verify (block=0x62f000006940)
    at gnsrecord_crypto.c:708
#16 0x00007fb1d57b9dde in block_plugin_gns_check_block (cls=0x0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000006940, block_size=240)
    at plugin_block_gns.c:197
#17 0x00007fb1da0351da in GNUNET_BLOCK_check_block (ctx=0x60300000b1d0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000006940, block_size=240)
    at block.c:329
#18 0x0000559ffd8991f1 in handle_dht_p2p_put (cls=0x6060000097a0,
    put=0x62f000006868) at gnunet-service-dht_neighbours.c:2000
#19 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x7ffdd3e4a890,
    mh=0x62f000006868) at mq.c:242
#20 0x0000559ffd8a10eb in GDS_u_receive (cls=0x60b000004a80, tctx=0x60800000aea0,
    sctx=0x608000009020, message=0x62f000006868, message_size=456)
    at gnunet-service-dht_neighbours.c:2836
#21 0x00007fb1d571baab in handle_core_message (cls=0x60800000aea0,
    msg=0x62f000006864) at plugin_dhtu_gnunet.c:515
#22 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x606000009740,
    mh=0x62f000006864) at mq.c:242
#23 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000009340,
    mh=0x62f000006864) at mq.c:192
#24 0x00007fb1da198b0d in handle_notify_inbound (cls=0x60c000000a00,
    ntm=0x62f000006840) at core_api.c:574
#25 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x610000001540,
    mh=0x62f000006840) at mq.c:242
#26 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000000b80,
    mh=0x62f000006840) at mq.c:192
#27 0x00007fb1d9be6f06 in recv_message (cls=0x60d0000006c0, msg=0x62f000006840)
    at client.c:347
#28 0x00007fb1d9ca44d4 in GNUNET_MST_from_buffer (mst=0x60400000f990, buf=0x0,
    size=0, purge=0, one_shot=0) at mst.c:222
#29 0x00007fb1d9ca5e84 in GNUNET_MST_read (mst=0x60400000f990,
    sock=0x60300000d9f0, purge=0, one_shot=0) at mst.c:367
#30 0x00007fb1d9be8784 in receive_ready (cls=0x60d0000006c0) at client.c:447
#31 0x00007fb1d9cf7663 in GNUNET_SCHEDULER_do_work (sh=0x606000007be0)
    at scheduler.c:2107
#32 0x00007fb1d9cf9fa0 in select_loop (sh=0x606000007be0, context=0x7ffdd3e4af90)
    at scheduler.c:2412
#33 0x00007fb1d9ce8649 in GNUNET_SCHEDULER_run (
    task=0x7fb1d9d01f94 <service_main>, task_cls=0x7ffdd3e4b240) at scheduler.c:710
#34 0x00007fb1d9d105c1 in GNUNET_SERVICE_run_ (argc=11, argv=0x7ffdd3e4bab8,
    service_name=0x559ffd8a6180 "dht", options=GNUNET_SERVICE_OPTION_NONE,
    service_init_cb=0x559ffd885b78 <run>,
    connect_cb=0x559ffd8739b0 <client_connect_cb>,
    disconnect_cb=0x559ffd873af5 <client_disconnect_cb>, cls=0x0,
    handlers=0x7ffdd3e4b820) at service.c:2136
#35 0x0000559ffd88694f in main (argc=11, argv=0x7ffdd3e4bab8)
    at gnunet-service-dht.c:540
(gdb) continue
Continuing.
  C-c C-c
Program received signal SIGINT, Interrupt.
0x00007fb1d99b1632 in ?? () from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
(gdb) bt
#0 0x00007fb1d99b1632 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#1 0x00007fb1d99ad096 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#2 0x00007fb1d99ad4d3 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#3 0x00007fb1d99b42f7 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#4 0x00007fb1d99b7156 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#5 0x00007fb1d998054d in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#6 0x00007fb1d9979aa9 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#7 0x00007fb1d9900832 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#8 0x00007fb1d98ec9ae in gcry_pk_verify ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#9 0x00007fb1d9c4ee01 in GNUNET_CRYPTO_ecdsa_verify_ (purpose=15,
    validate=0x61200005f140, sig=0x62f000007858, pub=0x62f000007838)
    at crypto_ecc.c:682
#10 0x00007fb1d577a3b9 in GNUNET_GNSRECORD_block_verify (block=0x62f000007830)
    at gnsrecord_crypto.c:708
#11 0x00007fb1d57b9dde in block_plugin_gns_check_block (cls=0x0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000007830, block_size=368)
    at plugin_block_gns.c:197
#12 0x00007fb1da0351da in GNUNET_BLOCK_check_block (ctx=0x60300000b1d0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f000007830, block_size=368)
    at block.c:329
#13 0x0000559ffd8991f1 in handle_dht_p2p_put (cls=0x6060000097a0,
    put=0x62f000007758) at gnunet-service-dht_neighbours.c:2000
#14 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x7ffdd3e4a890,
    mh=0x62f000007758) at mq.c:242
#15 0x0000559ffd8a10eb in GDS_u_receive (cls=0x60b000004a80, tctx=0x60800000aea0,
    sctx=0x608000009020, message=0x62f000007758, message_size=584)
    at gnunet-service-dht_neighbours.c:2836
#16 0x00007fb1d571baab in handle_core_message (cls=0x60800000aea0,
    msg=0x62f000007754) at plugin_dhtu_gnunet.c:515
#17 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x606000009740,
    mh=0x62f000007754) at mq.c:242
#18 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000009340,
    mh=0x62f000007754) at mq.c:192
#19 0x00007fb1da198b0d in handle_notify_inbound (cls=0x60c000000a00,
    ntm=0x62f000007730) at core_api.c:574
#20 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x610000001540,
    mh=0x62f000007730) at mq.c:242
#21 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000000b80,
    mh=0x62f000007730) at mq.c:192
#22 0x00007fb1d9be6f06 in recv_message (cls=0x60d0000006c0, msg=0x62f000007730)
    at client.c:347
#23 0x00007fb1d9ca44d4 in GNUNET_MST_from_buffer (mst=0x60400000f990, buf=0x0,
    size=0, purge=0, one_shot=0) at mst.c:222
#24 0x00007fb1d9ca5e84 in GNUNET_MST_read (mst=0x60400000f990,
    sock=0x60300000d9f0, purge=0, one_shot=0) at mst.c:367
#25 0x00007fb1d9be8784 in receive_ready (cls=0x60d0000006c0) at client.c:447
#26 0x00007fb1d9cf7663 in GNUNET_SCHEDULER_do_work (sh=0x606000007be0)
    at scheduler.c:2107
#27 0x00007fb1d9cf9fa0 in select_loop (sh=0x606000007be0, context=0x7ffdd3e4af90)
    at scheduler.c:2412
#28 0x00007fb1d9ce8649 in GNUNET_SCHEDULER_run (
    task=0x7fb1d9d01f94 <service_main>, task_cls=0x7ffdd3e4b240) at scheduler.c:710
#29 0x00007fb1d9d105c1 in GNUNET_SERVICE_run_ (argc=11, argv=0x7ffdd3e4bab8,
    service_name=0x559ffd8a6180 "dht", options=GNUNET_SERVICE_OPTION_NONE,
    service_init_cb=0x559ffd885b78 <run>,
    connect_cb=0x559ffd8739b0 <client_connect_cb>,
    disconnect_cb=0x559ffd873af5 <client_disconnect_cb>, cls=0x0,
    handlers=0x7ffdd3e4b820) at service.c:2136
#30 0x0000559ffd88694f in main (argc=11, argv=0x7ffdd3e4bab8)
    at gnunet-service-dht.c:540
(gdb) continue
Continuing.
  C-c C-c
Program received signal SIGINT, Interrupt.
0x00007fb1da22db5f in ?? () from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
(gdb) bt
#0 0x00007fb1da22db5f in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#1 0x00007fb1da22a70c in ?? ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#2 0x00007fb1da2acfdd in calloc ()
   from /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libasan.so.6
#3 0x00007fb1d9c63347 in w_malloc (n=32) at crypto_random.c:344
#4 0x00007fb1d98ee78d in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#5 0x00007fb1d98efe7d in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#6 0x00007fb1d99b2d55 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#7 0x00007fb1d99ad02f in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#8 0x00007fb1d99ad4d3 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#9 0x00007fb1d99b42f7 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#10 0x00007fb1d99b7156 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#11 0x00007fb1d998057c in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#12 0x00007fb1d9979aa9 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#13 0x00007fb1d9900832 in ?? ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#14 0x00007fb1d98ec9ae in gcry_pk_verify ()
   from /gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8/lib/libgcrypt.so.20
#15 0x00007fb1d9c4ee01 in GNUNET_CRYPTO_ecdsa_verify_ (purpose=15,
    validate=0x60d0000059a0, sig=0x62f00000a2a8, pub=0x62f00000a288)
    at crypto_ecc.c:682
#16 0x00007fb1d577a3b9 in GNUNET_GNSRECORD_block_verify (block=0x62f00000a280)
    at gnsrecord_crypto.c:708
#17 0x00007fb1d57b9dde in block_plugin_gns_check_block (cls=0x0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f00000a280, block_size=240)
    at plugin_block_gns.c:197
#18 0x00007fb1da0351da in GNUNET_BLOCK_check_block (ctx=0x60300000b1d0,
    type=GNUNET_BLOCK_TYPE_GNS_NAMERECORD, block=0x62f00000a280, block_size=240)
    at block.c:329
#19 0x0000559ffd8991f1 in handle_dht_p2p_put (cls=0x60600007d4e0,
    put=0x62f00000a1a8) at gnunet-service-dht_neighbours.c:2000
#20 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x7ffdd3e4a890,
    mh=0x62f00000a1a8) at mq.c:242
#21 0x0000559ffd8a10eb in GDS_u_receive (cls=0x60b000004a80, tctx=0x60800001ffa0,
    sctx=0x608000009020, message=0x62f00000a1a8, message_size=456)
    at gnunet-service-dht_neighbours.c:2836
#22 0x00007fb1d571baab in handle_core_message (cls=0x60800001ffa0,
    msg=0x62f00000a1a4) at plugin_dhtu_gnunet.c:515
#23 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x60600007d540,
    mh=0x62f00000a1a4) at mq.c:242
#24 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000033f40,
    mh=0x62f00000a1a4) at mq.c:192
#25 0x00007fb1da198b0d in handle_notify_inbound (cls=0x60c000000a00,
    ntm=0x62f00000a180) at core_api.c:574
#26 0x00007fb1d9ca68f2 in GNUNET_MQ_handle_message (handlers=0x610000001540,
    mh=0x62f00000a180) at mq.c:242
#27 0x00007fb1d9ca6144 in GNUNET_MQ_inject_message (mq=0x60c000000b80,
    mh=0x62f00000a180) at mq.c:192
#28 0x00007fb1d9be6f06 in recv_message (cls=0x60d0000006c0, msg=0x62f00000a180)
    at client.c:347
#29 0x00007fb1d9ca44d4 in GNUNET_MST_from_buffer (mst=0x60400000f990, buf=0x0,
    size=0, purge=0, one_shot=0) at mst.c:222
#30 0x00007fb1d9ca5e84 in GNUNET_MST_read (mst=0x60400000f990,
    sock=0x60300000d9f0, purge=0, one_shot=0) at mst.c:367
#31 0x00007fb1d9be8784 in receive_ready (cls=0x60d0000006c0) at client.c:447
#32 0x00007fb1d9cf7663 in GNUNET_SCHEDULER_do_work (sh=0x606000007be0)
    at scheduler.c:2107
#33 0x00007fb1d9cf9fa0 in select_loop (sh=0x606000007be0, context=0x7ffdd3e4af90)
    at scheduler.c:2412
#34 0x00007fb1d9ce8649 in GNUNET_SCHEDULER_run (
    task=0x7fb1d9d01f94 <service_main>, task_cls=0x7ffdd3e4b240) at scheduler.c:710
#35 0x00007fb1d9d105c1 in GNUNET_SERVICE_run_ (argc=11, argv=0x7ffdd3e4bab8,
    service_name=0x559ffd8a6180 "dht", options=GNUNET_SERVICE_OPTION_NONE,
    service_init_cb=0x559ffd885b78 <run>,
    connect_cb=0x559ffd8739b0 <client_connect_cb>,
    disconnect_cb=0x559ffd873af5 <client_disconnect_cb>, cls=0x0,
    handlers=0x7ffdd3e4b820) at service.c:2136
#36 0x0000559ffd88694f in main (argc=11, argv=0x7ffdd3e4bab8)
    at gnunet-service-dht.c:540
(0019687)
ulfvonbelow   
2023-01-17 03:36   
just went back and saw multiple minutes were requested, so here's another statistics sampling with 5 minutes between:
$ gnunet-statistics -s dht && sleep 5m && echo && gnunet-statistics -s dht
          dht # P2P PUT requests received: 84792
          dht # Local PUT requests not routed: 5
          dht # P2P GET requests received: 59
          dht # peers connected: 9
          dht # requests TTL-dropped: 24
          dht # ITEMS stored in datacache: 84807
          dht # P2P RESULT bytes received: 198873
          dht # P2P GET requests ONLY routed: 13
          dht # GET messages queued for transmission: 62
          dht # messages dropped (underlays busy): 68898
          dht # PUT requests routed: 84797
          dht # Peer selection failed: 23037
          dht # GET requests routed: 61
          dht # DHT requests combined: 7
          dht # Network size estimates received: 3
          dht # P2P GET bytes received: 15184
          dht # PUT requests received from clients: 5
          dht # GET requests given to datacache: 33
          dht # Entries added to routing table: 59
          dht # P2P HELLO lookup requests processed: 13
          dht # P2P PUT bytes received: 43659588
          dht # FIND PEER messages initiated: 2
          dht # PUT messages queued for transmission: 70407
          dht # P2P RESULTS received: 10
          dht # REPLIES ignored for CLIENTS (no match): 84807
          dht # Good REPLIES matched against routing table: 23
          dht # Duplicate REPLIES matched against routing table: 3
          dht # RESULT messages queued for transmission: 36

          dht # P2P PUT requests received: 111473
          dht # Local PUT requests not routed: 5
          dht # P2P GET requests received: 72
          dht # peers connected: 9
          dht # requests TTL-dropped: 24
          dht # ITEMS stored in datacache: 110191
          dht # P2P RESULT bytes received: 198873
          dht # P2P GET requests ONLY routed: 14
          dht # GET messages queued for transmission: 82
          dht # messages dropped (underlays busy): 97847
          dht # PUT requests routed: 110181
          dht # Peer selection failed: 24546
          dht # GET requests routed: 75
          dht # DHT requests combined: 9
          dht # Network size estimates received: 3
          dht # P2P GET bytes received: 19044
          dht # PUT requests received from clients: 5
          dht # Entries added to routing table: 72
          dht # GET requests given to datacache: 39
          dht # P2P HELLO lookup requests processed: 19
          dht # P2P PUT bytes received: 57353992
          dht # FIND PEER messages initiated: 3
          dht # PUT messages queued for transmission: 99476
          dht # P2P RESULTS received: 10
          dht # REPLIES ignored for CLIENTS (no match): 110191
          dht # Good REPLIES matched against routing table: 23
          dht # Duplicate REPLIES matched against routing table: 3
          dht # RESULT messages queued for transmission: 42
(0019691)
Christian Grothoff   
2023-01-17 14:15   
Well, either way the answer is clear on this one:
1) We shouldn't have Ascension create this many DHT PUTs at such a high frequency, either by increasing DHT block lifetime or whatever else helps.
2) We should implement probabilistic block verification in the DHT, as the signature check at this rate kills less powerful peers.
(0019698)
schanzen   
2023-01-23 07:26   
I just now notices that the above patches are against the guix package repository. That is not under our control. Maybe it is managed by a member of the community. In any case, nothing to apply to gnunet git so no need to open another report.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7914 [GNUnet] GNS minor have not tried 2023-08-06 19:01 2023-08-06 19:01
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Documentation and publication of GNS zone registrar
Description: The service must be documented in order for other interested parties to provide such a service.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7909 [GNUnet] GNS minor have not tried 2023-08-06 18:57 2023-08-06 19:01
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Development of a registrar service framework
Description: We aim to provide a service framework which allows GNS zone registrars with tooling that enables them to effectively manage their service. This includes the ability to offer a self-service portal to users to register subdomains. The framework should include both a backend service as well as a simple web-based user interface.
In DNS, subdomain registrations are usually facilitated through a payment service. In two subtasks, the privacy-friendly payment system GNU Taler will be integrated into this service and the resulting components will be prototypically deployed to demonstrate the GNU Taler payment functionality.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7913 [GNUnet] GNS minor have not tried 2023-08-06 19:01 2023-08-06 19:01
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deployment of registrar service for zones managed by the GNUnet project
Description: The developed registrar shall be operated (using KUDOS payments?) by GNUnet (replacing fcfs?)
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7912 [GNUnet] GNS minor have not tried 2023-08-06 19:00 2023-08-06 19:00
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Process results from security audit and accessibility audit
Description: NGIentrust/NLnet will provide an audit. Process results.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7911 [GNUnet] GNS minor have not tried 2023-08-06 18:59 2023-08-06 18:59
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: GNS zone registrar fontend service
Description: The frontend service. Maybe start with fcfsd.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7910 [GNUnet] GNS minor have not tried 2023-08-06 18:58 2023-08-06 18:59
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: GNS zone registrar backend service
Description: The backend service. Maybe start with fcfsd.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7908 [GNUnet] GNS minor have not tried 2023-08-06 18:55 2023-08-06 18:56
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Documentation and publications of mirrored DNS zones
Description: Mirrored and deployed zones will be documented and advertised on the GNUnet project websites and mailing lists.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7905 [GNUnet] GNS minor have not tried 2023-08-06 18:51 2023-08-06 18:56
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Selection and deployment of DNS zones
Description: The goal is to select a number of existing Top-Level Domains (TLDs) which can reasonably be migrated and continuously mirrored on the GNUnet project infrastructure providing a fallback root zone and top-level domain resolution mechanism for the DNS. The selection criteria include the openness of the TLD registrar’s data policy, the format in which the data is provided and the relevancy of the namespace. It is likely that different data formats require tailored translation mechanisms.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7907 [GNUnet] GNS minor have not tried 2023-08-06 18:54 2023-08-06 18:54
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deployment of zones via CSV/Other
Description: Import of CSV file on the other hand will have other challenges: Continuous updates are difficult to reflect efficiently as usually there are no delta CSVs available. Also, the CSVs must be parsed and may be in slightly different formats.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7906 [GNUnet] GNS minor have not tried 2023-08-06 18:53 2023-08-06 18:53
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Deployment of zones via AXFR
Description: The “Ascension” can be used as a basis for supporting AXFR-enabled-Zones (https://git.gnunet.org/ascension.git/). We expect that this task will be worked on first and include work on performance and reliability at scale with respect to the zone management tooling in GNUnet GNS.
Tags: ngi-entrust-2022-08-104
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6073 [Taler] libeufin-nexus major have not tried 2020-02-04 14:38 2023-08-03 21:00
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: serialize some transaction state to the database
Description: ... so that we don't run into timeouts when we didn't properly acknowledge a previous transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015908)
Marcello Stanisci   
2020-05-15 18:44   
Still pending. It seems that nexus performs all the steps in two big functions,
without storing any state during the operations:

- doEbicsDownloadTransaction()
- doEbicsUploadTransaction()
(0015953)
Florian Dold   
2020-05-24 13:52   
We likely require a new API for this. I wouldn't prioritize this right now though.

Just as a reminder, the main purpose of this is to be more robust against failures, because when we don't acknowledge an EBICS upload/download transaction on our side, we might have to wait for a timeout until the bank lets us do the same order type again.
(0017908)
MS   
2021-05-27 10:23   
Priority changed after this last note.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7896 [Taler] deployment and operations major always 2023-08-01 20:50 2023-08-03 18:44
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: high OS Version:  
Status: feedback Product Version: 0.9.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: git (master)  
Summary: taler-config overrides the template configuration under /etc/taler/taler.conf
Description: I happen several times, that after using the cli
taler-config -s <section> -o <option> -V <value>

I found that the content of the /etc/taler/taler.conf doesn't have the reference to the conf.d files.

In the same direction, when taler-config fails because of permissions problems it does it quietly (doesn't print anything). Error code is not 0 but from the user it looks like it when normally.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020398)
Christian Grothoff   
2023-08-02 23:24   
Well, we can't really fix it overriding taler.conf, that's why the documentation urges you to not use it for editing configuration files.

We should of course fix the error reporting on failures, I'll look into that.
(0020406)
Christian Grothoff   
2023-08-03 18:44   
$ touch foo
$ chmod 400 foo
grothoff@pixel:~/research/taler/docs$ taler-config -c foo -s bla -o blub -V var
2023-08-03T18:43:16.081130+0200 util-disk-210646 WARNING `open' failed on file `/home/grothoff/research/taler/docs/foo' at disk.c:1291 with error: Permission denied
grothoff@pixel:~/research/taler/docs$ echo $?
2

Error reporting looks fine to me, can you please give me an idea how to reproduce the issue?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7881 [Taler] wallet (WebExtension) feature always 2023-07-04 16:30 2023-08-02 11:04
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: none OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: make Wallet Web Extension compatible with Tor private browsing
Description: Umbrella issue to track all problems using web extension with tor:

Known problems:
 * indexedDB is not supported in Firefox private mode and Tor (https://bugzilla.mozilla.org/show_bug.cgi?id=1639542)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020387)
sebasjm   
2023-08-02 11:03   
waiting tor to to upgrade to new firefox version that supports indexed db on private mode


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7894 [GNUnet] transport service minor have not tried 2023-07-27 13:36 2023-07-27 13:40
Reporter: schanzen Platform:  
Assigned To: stmr OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: QUIC communicator TLS "channel binding"
Description: We possibly want to bind the peer ID to the TLS certificate used in the handshake.
We can use the API of quiche:

void quiche_conn_peer_cert(const quiche_conn *conn, const uint8_t **out, size_t *out_len);

To retrieve the certificate of an incoming connection in DER format.
The peer should then, in addition to its Peer ID, send a signature using the peer private key over the DER certificate.

Once verified, the same can be done in the other direction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020384)
schanzen   
2023-07-27 13:40   
Motivation: An adversary may establish a TLS-over-QUIC connection to our peer. In our current implementation, it may spoof any Peer ID making MitM trivial.
Binding the TLS certificate (maybe even better, the cryptographic session from quiche_conn_session), to the Peer ID, makes it a lot harder for an adversary to MitM such a connection.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7774 [GNUnet] transport service feature have not tried 2023-03-25 15:02 2023-07-27 13:36
Reporter: schanzen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: QUIC communicator implementation
Description: A QUIC communicator implementation would be nice addition to our existing TCP und UDP communicators.

For encryption we need to decide if we roll our own as in gnunet-communicator-udp.c, or use TLS-over-QUIC (RFC9001)
Maybe, we even want to support both through a gnunet-communicator-quictls and gnunet-communicator-quic?
OTOH, at that point we could just do HTTP/2 I guess? https://nghttp2.org/

https://datatracker.ietf.org/doc/html/rfc9000
https://datatracker.ietf.org/doc/html/rfc9001

There are a few libraries, looking at https://github.com/ngtcp2/ngtcp2/blob/main/examples/gtlssimpleclient.c (MIT license) that seems to work with a variety of TLS backends (including gnutls).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7893 [Taler] wallet-core major always 2023-07-26 16:44 2023-07-26 16:45
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Expiring PeerPushCredit stays Pending for receiving device
Description: When the set timeout expires after having scanned a P2P send, wallet-core on the receiving device doesn't transfer the transaction from pending to expired, but only adds an error:
  "code": 7005,
  "when": {
    "t_ms": 1690357721065
  },
  "hint": "Unexpected HTTP status 410 in response",
  "requestUrl": "https://exchange.demo.taler.net/purses/.../merge",
  "requestMethod": "POST",
  "httpStatusCode": 410,
  "errorResponse": {
    "code": 1026,
    "hint": "The purse has expired."
  }
Tags:
Steps To Reproduce: On the sending device, prepare a P2P send transaction with a short timeout (e.g. 3 min). Scan with the receiving device, then wait until the transactions expires. The sending device got it right and shows Status: Expired.
On the receiving device, the status stays Pending.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7892 [Taler] wallet-core major always 2023-07-24 16:22 2023-07-24 16:24
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Expired P2P Transactions do not show how much the exchange paid back
Description: After an unclaimed P2P-Send expired, the Exchange sends back some coins (but keeps the fee).
Users should see how much they got back, and when.
Either expand the transaction details, or leave as it is and generate a second transaction (like a refunds, but not from the merchant but from the Exchange itself).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7806 [Taler] wallet (Android App) tweak have not tried 2023-04-17 17:44 2023-07-24 11:45
Reporter: hbarnard Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Lots of 'complaints' when compiling wallet
Description: I'm doing some wallet compiles, because I may need a modified version. Maybe this is something I'm not setting?
Lots of deprecation warnings during the compile, but I seem to get an apk, that I haven't tried yet! See below:


hbarnard@hbarnard-OptiPlex-9020:~/projects/taler/taler-android$ ./gradlew :wallet:build
Configuration on demand is an incubating feature.
warn: removing resource net.taler.wallet.nightly:string/backup_last without required default value.
warn: removing resource net.taler.wallet.nightly:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet.nightly:string/transactions_detail_title_balance without required default value.


> Task :wallet:compileNightlyDebugKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java

> Task :wallet:packageFdroidRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.
warn: removing resource net.taler.wallet:string/backup_last without required default value.
warn: removing resource net.taler.wallet:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet:string/transactions_detail_title_balance without required default value.

warn: removing resource net.taler.wallet.nightly:string/backup_last without required default value.
warn: removing resource net.taler.wallet.nightly:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet.nightly:string/transactions_detail_title_balance without required default value.


> Task :wallet:compileGoogleReleaseKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/Utils.kt:25:25 'WifiConfiguration' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/accounts/AccountManager.kt:33:27 Parameter 'knownBankAccounts' is never used, could be renamed to _
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/payment/ProductImageFragment.kt:50:41 'getParcelable(String?): T?' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:58:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:99:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:106:15 'onCreateOptionsMenu(Menu, MenuInflater): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:39:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:44:15 'onActivityCreated(Bundle?): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:62:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionsFragment.kt:66:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java

> Task :wallet:compileNightlyReleaseKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/Utils.kt:25:25 'WifiConfiguration' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/accounts/AccountManager.kt:33:27 Parameter 'knownBankAccounts' is never used, could be renamed to _
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/payment/ProductImageFragment.kt:50:41 'getParcelable(String?): T?' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:58:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:99:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:106:15 'onCreateOptionsMenu(Menu, MenuInflater): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:39:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:44:15 'onActivityCreated(Bundle?): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:62:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionsFragment.kt:66:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java

> Task :wallet:packageGoogleRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageNightlyRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageFdroidDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageGoogleDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageNightlyDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:lintReportFdroidDebug
Wrote HTML report to file:///home/hbarnard/projects/taler/taler-android/wallet/build/reports/lint-results-fdroidDebug.html

BUILD SUCCESSFUL in 6m 9s
Tags:
Steps To Reproduce: ./gradlew :wallet:build
Additional Information:
Attached Files:
Notes
(0020112)
grote   
2023-04-18 17:56   
None of those are critical. Deprecations happen all the time in Android and we'll take care of them eventually. Outdated strings get fixed when Weblate is pushing new translations.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7845 [Taler] libeufin-bank minor have not tried 2023-05-17 20:40 2023-07-24 10:54
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: "libeufin-sandbox config" command should allow changing individual settings ...
Description: ... without having to specify the value of *all* other configuration settings.

The way the tool does it right now makes it very difficult to use.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6402 [Taler] libeufin-nexus major have not tried 2020-06-22 07:01 2023-07-24 10:52
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: handle disrupted EBICS transactions
Description: We should either explicitly cancel such a transaction or re-try if the EBICS host supports this feature.

Currently we might run into waiting for a timeout (for re-doing the same order type) until the bank cancels the active transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7569 [Taler] libeufin-bank minor have not tried 2023-01-12 17:27 2023-07-21 19:42
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: EBICS error codes should be fetched from the enum defined in Util.
Description: Sandbox hard-codes EBICS error codes as strings in its responses, ignoring the enum
offered in the util package that already collects many EBICS codes.

The enum is called "EbicsReturnCode", in Ebics.kt at util package.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7134 [libmicrohttpd] build system major always 2021-12-30 07:21 2023-07-18 18:07
Reporter: kloczek Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9.75  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.9.76  
    Target Version: 0.9.76  
Summary: 0.9.75: missing file chapters/websocket.inc in dist tar ball
Description: Looks like it is missing file in dist tart ball. I found it after modify *texi files afetr which it was necessary to renerate info pages.

Making all in doc
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
Making all in .
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/sh '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/build-aux/missing' makeinfo --version) >/dev/null 2>&1; then \
  for f in libmicrohttpd-tutorial.info libmicrohttpd-tutorial.info-[0-9] libmicrohttpd-tutorial.info-[0-9][0-9] libmicrohttpd-tutorial.i[0-9] libmicrohttpd-tutorial.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/sh '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/build-aux/missing' makeinfo -I . \
 -o libmicrohttpd-tutorial.info libmicrohttpd-tutorial.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd .; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd . && \
  $restore $backupdir/* `echo "./libmicrohttpd-tutorial.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
libmicrohttpd-tutorial.texi:116: @include: could not find chapters/websocket.inc
make[3]: *** [Makefile:553: libmicrohttpd-tutorial.info] Error 1
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
make[2]: *** [Makefile:774: all-recursive] Error 1
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
make[1]: *** [Makefile:608: all-recursive] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75'
make: *** [Makefile:515: all] Error 2

Please next time on generate dist tar ball use "make distchec" instead "make dist"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018753)
Christian Grothoff   
2022-02-28 23:55   
Fixed by Evgeny in bf89bd95f8d4401ddaabdb59023175e66bdbd80f
(0020169)
kloczek   
2023-04-28 21:57   
Still dist tar ball is broken.
(0020170)
kloczek   
2023-04-28 22:26   
Looks like not only doc/chapters/websocket.inc is missing in tar ball.
After add that filre on buiulding rpm package building documentation failed on another file

libmicrohttpd-tutorial.texi:190: @verbatiminclude: could not find examples/websocket.c
make[1]: *** [Makefile:554: libmicrohttpd-tutorial.info] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.76/doc'
make: *** [Makefile:775: all-recursive] Error 1

PLEASE make sure next time that dist tar ball has been generated not using "make dist" but "make dist check".

IMO it would be good ASP make new release with all missing files.
(0020248)
Christian Grothoff   
2023-06-01 21:51   
0.9.77 is out...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7879 [Taler] libeufin-nexus feature have not tried 2023-07-03 16:01 2023-07-16 16:11
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Implement EBICS 3.0 keying.
Description: The 3.0 implementation needs the same keying logic of 2.5's INI, HIA, HPB.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7810 [Taler] exchange feature have not tried 2023-04-22 17:54 2023-07-16 16:05
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support conversion service URL and regex validation for /wire
Description: We also need to distinguish between withdrawals and deposits, as in the conversion case, different restrictions for the payto:// URI apply.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020126)
Christian Grothoff   
2023-04-22 22:08   
(Last edited: 2023-04-22 22:09)
API change for /wire specified in docs.git -- 43a3dca..d3102b7.

Once implemented, we MUST bump the protocol to "15:0:0" and add a (transient) protocol-version based switch in libtalerexchange.
(0020172)
Christian Grothoff   
2023-05-02 12:09   
This is largely implemented (exchange, merchant, documentation). Wallet is missing (=> assigning to Florian). What is still missing is that the merchant (and wallet) currently ignores debit restrictions imposed by the exchange and would be perfectly happy to accept deposits for coins from exchanges where the exchange doesn't actually accept the merchant's bank account.

To fix this, we need a working regex evaluator for this style of regex AND to modify the pay logic to actually check.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7884 [Taler] exchange feature have not tried 2023-07-05 22:47 2023-07-16 14:06
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: exchange should have tooling to check consistency between DB and crypto helpers
Description: The tool should check that all denominations and signing keys in /keys are actually offered by the secmod helpers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7887 [GNUnet] util library tweak always 2023-07-14 13:45 2023-07-14 17:08
Reporter: t3sserakt Platform:  
Assigned To: t3sserakt OS:  
Priority: low OS Version:  
Status: assigned Product Version: 0.19.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0.0  
Summary: GNUNET_MQ_inject_message in mq.c only handles GNUNET_MQ_ERROR_MALFORMED not GNUNET_MQ_ERROR_NO_MATCH
Description: If a client has no matching handler for a message the message is silently not handled.

Tags:
Steps To Reproduce: Connect a fake core client to transport with no handler.
Additional Information: If no handler is found we should do something about it.

Should each subsystem choose how to handle this? Then we could call GNUNET_MQ_inject_error too in this case.

Tried it, but got a lot of those errors during peer startup! Each of those errors must be investigated.

A generic callback to send a generic error message to the other peer would be an alternative.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7466 [Taler] demobank-ui major have not tried 2022-11-17 17:55 2023-07-13 16:44
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: should be mobile friendly
Description: UI doesn't render properly on mobile browser with limited size
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7464 [Taler] wallet (iOS App) text always 2022-11-16 14:27 2023-07-08 13:08
Reporter: sebasjm Platform:  
Assigned To: MarcS OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: document minimal hardware and software required
Description: From email:

Our minimum deployment target is iOS 15 (which runs on iPhone 6S (2015) and later).
Sorry, but our app won’t run on iPhone 6 (2014) because that only runs iOS 12.5.
(All devices which were able to run iOS 13 and 14 also can run iOS 15)

https://git.taler.net/taler-ios.git/tree/README.md

It will be also nice for android, but at least i know where to look for it :)
https://git.taler.net/taler-android.git/tree/wallet/build.gradle
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019425)
sebasjm   
2022-11-16 15:36   
I have added in the README where the minimum browser required can be found in commit 9ddf3d3e196c66e731ca2e3189c453436de9417a
(0020345)
MarcS   
2023-07-08 13:08   
Added info to README.md (weeks ago...)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7752 [Taler] demobank-ui feature have not tried 2023-03-07 18:47 2023-07-04 16:47
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: show volume and transaction
Description: operation statistics.
- volume
- numbers of transactions

should render some nice plot in the SPA
also give the possibility to export as CSV

requires 0007781
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7880 [Taler] libeufin-nexus minor have not tried 2023-07-04 11:04 2023-07-04 11:04
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Introduce command to (ONLY) download the bank's keys.
Description: In the current version the bank's keys are downloaded along the uploading of the client keys. The responsible operation is called 'connect'. If the bank requires the client's keys to be confirmed (via ordinary post) before letting them download the bank's keys, then the user must run the 'connect' operation twice: first to upload the client keys, then to download the bank's.

The result is that the user wastefully uploads their keys twice.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5936 [Taler] libeufin-bank minor have not tried 2019-10-18 19:16 2023-06-29 12:44
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: version / revision / other globals / should be available from context
Description: Since EBICS responses want (at least) the EBICS version and revision, the sandbox should have some global object/context that is always updated with the revision and version under which it is serving requests
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015019)
Marcello Stanisci   
2019-10-18 19:17   
Clearly, after this is done, the parts where such values are hardcoded must be adapted to use the global context.
(0015923)
Marcello Stanisci   
2020-05-15 19:43   
Still open, but not urgent.
(0019820)
MS   
2023-02-13 18:25   
takes even less priority, because Sandbox won't _serve_ EBICS in the context of regional currencies.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6243 [Taler] libeufin-bank minor have not tried 2020-05-20 19:05 2023-06-29 12:44
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sandbox filtering on EBICS date range is missing in C53 requests
Description: The sandbox is ignoring the date range from C53 requests. To be fixed.
Tags:
Steps To Reproduce:
Additional Information: The responsible function is called "constructCamtResponse()"
Attached Files:
Notes
(0018149)
ms-mantis   
2021-08-31 14:49   
That is implemented here: 3967193487e42335b43b80ee7407fa44ad39cf70.

Extensive testing is now needed, especially via Nexus' querying.
(0019514)
MS   
2022-12-13 16:39   
(Last edited: 2022-12-14 23:14)
Camt.052 needs date range too. Now throws NotImplementedError().

=> after private discussion, libeufin won't support date ranges on C52.

Keep open until C53 gets tested. Not urgent as not used by Taler.
(0019751)
MS   
2023-02-03 18:17   
(Last edited: 2023-02-03 18:18)
That depends on the Sandbox to "tick" business days. A tick operation moves all the pending transactions to the booked state, and only then they become available for C53.

Hence before fixing this, Sandbox should tick, otherwise it will have always no C53-content.

This feature would help in case of data loss from Nexus, as then only the bank could resort
the lost information.
(0019822)
MS   
2023-02-13 18:39   
Lowering the priority because Sandbox won't _serve_ EBICS in the context of regional currencies.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6893 [Taler] libeufin-bank minor have not tried 2021-05-27 15:51 2023-06-29 12:43
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Camt reports should respect time "chunking".
Description: At this present time, every report / statement accounts for the whole history of the bank account. Instead, those reported histories need to account only for a particular time window. Usually, from one point in the past, up to the current date.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5955 [Taler] libeufin-bank minor have not tried 2019-10-31 19:48 2023-06-29 12:41
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: use EBICS return codes from EBICS spec, make sure correct codes are returned
Description: The specification has three things:
1. code
2. short name
3. explanatory text

and all these are required.

Furthermore, unless there is actually a bank-technical response code, ebicsHEVResponse should be used.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6962 [Taler] libeufin-bank minor have not tried 2021-07-29 11:44 2023-06-29 12:28
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: CAMT reports need more structure to specify negative balances.
Description: CAMT numbers cannot be negative, therefore whenever a bank account enters the debit status, the CAMT generation must include more structure to reflect it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6260 [Taler] libeufin-nexus minor have not tried 2020-05-24 14:34 2023-06-29 12:27
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: nexus should store balance
Description: The nexus should parse the latest account balance and offer it via API.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019821)
MS   
2023-02-13 18:29   
Not required for regional currencies: users don't have accounts at Nexus and the exchange doesn't need it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6268 [Taler] libeufin-bank feature have not tried 2020-05-29 08:47 2023-06-29 12:08
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sandbox should support balances in c52/c53
Description: Right now, we always display a balance of 0.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017920)
MS   
2021-05-27 15:41   
For now (4c44480..d527df4) every report always include the whole history of one bank account.
(0019146)
Florian Dold   
2022-09-19 12:53   
There is an (incomplete!) test case "test-libeufin-nexus-balance" in the wallet integration tests. I will disable this test for now, but we should eventually fix it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5973 [Taler] libeufin-bank minor have not tried 2019-11-18 19:33 2023-06-29 11:58
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: report more information about a user's state
Description: For example, if the user tries to send signed data *before* sharing their keys with the bank, then the Sandbox responds with "invalid signature". Instead, the Sandbox should point the user to the right way telling them that their keys weren't received yet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015296)
Marcello Stanisci   
2020-01-23 00:13   
260528a..5bc7981 throws more appropriate errors (EbicsSubscriberStateError) whenever a subscriber attempts some operation while being in a wrong state. Leaving open until testing this change.
(0015914)
Marcello Stanisci   
2020-05-15 19:08   
Still untested.
(0019747)
MS   
2023-02-03 16:06   
The code doesn't show anymore such checks. Issue still open
(0019817)
MS   
2023-02-13 18:17   
(Last edited: 2023-02-13 18:17)
not needed for regional currencies. As soon as a user is registered, their state is ready to operate.
(0020100)
Florian Dold   
2023-04-17 11:06   
Not sure why this is assigned to me. @MS could you please look into this bug and whether we can already resolve it?
(0020323)
MS   
2023-06-29 11:49   
Not solvable as the requirement is not fulfilled, but sure it has a very low priority.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7556 [Taler] libeufin (general) minor have not tried 2023-01-07 10:35 2023-06-29 11:47
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Fix "make parse".
Description: The two failing tests (test_dashed_subject, test_camt53_example3) show both a message like the following:

self = <json.decoder.JSONDecoder object at 0x7fd9059361d0>
s = '10:04:43,134 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]\n10... "unstructuredRemittanceInformation" : "subject-with-dashes"\n }\n } ]\n } ]\n } ]\n } ]\n}\n'
_w = <built-in method match of re.Pattern object at 0x7fd905a892f0>
Tags:
Steps To Reproduce: Run "make parse".
Additional Information: =============================== short test summary info ================================
FAILED checks.py::test_dashed_subject - json.decoder.JSONDecodeError: Extra data: line 1 column 3 (char 2)
FAILED checks.py::test_camt53_example3 - json.decoder.JSONDecodeError: Extra data: line 1 column 3 (char 2)

Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6547 [Taler] libeufin-nexus minor have not tried 2020-08-31 12:56 2023-06-29 11:46
Reporter: MS Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Offer raw EBICS upload for any message.
Description: Nexus needs to offer a API call to upload for any type of EBICS message. This is already documented,
therefore needs the implementation. The download does have a implementation already.

The endpoint will look like the following:
  
  {nexus_base_url}/bank-connections/{connection_name}/ebics/upload/{msg}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020061)
MS   
2023-04-11 10:43   
Not _strictly_ relevant for the Postfinance integration as what gets uploaded to the bank
needs a defined type (as opposed to raw content to be sent "on the fly"). Still, this may result
convenient, so keeping for now but with low priority.
(0020322)
MS   
2023-06-29 11:46   
Could not prove the 'already documented' part, which is better as people wouldn't get misled.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6404 [Taler] libeufin-nexus minor have not tried 2020-06-22 12:03 2023-06-29 11:40
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: ISO20022 camt mapping is not documented, incomplete and incorrect in some places
Description: See summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020059)
MS   
2023-04-11 10:39   
Assuming the bug refers to this data type, suggesting to more verbosely document its fields:
https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/iso20022/Iso20022.kt?id=101fa06fd5fa863a90eb4cbc0b4fcd2e28fda583#n274


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7448 [Taler] wallet-core feature have not tried 2022-11-10 13:51 2023-06-28 20:26
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: low OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet operation that receive amount in the request should specify if the amount include fee
Description: For example
1.- the user wants to withdraw all the KUDOS from the bank, the amount in the request is the raw amount
2.- the user wants to pay for an article, doesn't have enough coins, wallet redirect to the withdrawal operation, the amount in the request is the effective amount (just what need for the payment)

The same happens to other commands:
 * deposit: the user may want specify the amount to send from the wallet or the amount to receive in the bank account
 * transfer and invoice also

Since the fee is affected by the coin selection this is not an easy calculation that the user can do from the UI.

Proposal:
We have a prepare command for every operation (prepareWitdraw/GetFeeForDeposit/peer/...) this prepare command is being use to get information about the operation like the total fee.

It will be enough to add the intention (semantic) of the amount in the prepare command, return the {effective,raw} amount and then always use the amount raw in the confirmation command.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019992)
Florian Dold   
2023-03-30 11:27   
Okay so what we want is for operations that take an *instructed* amount to also include some "mode" argument. But the *raw* and *effective* amounts are always interpreted the same. Can we agree on what we want these modes to be?

For withdrawal, I can see:
* raw (default): instructed amount is what is subtracted from the reserve balance (i.e. it's the raw amount)
* effective: instructed amount is what the user wants to have as material balance in the wallet

However, that does not really cover the user case where the merchant charges fees and the user has to pay for that. So in theory we could have a mode that withdraws enough to pay for some particular claimed order, but IMHO that's overkill.

For deposits:
* max: The instructed amount is ignored (can be zero in the request), and all coins are spent
* raw (default): The instructed amount is what will be paid to the "merchant" (or the customer's bank account), ignoring wire fees
* effective: The instructed amount is how the wallet's balance will be affected. Difficult to compute accurately because refresh is involved.

For peer-push-debit:
* raw (default): The instructed amount is what will be paid, deposit fees are covered by the sender, withdrawal fees from the reserve by the receiver
* effective: Instructed amount is the effect on the material balance. Difficult to compute accurately because refresh is involved.

Should we also have a mode where withdrawal fees are covered by the side that does peer-push-debit? However, that assumes the other party has the same withdrawal coin selection algorithm

For peer-pull-credit:
* raw (default): Amount that the other party has to put in the reserve, where the other party has to pay deposit fees
* effective: Amount that be added to on the initiator's balance

IMHO this is complex enough to warrant a new DD
(0019996)
Florian Dold   
2023-03-30 12:18   
I've created DD41 with the above definitions as a starting point.
(0019997)
sebasjm   
2023-03-31 15:56   
As discussed two new concepts, instructedAmount could be

    origin-effective: how the balance is going to change with the operation
    destination-effective: how the balance/account is going to change with the operation

Its going to be specified by the `mode` argument

And new functions to validate input from the user

checkPeerPushPayment(instructedAmount, mode) => AmountResult

type AmountResult = InstructedAmountPossible | InstructedAmountNotPossible

type InstructedAmountPossible = {
  type: "possible",
  amountEffective,
  amountRaw,
}

type InstructedAmountNotPossible = {
  type: "not-possible",
  closestHigher: {
    amountEffective,
    amountRaw,
  },
  closestLower: {
    amountEffective,
    amountRaw,
  },
}
(0020318)
sebasjm   
2023-06-28 20:26   
this is going to be solved after DD41 is finished


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7872 [Taler] wallet-core major always 2023-06-27 14:34 2023-06-28 15:46
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE does not always return feeGapEstimate
Description: coins:
1 x KUDOS:5
5 x KUDOS:2
1 x KUDOS:1
28 x KUDOS:0.1

balance material: 18.8

Calling `WalletApiOperation.CheckPeerPushDebit` with amount=18.8 I get feeGapEstimate: 0.36
which is right, and expected.

BUT:
Calling `WalletApiOperation.CheckPeerPushDebit` with amount=19 I get feeGapEstimate: 0
I expect to return feeGapEstimate: 0.36
OR:
to return something that I can use to in `WalletApiOperation.CheckPeerPushDebit`

maybe a workaround:
if "CheckPeerPushDebit" fails then call again with balanceMaterial - feeGapEstimate.

Then:
1.- amount=19 it will fail, and call 18.8
2.- amount=18.8 it will fail, and call 18.44
3.- amount=18.44 will work

example of errors:

with amount = 18.8

    "details": {
      "code": 7027,
      "when": {
        "t_ms": 1687868248035
      },
      "hint": "Error (WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE)",
      "insufficientBalanceDetails": {
        "amountRequested": "KUDOS:18.8",
        "balanceAvailable": "KUDOS:18.8",
        "balanceMaterial": "KUDOS:18.8",
        "feeGapEstimate": "KUDOS:0.36",
        "perExchange": {
          "https://exchange.demo.taler.net/": {
            "balanceAvailable": "KUDOS:18.8",
            "balanceMaterial": "KUDOS:18.8",
            "feeGapEstimate": "KUDOS:0.36"
          }
        }
      }
    }

with amount = 19

    "details": {
      "code": 7027,
      "when": {
        "t_ms": 1687868876516
      },
      "hint": "Error (WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE)",
      "insufficientBalanceDetails": {
        "amountRequested": "KUDOS:19",
        "balanceAvailable": "KUDOS:18.8",
        "balanceMaterial": "KUDOS:18.8",
        "feeGapEstimate": "KUDOS:0",
        "perExchange": {
          "https://exchange.demo.taler.net/": {
            "balanceAvailable": "KUDOS:18.8",
            "balanceMaterial": "KUDOS:18.8",
            "feeGapEstimate": "KUDOS:0"
          }
        }
      }
    }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020309)
Florian Dold   
2023-06-27 20:03   
(Last edited: 2023-06-27 20:03)
As discussed in the Mumble meeting, I see this as the function conforming to its specification.

The feeGapEstimate is only reported when the payment looks like it would be possible with the material amount, but is impossible because of extra fees. If the payment is "obviously not possible", there is no need to report the feeGapEstimate.

It looks like you (@Sebastian) are using the output of this to compute the maximum amount that can be spent, right? If that's the case, I would propose that we have a separate wallet-core request for that. In case the CheckPeerPushDebit returns the insufficient balance error, the UI should just use this new request to show a nicer error message.

Or alternatively, the WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE error details could always include some "maxAmountRaw" in it, so we don't have to make a separate request from the UI.

What do you think?
(0020312)
sebasjm   
2023-06-28 15:00   
> Or alternatively, the WALLET_PEER_PUSH_PAYMENT_INSUFFICIENT_BALANCE error details could always include some "maxAmountRaw" in it, so we don't have to make a separate request from the UI.

This one is better. Maybe we should call it "maxInstructedAmount"?
Because I expect this amount to be what the UI is going to suggest the user to be the max to call the operation again.

So if I call the operation again (and no balance change in the middle) with instructedAmount = maxInstructedAmount the operation will succeed and use all the coins.
(0020313)
Florian Dold   
2023-06-28 15:46   
Yeah, sounds good, but I'd call it maxRawInstructedAmount since instructed amount is ambiguous. I'll implement this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7862 [Taler] exchange API (HTTP specification) feature have not tried 2023-06-06 18:48 2023-06-23 11:44
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: exchange should return some hint about the kyc requirements
Description: In machine readable format so wallets can query and show to the user that an operation above X amount will trigger KYC requirements. (before doing the actual operation)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7860 [Taler] libeufin-bank minor have not tried 2023-06-06 17:06 2023-06-06 17:06
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: demobank should support aborting withdrawal operations from the wallet
Description: It's currently not in the spec, but I assumed that (at least optionally) withdrawal operations in the Bank Integration API provide a way for the *wallet* to cancel the withdrawal when the user aborts it.

But looks like currently this is neither in the spec nor the demobank.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7858 [Taler] other minor have not tried 2023-06-05 14:06 2023-06-05 14:32
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: consider protocol extensions to shift around fees from customer to merchant
Description: Not clear yet how we would do this or if this is even desirable, but multiple people have mentioned that they would be interested in this, so I'm opening the bug.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020262)
sebasjm   
2023-06-05 14:32   
Consider the situation when the merchant must return the effective amount to the user wallet. In that case the refund fee can be drained from a reserve that the merchant uses for tipping.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7857 [Taler] wallet-core minor have not tried 2023-06-05 14:00 2023-06-05 14:00
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core should immediately re-try processing a transaction once a dependent transaction changes status
Description: We currently check with exponential back-off, as if this were some network request. That's slow and inefficient.

Examples:
* withdrawals of peer-(push,pull)-credit transactions
* refreshes of certain aborting transactions

Instead we should simply run the code to process a transaction that's waiting for another one once the dependee changes state.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7855 [Taler] wallet-core feature have not tried 2023-06-02 17:08 2023-06-02 17:08
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Timestamp of withdrawal transaction should be updated to the time the withdrawal really happens
Description: When making a manual withdrawal, wallet-core generates a pending transaction with the current time.
But the wire transfer takes time, so it could be days until the pending transaction continues.
The transaction timestamp should be updated to the time at <withdrawal-group-reserve-ready> or even <withdraw-group-finished>
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7645 [GNUnet] cadet service trivial always 2023-01-29 23:39 2023-06-01 20:25
Reporter: ulfvonbelow Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.20.0  
Summary: Memory leaks in test_cadet.c
Description: t_op's elements are overwritten without any chance of freeing them. Many channel wrappers are leaked.
Tags: memory-leak, patch
Steps To Reproduce: ./configure --enable-sanitizer
make
make install
make check
Additional Information: Patch attached. Note that it modifies the cadet API slightly, so that GNUNET_CADET_channel_destroy returns the closure it was created with. If this is undesirable, I ask that someone more familiar with the workings of this many-tests-in-one program fix its memory leaks.
Attached Files: 0001-CADET-return-closure-from-GNUNET_CADET_channel_destr.patch (7,422 bytes) 2023-01-29 23:39
https://bugs.gnunet.org/file_download.php?file_id=1345&type=bug
Notes
(0019763)
schanzen   
2023-02-06 05:58   
I think this needs some investigation, returning void* seems odd.
(0019845)
schanzen   
2023-02-15 10:20   
It boils down to this: The "ctx" that is passed to GNUNET_CADET_channel_create() as a second argument is the responsibility of the caller, not the API.
The caller must have a way of cleaning this up. Either when the API is "done" and eventually passes ctx again (disconnect handler) or when the caller itself does a cleanup after, e.g. deciding to abort.
The tests needs to track the CadetTestChannelWrapper for the respective channel. Mostly they do. But there may be a race condition timeout.
I don't think it is really worth fixing. But the way to do it would probably to introduce global variables for the wrapper struct(s).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7699 [Taler] wallet-core minor have not tried 2023-02-16 18:57 2023-05-18 21:24
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wallet should support different types of instructed amounts (before and after fees)
Description: Depending on the context, the user wants the instructed amount to be the *effective* instructive amount or the *raw* instructed amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7841 [Taler] merchant backend API (HTTP specification) feature N/A 2023-05-10 17:53 2023-05-13 22:18
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: merchant should require wallet to accept or reject refund
Description: in current protocol refunds are unilateral decisions, when the merchant create a refund this is assume that is good for the wallet since is more money for the pocket.
the merchant is assume to behave in a good way but there are situations that this can be exploited

consider the scenario of selling ticket of concerts:

over sell
---
1.- merchant has 100 seats to sells
2.- merchant sells 110 seats
3.- choose 10 seats based on some factors to refund

speculative price
--
1.- merchant has 100 seats to sells
2.- merchant sells 100 seats at price X
3.- sold in 2 days, still 2 month for the performance
4.- refund 20%, double the price and sell again

in all cases
1.- wallet will automatically pickup refunds
2.- wallet user can't complain since refund was accepted and money is in their pockets

more importantly:

A. if the refund does cancel the contract: wallet doesn't have a warrant that after the purchase the merchant is not going to unilateral cancel the contract
B. if the refund doesn't cancel the contract: merchant can't have a way to deny the entrance (or the service in the contact terms) after a refund.

we want to make this work without reducing the refundable duration since in the example of a ticket for a concert, the refundable duration should be between the purchase and the performance.

proposal:
---

https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-orders-$ORDER_ID-refund

interface WalletRefundRequest {
  // Hash of the order's contract terms (this is used to authenticate the
  // wallet/customer).
  h_contract: HashCode;
 
  // accepted -> actual case
  // denied -> return the amount to the merchant, as nothing happened
  decision: "accepted" | "denied"
}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020195)
Christian Grothoff   
2023-05-13 20:36   
I think your report here is filed under a false legal premise. By merely (especially automatically) accepting a refund, a customer does not inherently forfeit their rights to the contract. So the customer could still go after the merchant for not fulfilling their original agreement. And in your scenario where the merchant behaved in bad faith, I'm pretty sure they'd loose in court. On the other hand, if the merchant could not be expected to uphold their end (say concert was cancelled due to sickness or natural disasters), then the merchant would be in their rights to unilaterally break the contract like this. But, again, this is something for the courts. So before implementing anything here, we definitively need to talk to an actual contract lawyer....


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7773 [GNUnet] transport service feature have not tried 2023-03-25 15:00 2023-05-09 19:25
Reporter: schanzen Platform:  
Assigned To: stmr OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: QUIC communicator
Description: This is the meta issue for the QUIC communicator in TNG
Tags: gsoc, tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7838 [Taler] challenger feature N/A 2023-05-08 22:33 2023-05-09 11:07
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: none OS Version: squeeze  
Status: confirmed Product Version: 0.9.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Add support for rfc7636 to challenger
Description: This is mostly to follow best current practice, it is merely recommended in our scenario as our clients are no public and thus the "someone steals my client secret from an App" doesn't really apply to Taler. But, if we want to see challenger used more broadly (beyond Taler), this might be a nice feature to eventually add.
Tags:
Steps To Reproduce:
Additional Information: schanzen: I have some PKCE code in GNUnet if you want to steal it
https://git.gnunet.org/gnunet.git/tree/src/reclaim/oidc_helper.c#n710
System Description
Attached Files:
Notes
(0020189)
schanzen   
2023-05-09 11:07   
Note that you are implementing an AS. For the AS, it is a MUST in the BCP. For clients it is RECOMMENDED.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7836 [Taler] wallet-core minor have not tried 2023-05-07 22:11 2023-05-07 22:11
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: test-refund-gone doesn't work as expected
Description: While the test passes, it looks like the refund isn't actually gone --- for some reason, time-travel isn't working, and the refund works even though it shouldn't.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7834 [Taler] wallet-core minor have not tried 2023-05-05 16:39 2023-05-05 16:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: wallet relies on longpolling to work
Description: Instead, the wallet should make sure that it does appropriate waiting if long-polling returns too early.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7697 [Taler] wallet-core tweak have not tried 2023-02-16 12:21 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wallet is not GCing denominations
Description: Thus the database grows to a very large size.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7736 [Taler] wallet-core feature always 2023-03-02 12:53 2023-05-04 20:19
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core should enforce accepted ToS for various operations
Description: UI need information about the ToS status

wallet-core should not allow using an exchange without accepting ToS first (does this happen also with withdrawals?)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6397 [Taler] documentation text have not tried 2020-06-18 22:13 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: write a good README(.md) file for LibEuFin
Description: See summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7506 [Taler] libeufin (general) feature have not tried 2022-11-30 22:58 2023-05-04 20:16
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Add helpers to generate test data.
Description: database data used in tests should be generated by convenient helper functions, instead of
being entered by verbose blocks of bare database instructions copied in several parts.
Tags:
Steps To Reproduce:
Additional Information: Examples are MakeEnv.kt and DownloadAndSubmit.kt in the Nexus test suite.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6396 [Taler] libeufin-nexus feature have not tried 2020-06-18 22:09 2023-05-04 20:16
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Implement FinTS
Description: ... as another bank connection type.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7665 [Taler] documentation text have not tried 2023-02-08 16:31 2023-05-04 20:10
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: Document database schema of Sandbox and Nexus
Description: of both Sandbox and Nexus.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7815 [Taler] exchange feature always 2023-04-23 22:21 2023-04-24 20:06
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: exchange should have API to give refunds for purses in peer-pull payments
Description: The refund should only be possible until the purse is filled completely. The refund is done for each deposited coin individually.

The attached diagram shows the state machine for peer-pull-debit transactions *with* refunds. The wallet for now does not support them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: transaction-pull-debit-states.png (109,494 bytes) 2023-04-23 22:21
https://bugs.gnunet.org/file_download.php?file_id=1369&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7116 [Taler] libeufin-nexus feature have not tried 2021-11-30 18:48 2023-04-23 23:46
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: payment bouncing fee should be configurable
Description: The Taler facade bounces malformed incoming payments with the same amount that was paid by the debtor. Instead it should deduct a bounce fee, and this one should be specified in the configuration.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7795 [Taler] libeufin-bank minor have not tried 2023-04-07 15:59 2023-04-23 23:38
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: STDOUT not showing.
Description: Redirecting both STDOUT and STDERR to a file doesn't show STDOUT.
Observed in Sandbox when using Exposed's StdOutSqlLogger.
Tags:
Steps To Reproduce:
Additional Information: Information loss is very unlikely, because logging goes to STDERR.
Attached Files:
Notes
(0020138)
Florian Dold   
2023-04-23 23:38   
Can you clarify this a bit?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7771 [Taler] libeufin (general) trivial have not tried 2023-03-23 12:52 2023-04-23 23:36
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Manage missing testing dependencies.
Description: Instead of failing when 'jq', Python 'requests', or 'sqlite3' are missing, tests should either
install them or inform the user about such missing dependencies.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5954 [Taler] libeufin (general) minor have not tried 2019-10-29 18:00 2023-04-23 23:32
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: look for or implement better alternative to JAXB
Description: JAXB doesn't work well with kotlin, but it also is pretty bad in general.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6259 [Taler] libeufin-nexus minor have not tried 2020-05-24 13:58 2023-04-23 23:32
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: error log in database
Description: LibEuFin should collect bank-technical errors in a database, and the UI should be able to render them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6556 [Taler] wallet-core tweak have not tried 2020-09-03 11:41 2023-04-23 23:31
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: have integration tests that mutate signatures to check that implementation checks all relevant signatures
Description: It's pretty easy to forget checking signatures in the wallet. We should have test cases that actually trigger signature verification failures.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6804 [Taler] wallet-core feature have not tried 2021-03-11 16:10 2023-04-23 23:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: implement wallet test case for a multi-exchange payment
Description: The test case should withdraw from two exchanges and then pay for an order with a merchant that accepts both exchanges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4379 [Taler] wallet-core feature have not tried 2016-04-06 23:34 2023-04-23 20:21
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: error handling: exportable proof of e.g. double spending for auditor
Description: When payments fail and it is not a transient error, the wallet needs to provide the user with a way to extract the information regarding the claim the merchant made.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011423)
Florian Dold   
2016-11-03 20:21   
Not clear how this should look UI-wise, and I'm also not sure what's the best way to test this.

For the UI: We could open an in-extension tab that shows a message and a way to save the proof. Should it show up anywhere in the wallet popup, or just in the history?

Does this error page provide the user with the option to refresh coins that are not double-spended? Does this happen automatically (probably makes most sense)?

Should we have some informal spec that documents these cases before we start implementing?
(0011451)
Florian Dold   
2016-11-08 15:01   
Moved to 0.3 since we should have at least the facilities to trigger the various error paths (wallet really double-spended / merchant falsely claimed double spending).
(0011452)
Christian Grothoff   
2016-11-08 16:11   
Eh, that would be 0.5. That's when the error path triggering is on the roadmap.
(0011453)
Christian Grothoff   
2016-11-08 16:11   
Wrong again. 0.6.
(0011945)
Christian Grothoff   
2017-03-19 00:06   
In terms of specification, I basically expect that for each possible proof we export a JSON file with:

* always top-level: some numeric information about the type of proof
* always top-level: some human-readable information about the type of proof

Then, type-specific key-value pairs where:

key: some string describing the value
value: some json object (or array) with structured proof data, i.e. public keys, amounts, signatures, hashes, etc., depending on what the proof is about.


We should also have some command-line tool to verify proofs, i.e. I would run:

taler-check-proof FILENAME.json

and it would:
1) open file, parse the json (make sure JSON was valid)
2) look at the type, use it to load some plugin to verify the proof and
3) output the result of the check ("valid" / "invalid")

We need to have an additional options "--extract-contract" that could be used to extract the JSON contract from the overall proof (if present), so that one can use the (generic) contract renderer (which we need to have a standalone-version of) to show the contract. I think that's about it for the overall design, the individual JSON field members for each proof should probably just be speced as the export-logic and proof-validation plugin are implemented.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6258 [Taler] libeufin-nexus minor have not tried 2020-05-24 13:55 2023-04-23 19:38
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: parse HAC for better reliability
Description: With some operations, we will only know by looking at HAC whether they succeeded or failed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6664 [Taler] documentation text have not tried 2020-12-08 15:59 2023-04-18 20:06
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: clarify normalization algorithm of contract terms and backup blob
Description: We currently don't specify the algorithm, but just refer to the jansson implementation.

We should have a look at https://tools.ietf.org/html/rfc8785 for this.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020119)
Christian Grothoff   
2023-04-18 20:06   
DD 018 already clearly refers to RFC 8785, so I am not sure what else is left to do here.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7696 [Taler] libeufin-nexus major have not tried 2023-02-15 16:09 2023-04-17 11:48
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: EBICS_NO_DOWNLOAD_DATA_AVAILABLE check is possibly wrong.
Description: Nexus checks this as a EBICS-technical return code, although the documentation lists it among the
business-technical return codes. That doesn't break demo because Sandbox does the same (just
server-side).

However, this may break when using Nexus with other banks. Hence such check needs more tests
with different banks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6250 [Taler] libeufin-nexus minor have not tried 2020-05-21 09:05 2023-04-17 11:42
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement advanced permission storage and checking
Description: Right now, the nexus doesn't do any permissions at all beyond authenticating the user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020065)
MS   
2023-04-11 11:03   
It does. This is one example from the Taler facade:
https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/Taler.kt?id=1b9fbb02ac2d2eb402c18877079d1bdbae03a620#n180
(0020066)
MS   
2023-04-11 11:08   
Although a valid issue, that can be moved to another release because Nexus
will rarely be exposed online AND have more than one user at the first deployment
with Postfinance. On top of that, the note above shows that checks do take place.

It remains to check WHERE ELSE they may be needed and test them.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7766 [Taler] libeufin-nexus major have not tried 2023-03-14 10:52 2023-04-17 11:41
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Production deployments need "since-last" when downloading bank transactions.
Description: Tasks that download bank transactions need "since-last" as the "range-type" (see API doc below),
in order to avoid data loss in case one batch doesn't get stored in the database.

This problem exists, for example, with the "latest" range type. If "latest"-batch at time T doesn't
arrive to the database, then "latest"-batch at time T+1 will likely NOT include payments from T,
resulting in data loss.

https://docs.taler.net/libeufin/api-nexus.html#post-nexusBase-bank-accounts-acctid-schedule
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7785 [Taler] libeufin-nexus minor have not tried 2023-03-31 18:40 2023-04-17 11:40
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Error handling mixes up bank- and EBICS-technical errors.
Description: For example, if Nexus submits a payment with the wrong currency, then
an error object named EbicsProtocolError is thrown and it carries the error
code from the bank in its 'ebicsTechnicalCode' field.

The error in question is NOT EBICS-technical because the problem was in
the EBICS _payload_ and NOT in the EBICS communication itself.

The fix should provide this difference, and as well be the occasion to review
the code to spot other places where the same problem lies.
Tags:
Steps To Reproduce:
Additional Information: The test case 'unsupportedCurrency()' at EbicsTest.kt reproduces the wrong currency scenario.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6046 [Taler] libeufin-bank major have not tried 2020-01-15 10:12 2023-04-17 11:19
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Must distinguish between booked and non booked transactions
Description: To implement C52 and C53 messages, the database should allow to qualify transactions as "booked" or "non-booked".
Tags:
Steps To Reproduce:
Additional Information: In particular, non-booked transactions must be excluded from CAMT.053 responses.
Attached Files:
Notes
(0015913)
Marcello Stanisci   
2020-05-15 19:07   
Still open.
(0019816)
MS   
2023-02-13 18:14   
Removing the 0.9.2 target as this issue suggests to emulate traditional banks. That doesn't fit into the current regional currency scenario.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5830 [Taler] merchant backend API (C) feature have not tried 2019-08-17 19:26 2023-04-13 21:58
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement request tunneling for wallets
Description: The /proxy API should be implemented to allow the wallet to tunnel requests to the exchange and merchant backend via a PoS terminal.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014870)
Florian Dold   
2019-09-06 11:51   
Moving this to a later milestone.

Currently the Android PoS app does the tunneling. Doing the tunneling through the merchant backend would be much nicer, but is not really urgently needed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6383 [Taler] libeufin-nexus minor have not tried 2020-06-15 08:54 2023-04-13 21:49
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support notifications / "long polling" for certain operations
Description: For the UI, we might want to support web socket notifications.

For the TWG, we need to support long polling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019959)
MS   
2023-03-13 11:03   
TWG part addressed, see 0007693.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6387 [Taler] libeufin-nexus tweak have not tried 2020-06-16 12:05 2023-04-13 21:48
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: more integration tests for key management needed
Description: Right now we mostly cover the "happy path" in key management, but we should also cover error cases.

For example, real banks don't set the subscriber to "ready" after INI and HIA. We thus need a test to make sure that Nexus handles this situation correctly: A sent INI/HIA where the subscriber keys aren't activated on the bank side yet.

Some of these might require support from the sandbox.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6368 [Taler] libeufin-nexus tweak have not tried 2020-06-08 21:17 2023-04-13 21:47
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: test message chunking
Description: Right now we mostly have EBICS transactions with one segment. We also need test cases for bigger EBICS order payloads.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6698 [Taler] libeufin (general) minor have not tried 2021-01-14 00:27 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: general code cleanup required
Description: There are currently quite a number of compile-time warnings as well as linter issues pointed out by IntelliJ.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6973 [Taler] libeufin (general) minor have not tried 2021-08-03 14:54 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: CLI integration test should test nexus permissions
Description: ... both positive (=yes, allowed user can access this) and negative (=no, without permissions the user can't access)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6364 [Taler] libeufin (general) text have not tried 2020-06-04 16:37 2023-04-13 21:46
Reporter: MS Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: Comments style.
Description: From a private conversation:

I've seen that some comments in LibEuFin use the

/**
 * foo
 * bar
 */

style. While this is not really a big issue, I just wanted to mention
that comments beginning with "/**" usually indicate doc comments. That
is, comments that are relevant to the documentation generator (doxygen,
dokka, ...).

As such, it's better style to use "//" comments or "/*" comments (single
start) for comments that just explain what's going on inside the code,
as opposed to comments that represent the documentation for some
"documentable" element, such as functions, class members, etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6399 [Taler] libeufin-nexus minor have not tried 2020-06-19 14:19 2023-04-13 21:45
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: review and document date/time/timezone handling
Description: Especially for EBICS order params.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6972 [Taler] libeufin-nexus minor have not tried 2021-08-03 14:53 2023-04-13 21:42
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: review /facades and /facades/${id} implementation
Description: We currently have a lot of code duplication there, and the code is not generic for the facade, but only works with the TWG facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7168 [Taler] libeufin (general) feature have not tried 2022-02-02 07:38 2023-04-13 21:41
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: remove non-Access-API command from libeufin-cli
Description: That should happen after having removed their use from wallet tests.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6248 [Taler] libeufin-nexus tweak have not tried 2020-05-21 09:01 2023-04-13 21:39
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: test error handling during subscriber initialization
Description: Right now we assume everything goes okay.

We should have a *separate* test case where we mess with the sandbox during the subscriber initialization. For example, we can "undo" the INI on the sandbox and see if the nexus correctly reports what's going on.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6721 [Taler] libeufin-nexus minor have not tried 2021-01-25 15:14 2023-04-13 21:38
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: consider a way to synchronize the row_id with the TWG
Description: We should be able to recover as cleanly as possible in case the LibEuFin state somehow gets purged.

The TWG might notify the exchange to reset to a lower row_id when the transactions request is "unreasonable".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017393)
Christian Grothoff   
2021-01-25 23:23   
I don't think the exchange can possibly reset -- it must not have duplicate row IDs. More importantly, it is necessary that the auditor sees/computes the same row IDs!

So what instead can/should be done, is that a resuming libeufin can be told to _begin_ its row IDs at a non-zero offset. That offset could then be extracted from the exchangedb.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5962 [Taler] libeufin-nexus minor have not tried 2019-11-08 19:46 2023-04-13 21:34
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: find out details about EBICS case sensitivity
Description: Apparently some EBICS clients treat data in a case-insensitive way and upper case even when they got data (e.g. transaction IDs) in lower case.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6382 [Taler] libeufin-nexus minor have not tried 2020-06-15 08:47 2023-04-13 21:31
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support transaction fetching since last successful bank-side creation date/time
Description: Thus we can request transaction history without any gaps.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016330)
Florian Dold   
2020-06-21 16:06   
A rudimentary version of this is implemented, however the EBICS-related timezone mess still needs to be sorted out.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7786 [Taler] libeufin-nexus minor have not tried 2023-03-31 18:43 2023-04-13 21:31
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Taler facade throws EBICS errors.
Description: The Taler facade faces only clients that are unaware of EBICS. For this reason it should throw the more
generic NexusError objects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7789 [Taler] libeufin-bank major always 2023-03-31 20:33 2023-04-13 20:52
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Can delete account when balance is 0
Description: This error is thrown

org.postgresql.util.PSQLException: ERROR: update or delete on table "ebicssubscribers" violates foreign key constraint "fk_ebicsuploadtransactions_subscriber_id" on table "ebicsuploadtransactions" Detail: Key (id)=(10) is still referenced from table "ebicsuploadtransactions".


The account was a non-circuit account
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020035)
MS   
2023-04-07 14:50   
Lowering the priority because no regional setup will have EBICS accounts
in Sandbox and demo setups with EBICS have no reason to delete the only
EBICS account: exchange's.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6713 [Taler] libeufin-nexus minor have not tried 2021-01-21 16:53 2023-04-13 20:50
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: implement exporting a TWG facade for easier upgrades of LibEuFin
Description: Due to the way that the Taler Wire Gataway works, we can't just "start from zero". An easy way to avoid costly migration code would be to offer an export feature for the facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7344 [Taler] demobank-ui text have not tried 2022-09-08 20:40 2023-04-13 20:33
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: withdraw target unclear
Description: One user was confused where the money would go when withdrawing money from the bank. The idea that it would go into the Wallet/Webextension in the browser (or on a Mobile phone) was completely alien. He would have liked to FIRST specify the destination before selecting an amount.

Idea: maybe do it more parallel to what we do in the wallet, where we can now specify "send money" and then pick "to wallet" or "to bank account" -- and then ask for the amount?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7345 [Taler] demobank-ui feature N/A 2022-09-08 20:42 2023-04-13 20:32
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: User confused by captcha
Description: User was confused why a captcha was needed, did not see link to PIN/TAN. I guess we should probably really collect a phone number on account creation and send an actual SMS even in the demo...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7509 [Taler] documentation text have not tried 2022-12-01 19:01 2023-04-13 20:31
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: libeufin-sandbox API doc lacks response status codes.
Description: Make sure that every endpoint has their HTTP response status and/or make a disclaimer where obvious statuses are omitted.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7365 [Taler] exchange API (HTTP specification) feature N/A 2022-09-18 11:33 2023-04-08 10:02
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: KYC fee is never charged / not speced or implemented
Description: The taler-exchange-offline tool (already) has a means to specify a KYC fee, and in principle the "/kyc-check" endpoint could generate a 402 payment required for the KYC process. However, the detailed 402 response is unspecified and also not implemented.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019170)
Christian Grothoff   
2022-09-22 15:36   
There's now a high-level hint of the exchange possibly returning a 402 in the /kyc-check spec.
(0019224)
Christian Grothoff   
2022-10-18 19:17   
Discussion today: have different KYC fees per trigger.
(0019225)
Christian Grothoff   
2022-10-18 19:27   
Charge KYC fees either to reserve (incl. wallet's long-term reserve for balance trigger) or to outgoing wire amount.
(0019226)
Christian Grothoff   
2022-10-18 19:27   
(Last edited: 2022-10-18 19:28)
As long as frees cannot be paid, transaction is simply on hold until KYC threshold is gone below or balance goes high enough to pay KYC fee.
(0019697)
Christian Grothoff   
2023-01-21 21:21   
Given that AML may trigger KYC, I think the _only_ case where we legitimately can and should charge a KYC fee is if a client explicitly asks for it -- e.g. because they want to get attributes signed for invoicing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7271 [Taler] exchange API (HTTP specification) feature N/A 2022-07-05 11:27 2023-04-08 10:01
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: exchange-to-exchange wad transfers are not implemented
Description: This is a feature for W2W payments across exchanges. Places in the code that are related are marked with this bug number.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7737 [Taler] merchant backend API (HTTP specification) feature always 2023-03-02 13:55 2023-04-08 10:01
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: merchant with a wallet should be able to fill a reserve for tipping
Description: wallet support starting a deposit with a payto URI and right now it fills a contract with some empty values
but this deposit will make a wire transfer to the exchange without the reserveId

The exchange could detect if "merchant_payto_uri" in the DepositRequest of https://docs.taler.net/core/api-exchange.html#deposit is the same of the exchange account and then it could reuse some fields to get the reserve id (maybe the order_id?)

With this there is no need of a wire transfer and it make the transaction efficient
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019916)
Christian Grothoff   
2023-03-02 15:41   
Actually, we should use the P2P transfer feature for this. That requires then no changes at the exchange. All we need is for the merchant backend/SPA to generate an 'invoice' (pull payment request) using its tipping reserve private key!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7267 [Taler] exchange major always 2022-06-30 10:31 2023-04-08 09:56
Reporter: oec Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: TEH_make_coin_known needs proper conflict handling and evidence gathering
Description: Right now, TEH_make_coin_known calls TEH_RESPONSE_reply_coin_insufficient_funds in the cases TALER_EXCHANGEDB_CKS_DENOM_CONFLICT and TALER_EXCHANGEDB_CKS_AGE_CONFLICT. This is not correct because that function does not gather the required evidence for the noticed conflicts.

We need a new conflict resolver/evidence gatherer function for those cases. It must take into account the usage of the coin in deposits, p2p or refunds (and maybe other circumstances?)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018951)
oec   
2022-06-30 10:33   
And we need test cases for those situations, too!
(0018952)
oec   
2022-06-30 10:40   
Also, other places that call TEH_RESPONSE_reply_coin_insufficient_funds might require similar treatment


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6954 [Taler] merchant backoffice SPA feature have not tried 2021-07-23 14:20 2023-04-05 18:37
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: create sample deployment to test external authentication
Description: We currently have only tested the SPA with merchant-internal token authentication.

We should create a very simple test deployment (with fixed auth information in, say, nginx) to make sure that the SPA handles external auth properly (both conceptually and in the implementation).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3476 [Taler] wallet-core feature have not tried 2014-07-01 18:49 2023-04-05 18:36
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: evil exchange testsuite
Description: There should be an "evil" exchange testsuite, which tries to trigger edge- or error cases in the customer implementation.

Preferably, the result of these test cases should be that the customer can always construct a cryptographic proof that demonstrates the exchange's failure. This is of course only possible for byzantine failures, and not for denial-of-service.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012906)
Christian Grothoff   
2018-03-27 17:30   
With Twister, we now have in principle the infrastructure in place for this, but we naturally need to modify the (existing?) wallet tests to trigger the Twister at the right times. This sounds like it would be best done in May or June as a collaboration between Marcello and Florian.
(0013233)
Christian Grothoff   
2018-09-17 11:31   
Changing to be against wallet, as this is about testing the wallet and the wallet thus needs to do the required twister instrumentation. (Do we have a separate bug for the merchant backend? Do we need one?)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7270 [Taler] exchange API (HTTP specification) feature N/A 2022-07-05 11:25 2023-04-05 18:35
Reporter: Christian Grothoff Platform: i7  
Assigned To: oec OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: extension support is not implemented everywhere consistently
Description: Places in the code related to where extension support is known to be missing are (to be) marked with this bug number.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019353)
oec   
2022-11-04 14:02   
Commit 752f10273860d2496fc3eb1e03de6ad4451e7c0f and 680ae81d860eb9bde951a3f95c0da06c111b66f8 fixes most of the places, and tests pass.

Missing: add tests with policy_details set.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7498 [Taler] exchange API (HTTP specification) major always 2022-11-28 14:19 2023-04-05 18:34
Reporter: oec Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: fee structure considerations (was: Incoherent calculation of fees during withdraw)
Description: With the latest wallet webextension (commit 3577227cc0ff0f9e0c422ae34c4407d88e98ec21) there is an inconsistency with the transaction fee calculation:

A withdraw amount of '10' leads to an transaction fee of '-0.13'.
A (higher) withdraw amount of '10.01' leads to a transaction fee of (only) '-0.01'.

Is this the result of a miscalculation or the fee-structure of the denominations?
Tags:
Steps To Reproduce: A)
1. On the withdraw form, I enter '10' as the value.
2. On the next dialog, I see '-0.13' as the transaction fee.

B)
1. On the withdraw form, I enter '10.01' as the value.
2. On the next dialog, I see '-0.01' as the transaction fee.
Additional Information: - exchange config attached.
Attached Files: 2022-11-28-141823_715x727_scrot.png (40,220 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1278&type=bug
2022-11-28-141747_681x742_scrot.png (44,078 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1279&type=bug
c.conf (5,030 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1280&type=bug
Notes
(0019485)
sebasjm   
2022-11-28 15:58   
Well, I see that if you wire transfer 10.01, the exchange will give you 1 coin of 10 with the fee of 0.1 (as seen in the config)

If you wire transfer 10, it will discount 0.01 for every coin used an that will depend on the configuration.

I don't see any bug here.
(0019486)
oec   
2022-11-28 16:20   
(Last edited: 2022-11-28 16:38)
Here is why this is broken, IMHO:

1. A user enters '10' to receive an amount of '10' because he/she needs that much.
2. On the next dialog page the user sees that he/she won't receive '10' but only '9.87' due to fees of '0.13'
3. But the user wants _10_ not, 9.87, so goes back and enters '10.13' instead, to include the fees.
4. But now, surprisingly, the result is '10.11' and the fees seem to be _lower_ for a _higher_ amount.

As a user I find this incoherent. Why should the user care about the demonination-structure and additive model for fees in the exchange?

I think the following are potential, orthogonal solutions:

a) Add to the withdraw form an option to either _include_ or _exclude_ the fees in the amount to be withdrawn. That way, the user wouldn't be confused in first place.

b) Change the fee mechanism for withdraw in the exchange to be based on the total _amount_ to be withdrawn, not the particular _denominations_ needed for that amount.
(0019487)
oec   
2022-11-28 16:34   
(Last edited: 2022-11-28 16:34)
... c) Make the fees for denomations additive: D1 = N*D2 => fee(D1) = N*fee(D2). The auditor can check that, too.
(0019496)
Christian Grothoff   
2022-12-05 10:34   
Well, let's see about (c):
1) Obviously, the lowest possible fee must be the lowest denomination, let's say that is 0.01 KUDOS.
2) Then for a 0.01 KUDOS coin, the deposit fee must be 0.01 KUDOS.
3) By your math, the fee for a coin of value X must then be X.
Consequently, you can only pay fees, but never merchants. See the problem?
(0019498)
oec   
2022-12-05 14:22   
Not if the fee(v) = q*v with 0 < q << 1 and we only round up to D_0 at the end of the calculation, no?

However, I agree that (b) and (c) don't discourage the withdrawal of many small denominations.
(0019499)
Christian Grothoff   
2022-12-05 14:35   
There are more problems with (c): the fees end up either too low for our business model (where microtransactions are where we can make real profits), or too high to be competitive with traditional payment systems for larger amounts. Imagine q=1%. Then for a 1cent transaction, you may make too little profit. But for a 1000 EUR transaction, your fee is already insanely high. Logarithmic fees are actually good for Taler, it makes us competitive in all markets.
(0019500)
oec   
2022-12-05 15:53   
That leaves option a) above.
(0020033)
Florian Dold   
2023-04-05 18:34   
I think we should write down these considerations somewhere outside of the bug tracker.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6565 [Taler] wallet-core feature have not tried 2020-09-03 20:46 2023-04-04 19:41
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version: