View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5933 [GNUnet] other text have not tried 2019-10-16 18:35 2019-11-20 01:33
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: translate the eV satzung
Description: translate the eV satzung to English
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015080)
Christian Grothoff   
2019-11-16 18:33   
Eh, no. That's a legal document. Doing a legally-binding translation is virtually impossible, and there is also no need.
(0015089)
ng0   
2019-11-20 01:32   
as per discussion, reopened: https://lists.gnu.org/archive/html/gnunet-developers/2019-11/msg00012.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5949 [GNUnet] build process minor have not tried 2019-10-26 12:13 2019-11-20 01:31
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.11.6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.12.0  
    Target Version: 0.12.0  
Summary: check if lint can be restructered and if this error is still in HEAD
Description: Making all in lint
--- check-bashism ---
--- check-python ---
--- check-man ---
--- check-texinfo ---
--- check-bashism ---
printf "Run checkbashism on all .sh files.\n"
Run checkbashism on all .sh files.
printf "Currently this expects checkbashism.pl at a fixed location."
Currently this expects checkbashism.pl at a fixed location.find '..' -type f ! -path '*/.*' ! -path '*/_*' -name '*.sh' -print0 | xargs -0 ./checkbashisms.pl -f 2>&1 | tee ./bashism.log || true
--- check-python ---
printf "Running flake8 and 2to3 if detected.\n"
Running flake8 and 2to3 if detected.
../contrib/scripts/lint-python.sh || true
sh: ../contrib/scripts/lint-python.sh: not found
--- check-man ---
printf "Running lint-man.sh in doc/man.\n"
Running lint-man.sh in doc/man.
sh: ../../contrib/scripts/lint-man.sh: not found
--- checkbashisms.pl ---
--- check-texinfo ---
printf "Running basic texinfo linters\n"
Running basic texinfo linters
printf "...lines containing tabstops?\n" 2>&1 | tee ../doc/handbook/texinfo_handbook.log || true
--- checkbashisms.pl ---
/usr/bin/sed -e 's,[@]PERL[@],/usr/work/wip/gnunet/work/.tools/bin/perl,g' < ./checkbashisms.pl.in > checkbashisms.pl
--- check-texinfo ---
...lines containing tabstops?
printf "...lines containing tabstops?\n" 2>&1 | tee ../doc/tutorial/texinfo_tutorial.log || true
--- checkbashisms.pl ---
chmod +x checkbashisms.pl
--- check-texinfo ---
...lines containing tabstops?
--- check-bashism ---
./checkbashisms.pl: use: not found
./checkbashisms.pl: use: not found
./checkbashisms.pl: 25: Syntax error: "(" unexpected
--- check-texinfo ---
cd: can't cd to ../doc/tutorial
printf "...line length over 79 chars?\n" 2>&1 | tee ../doc/handbook/texinfo_handbook.log || true
tee: ../doc/handbook/texinfo_handbook.log: No such file or directory
...line length over 79 chars?
cd: can't cd to ../doc/handbook
printf "...line length over 79 chars?\n" 2>&1 | tee ../doc/tutorial/texinfo_tutorial.log || true
tee: ../doc/tutorial/texinfo_tutorial.log: No such file or directory
...line length over 79 chars?
cd: can't cd to ../doc/tutorial
printf "...lines containing macros incompatible with old makeinfo?\n" 2>&1 | tee -a ../doc/handbook/texinfo_handbook.log || true
tee: ../doc/handbook/texinfo_handbook.log: No such file or directory
...lines containing macros incompatible with old makeinfo?
cd: can't cd to ../doc/handbook
printf "...lines containing macros incompatible with old makeinfo?\n" 2>&1 | tee -a ../doc/tutorial/texinfo_tutorial.log || true
tee: ../doc/tutorial/texinfo_tutorial.log: No such file or directory
...lines containing macros incompatible with old makeinfo?
cd: can't cd to ../doc/tutorial
printf "...lines containing macros incompatible with texi2mdoc?\n" 2>&1 | tee -a ../doc/handbook/texinfo_handbook.log || true
tee: ../doc/handbook/texinfo_handbook.log: No such file or directory
...lines containing macros incompatible with texi2mdoc?
cd: can't cd to ../doc/handbook
printf "...lines containing macros incompatible with texi2mdoc?\n" 2>&1 | tee -a ../doc/tutorial/texinfo_tutorial.log || true
tee: ../doc/tutorial/texinfo_tutorial.log: No such file or directory
...lines containing macros incompatible with texi2mdoc?
cd: can't cd to ../doc/tutorial
printf "...lines telling us what is left TODO or to fix?\n" 2>&1 | tee -a ../doc/handbook/texinfo_handbook.log || true
tee: ../doc/handbook/texinfo_handbook.log: No such file or directory
...lines telling us what is left TODO or to fix?
cd: can't cd to ../doc/handbook
cd: can't cd to ../doc/handbook
printf "...lines telling us what is left TODO or to fix?\n" 2>&1 | tee -a ../doc/tutorial/texinfo_tutorial.log || true
tee: ../doc/tutorial/texinfo_tutorial.log: No such file or directory
...lines telling us what is left TODO or to fix?
cd: can't cd to ../doc/tutorial
cd: can't cd to ../doc/tutorial
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015034)
ng0   
2019-10-27 12:38   
I forgot that this only happens with --enable-experimental
(0015088)
ng0   
2019-11-20 01:31   
fixed by moving to top Makefile


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5973 [libeufin] sandbox minor have not tried 2019-11-18 19:33 2019-11-18 19:33
Reporter: Marcello Stanisci 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:  
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:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5972 [libeufin] nexus minor have not tried 2019-11-18 19:28 2019-11-18 19:28
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:  
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:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5943 [libeufin] nexus minor have not tried 2019-10-22 16:24 2019-11-18 15:54
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: implement client-side EBICS key management
Description: ... including a command line tool to set up accounts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015087)
Marcello Stanisci   
2019-11-18 15:54   
implemented long ago


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5971 [libeufin] nexus minor have not tried 2019-11-18 14:41 2019-11-18 14:41
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: subscriber and key import and export should be implemented
Description: Right now, export in JSON plus a structured standard format (PKCS#8 for private keys, X509 for public keys) is fine.

Eventually, encryption of the exported keys must also be 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:
5935 [libeufin] sandbox minor have not tried 2019-10-18 19:11 2019-11-18 14:36
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: eliminate conversion to string before responding
Description: The sandbox performs a (costly?) conversion from JAXB to String before returning the response back. There should be a way to pass Ktor the JAXB object without converting it to String first.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015020)
Marcello Stanisci   
2019-10-21 16:00   
It appears that JSON official converter also passes through text conversion: https://ktor.io/servers/features/content-negotiation.html
(0015086)
Florian Dold   
2019-11-18 14:36   
This is unavoidable, but at least now we do

  JAXB -> string

instead of

  JAXB -> DOM -> string


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5915 [libeufin] sandbox minor have not tried 2019-09-30 15:34 2019-11-18 14:31
Reporter: Marcello Stanisci Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: identifiers should include strings
Description: user / partner / system IDs now are plain numbers. Since the specification mandates the use of strings for them, then
it is more readable to define each of them as "uX" / "pX "/ "sX", respectively for user / partner / system IDs, where X is a number.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014976)
Marcello Stanisci   
2019-10-03 18:50   
This feature has been implemented here: 757c39c..15ae048.
(0015085)
Florian Dold   
2019-11-18 14:31   
This has been fixed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5953 [libeufin] other minor have not tried 2019-10-29 10:08 2019-11-18 14:30
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: generate code documentation with Dokka
Description: See https://kotlinlang.org/docs/reference/kotlin-doc.html
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:
5970 [libeufin] other minor have not tried 2019-11-18 14:30 2019-11-18 14:30
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Move shared things between sandbox and nexus to "libeufin-util" module.
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:
5900 [libeufin] sandbox minor have not tried 2019-09-19 01:59 2019-11-18 14:28
Reporter: Marcello Stanisci Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Less verbosity needed.
Description: Logs are (1) too verbose:
2019-09-19 01:47:50,045 ERROR [nioEventLoopGroup-4-2] libeufin-sandbox [Main.kt:48] Invalid request received

and (2) a gigantic amount of stack traces are printed (once) when launching the server:

Using SLF4J as the default logging framework
-Dio.netty.noUnsafe: false
Java version: 8
sun.misc.Unsafe.theUnsafe: available
sun.misc.Unsafe.copyMemory: available
java.nio.Buffer.address: available
direct buffer constructor: available
java.nio.Bits.unaligned: available, true
jdk.internal.misc.Unsafe.allocateUninitializedArray(int): unavailable prior to Java9
java.nio.DirectByteBuffer.<init>(long, int): available
sun.misc.Unsafe: available
-Dio.netty.tmpdir: /tmp (java.io.tmpdir)
-Dio.netty.bitMode: 32 (sun.arch.data.model)
-Dio.netty.maxDirectMemory: 954466304 bytes
-Dio.netty.uninitializedArrayAllocationThreshold: -1
java.nio.ByteBuffer.cleaner(): available
-Dio.netty.noPreferDirect: false
-Dio.netty.native.workdir: /tmp (io.netty.tmpdir)
-Dio.netty.native.deleteLibAfterLoading: true
-Dio.netty.native.tryPatchShadedId: true
Unable to load the library 'netty_transport_native_epoll_x86_32', trying other loading mechanism.
java.lang.UnsatisfiedLinkError: no netty_transport_native_epoll_x86_32 in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at io.netty.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:369)
    at java.security.AccessController.doPrivileged(Native Method)
    at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:361)
    at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:339)
    at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:136)
    at io.netty.channel.epoll.Native.loadNativeLibrary(Native.java:186)
    at io.netty.channel.epoll.Native.<clinit>(Native.java:57)
    at io.netty.channel.epoll.Epoll.<clinit>(Epoll.java:38)
    at io.ktor.server.netty.EventLoopGroupProxy$Companion.create(NettyApplicationEngine.kt:186)
    at io.ktor.server.netty.NettyApplicationEngine.<init>(NettyApplicationEngine.kt:74)
    at io.ktor.server.netty.Netty.create(Embedded.kt:14)
    at io.ktor.server.netty.Netty.create(Embedded.kt:12)
    at io.ktor.server.engine.EmbeddedServerKt.embeddedServer(EmbeddedServer.kt:79)
    at io.ktor.server.engine.EmbeddedServerKt.embeddedServer(EmbeddedServer.kt:67)
    at io.ktor.server.engine.EmbeddedServerKt.embeddedServer(EmbeddedServer.kt:36)
    at io.ktor.server.engine.EmbeddedServerKt.embeddedServer$default(EmbeddedServer.kt:34)
..and MANY others !!

For 1, the line should at least drop the "[nioEventLoopGroup-4-2]" chunk, and for 2 there must be some filtering option to pass to the logger constructor.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015084)
Florian Dold   
2019-11-18 14:28   
Logging is now properly configured.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5884 [libeufin] General minor have not tried 2019-09-09 13:47 2019-11-18 14:27
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: look at kotlin/Java HTTP server libraries to implement the sandbox and cross-bank API
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:
5881 [libeufin] General minor have not tried 2019-09-09 13:37 2019-11-18 14:27
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: study the EBICS specification and come up with an implementation plan
Description: .... in particular, we should figure out the relevant parts that we need to implement.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014875)
Florian Dold   
2019-09-09 13:39   
It might also make sense to see which crypto primitives from the spec we *actually* need to have.
(0015083)
Florian Dold   
2019-11-18 14:27   
We have the detailed implementation plan, and a bit chunk of the implementation is finished.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5919 [libeufin] sandbox feature N/A 2019-10-03 16:26 2019-11-18 14:24
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: sandbox should respond to INI and HIA messages
Description: These are the first messages we get after HEV.

The handler must
* parse the message
* check the database for the subscriber status
* update the database with the newly received keys
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015082)
Florian Dold   
2019-11-18 14:24   
Implemented.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5880 [libeufin] General minor have not tried 2019-09-09 13:36 2019-11-18 14:23
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: look at ebics-java-client
Description: https://github.com/uwemaurer/ebics-java-client
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015081)
Florian Dold   
2019-11-18 14:23   
It's not very good, specific to France, and we support a superset of what it now does.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5947 [libeufin] sandbox minor have not tried 2019-10-24 20:13 2019-11-18 14:22
Reporter: Marcello Stanisci 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:  
Summary: Design generation of "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).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5735 [GNUnet] build process minor have not tried 2019-05-25 14:14 2019-11-16 19:52
Reporter: ng0 Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.11.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: pretify configure end output
Description: detailed listing etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014488)
Christian Grothoff   
2019-06-01 19:36   
ng0, AFAIK you did this, why did you keep this one open?
(0014493)
ng0   
2019-06-01 20:28   
See my post on the mailinglist and read the configure.ac
It is not done.
(0014629)
ng0   
2019-07-01 12:32   
Christian, can you please check and give feedback on how you would improve this? I haven't worked on it again, and no one gave feedback.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5617 [GNUnet] integration tests tweak always 2019-02-28 11:46 2019-11-16 19:51
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: feedback Product Version: 0.11.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: clique test fails
Description: Somehow not all connections go up that should. The test was disabled for 0.11.0 in commit de970e1f0fd6a5deb908d0c60fbb80b029791497. We should get it to pass again and re-enable the test.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014115)
Christian Grothoff   
2019-03-02 11:08   
I've now tested this on wacko, and the test worked (without changes!) just fine. So this seems to be system-specific. I've reactivated the test for now (0b30ad775..2d4b48f0d), maybe we can get a better idea on which systems it is failing that way.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5552 [GNUnet] UDP transport feature N/A 2019-02-08 19:11 2019-11-16 19:51
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: congestion control for UDP
Description: UDP currently does not rate-limit transmissions in the absence of ACKs. We should implement some sane rate limiting here. Some of it likely at the transport-level (for uni-directional communicators), and for incoming messages at least the KX/DH operations need to probably be limited per sender to a certain "fair" share.
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:
5907 [GNUnet] GNS block always 2019-09-25 19:34 2019-11-16 19:51
Reporter: dvn Platform:  
Assigned To: Christian Grothoff OS:  
Priority: urgent OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: APT cannot resolve package servers when libnss GNS plugin enabled
Description: "Something wicked happened resolving 'us.archive.ubuntu.com:http' (-5 - No address associated with hostname)"

This is an example of the type of error message I get from `apt` when the GNS plugin for libnss is enabled, a trying to update the repository list, or install packages. I'm using apt version 1.8.1, on Ubuntu, but I've also experienced this in the past on Debian with (presumably) different versions of apt.

For reference, here is the relevant line from my nsswitch.conf:

"hosts: files gns [NOTFOUND=return] mdns4_minimal [NOTFOUND=return] dns"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: colon-patch.diff (411 bytes) 2019-10-08 20:00
https://bugs.gnunet.org/file_download.php?file_id=857&type=bug
Notes
(0014964)
dvn   
2019-09-25 19:36   
I should add that `curl us.archive.ubuntu.com` works as expected. It resolves.
(0014978)
Christian Grothoff   
2019-10-06 22:00   
That's because curl implements DNS itself and bypasses libc NSS.

"us.archive.ubuntu.com:http" -- maybe that's the issue: does it really pass ":http" as part of the hostname? If that's the case, we might have to simply modify gnunet-gns to ignore everything after the ":".
(0014979)
dvn   
2019-10-06 22:11   
> That's because curl implements DNS itself and bypasses libc NSS.

hmm, but I am able to curl gns names when I have the nsswitch plugin enabled...

> If that's the case, we might have to simply modify gnunet-gns to ignore everything after the ":".

I will try this out.
(0014986)
dvn   
2019-10-08 19:49   
Looking through the GNS module source, I'm unsure where the string ignore should be. Can you point me in the right direction?
(0014987)
Christian Grothoff   
2019-10-08 20:00   
dvn, please try with the attached patch against gnunet-gns.c
(0014989)
dvn   
2019-10-09 22:11   
that does indeed work.

we have some undesirable and inaccurate output preceding the regular APT output though:

Oct 09 13:02:08-648275 gnunet-gns-17982 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-653523 gnunet-gns-17983 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-739994 gnunet-gns-17984 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-748697 gnunet-gns-17985 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-839123 gnunet-gns-17986 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-843210 gnunet-gns-17987 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-896835 gnunet-gns-17988 WARNING Cannot resolve using GNS: GNUnet peer not running
Oct 09 13:02:08-900443 gnunet-gns-17989 WARNING Cannot resolve using GNS: GNUnet peer not running
Hit:2 http://us.archive.ubuntu.com/ubuntu disco InRelease
Hit:3 http://security.ubuntu.com/ubuntu disco-security InRelease
...
(0014990)
Christian Grothoff   
2019-10-09 22:44   
Ok, I've applied the patch to master.
Why do you say the output is inaccurate? Is the peer running? (properly, etc.)?

I must admit I'm also a bit dubious about running gnunet-gns at all as root, as usually there shouldn't be GNUnet processes running as 'root', and the above _could_ only work if root ran a 'full peer'. So maybe an answer would be to test for 0==getuid() and bail if it is true.

As for the output being 'undesirable', what do you propose we do? Not logging anything when we give up if a peer is not running doesn't seem right either...
(0014991)
dvn   
2019-10-10 06:49   
Argh, I typed out a long response and then it timed out when I tried to submit... I thought we fixed this in Mantis years ago! :P

Try again...

> Ok, I've applied the patch to master.
> Why do you say the output is inaccurate? Is the peer running? (properly, etc.)?
>
> I must admit I'm also a bit dubious about running gnunet-gns at all as root, as usually there shouldn't be GNUnet processes running as 'root', and the above _could_ only work if root ran a 'full peer'. So maybe an answer would be to test for 0==getuid() and bail if it is true.

Ah, yes, the output is accurate. I overlooked the fact that the command was running as root, thus unable to communicate with the gns service.

"test for 0==getuid() and bail if it is true" <--- Do you mean for the gns service or the utility? If the service, then that would mean that root could still resolve names as long as the node was setup for multi-user, correct? I'll admit that almost all of my usage and testing of gnunet has been with single-user configurations.
(0015006)
Christian Grothoff   
2019-10-12 20:17   
I think actually libnss should probably be doing that test and bailing. Basically, no GNUnet for root.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5456 [GNUnet] transport service minor N/A 2018-10-11 05:55 2019-11-16 19:50
Reporter: amatus Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: Peers don't gossip about transport addresses they don't support
Description: I'm working on creating a WebRTC transport for gnunet-web but when a gnunet-web peer sends its HELLO with a "webrtc" transport address to a non-gnunet-web peer the address is dropped because the non-gnunet-web peer does not have the "webrtc" transport plugin and cannot validate the address.
We should not be so stringent about what is gossiped or uncommon transport protocols will never work because peers that support them won't find each other.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013671)
Christian Grothoff   
2019-02-12 09:01   
Should be fixed as part of TNG rewrite.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5710 [GNUnet] transport service feature N/A 2019-05-02 14:28 2019-11-16 19:50
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: confirmed Product Version: 0.11.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: TNG meta issue
Description: This is the transport "next generation" (TNG) meta issue. Bugs in TRANSPORT that we expect to be fixed by the TNG re-design should be *related* to this bug. Issues that are to be addressed so we can call TNG "done" should be come *child* issues of this bug.
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:
5950 [GNUnet] build process minor have not tried 2019-10-26 13:05 2019-11-16 19:50
Reporter: ng0 Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: add configure switches for conversation
Description: needs flags to disable subsets and recommend them if a dependency is (not) found.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015030)
ng0   
2019-10-26 15:21   
all that is missing is recommendations.
(0015035)
ng0   
2019-10-27 12:40   
please tell me what your idea of messages is for these options.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5645 [GNUnet] DNS service major sometimes 2019-03-13 10:46 2019-11-16 18:42
Reporter: ic.rbow Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: Issuing request to a local DNS service breaks node
Description: I found there is a local resolver service running that gets DNS traffic from iptables and decided to try it.

The dig query timed out, but I found gnunet-arm went unresponsive and there's a constant stream of ERROR/MQ messages in transport and ats logs:

    Mar 13 08:21:00-682310 transport-25692 ERROR MQ with 10000 entries extended by message of type 364 (FC broken?)

    Mar 13 09:35:54-724788 ats-28266 ERROR MQ with 10381 entries extended by message of type 345 (FC broken?)

The spew persists after restarts and seems to die out after a while.
Tags:
Steps To Reproduce: 1) gnunet-arm -i dns
2) dig www.W4GVVA8FXH1QPTHS533MZTGASTSKK3MWGGTBH9T0WMFDR482CE4G @169.254.1.1
3) ????
4) Watch transport and ats go haywire.
Additional Information:
Attached Files:
Notes
(0014191)
ic.rbow   
2019-03-13 10:57   
I tried to reproduce it a with and without UDP transport enabled and it is much more stable. The dig still silent, but at least the logs aren't getting hammered.

Additionally, issuing `gnunet-transport -in` dumps a limited amount of MQ errors [in ats logs] with UDP enabled, but silent otherwise.
(0014368)
Christian Grothoff   
2019-05-02 14:26   
I'm not sure this is related to the local DNS request, usually those errors appear after a while just in general AFAIK. And getting this mess under control is why I'm rewriting TRANSPORT/ATS in the "TNG" redesign these days...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5550 [GNUnet] transport service feature N/A 2019-02-08 19:06 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: backchannel support
Description: The UDP plugin will attempt to transmit messages via the so-called backchannel feature (GNUNET_TRANSPORT_communicator_notify()). While in 0005547 the test should just drop backchannel data, for this version of the test the test driver should pass backchannel data to the other peer (GNUNET_TRANSPORT_CommunicatorNotify()).

Performance (goodput, latency) should be measured as before.

This variant of the test should also use the same basic C code, with the backchannel feature being controlled by a simple testcase driver option in the configuration file (i.e. [communicator-test] ENABLE_BACKCHANNEL = YES/NO).
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:
5549 [GNUnet] transport service feature N/A 2019-02-08 19:03 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: bidirectional communicator test
Description: A variant of the 0005547 test should check that the receiving peer also is notified about a MQ when there is an incoming connection, and then use both MQs to transmit messages in both directions (and measure goodput/avg. latency). This test should only be activated for fundamentally bidirectional channels (UNIX, TCP, HTTP(S)).
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:
5548 [GNUnet] transport service feature N/A 2019-02-08 18:59 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: communicator rekey test plan
Description: For this test, the communicator logic must be changed to introduce an option for the rekey frequency. Then, the test case should use a configuration setting the rekey frequency to say 100ms. Finally, as 0005547 messages should be transmitted for 2 seconds, again measuring communicator performance.

Note that the actual C code of the test should be *identical* to that of 0005547, only support for a retransmission frequency option must be added (currently a #define) and set to a small value in the respective configuration.
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:
5547 [GNUnet] transport service feature N/A 2019-02-08 18:54 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: schanzen OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: communicator basic test plan
Description: This issue describes the most basic test we should do for communicators.

The high-level test setup should be a test driver which also pretends to be *two* transport services, using different service configurations (say udp1.conf and udp2.conf) with the main difference being different ports/UNIXPATHs and the PeerIdentity. There, it needs to offer support for (some of) the messages that the gnunet_transport_communication_service.h API transmits to the transport service. The test driver should furthermore launch two communicator processes, again based on different configurations (udp1.conf and udp2.conf) differing in the port that is being used.

The test should then expect both communicators to notify it about their own address (i.e. 127.0.0.1:PORT). In response, the transport should give to one of them the address (and PID) of the other (triggering CommunicatorMqInit). Depending on the plugin, it should then expect an MQ to be created at one end (UDP) or both ends (TCP). It should then use the MQ to transmit a message, and verify that the other peer receives the message. The basic test should only test uni-directional communication, but with different message sizes (0-UINT16_MAX bytes).

The test should transmit short messages (0000118:0000128 bytes) for 2s and long messages (32kb) for 2s, followed by one round of messages ranging from 0 to 65535 in steps of 5 bytes (correctness only). The test should then output the achieved goodput for short messages (# 128b * msg received / 2s), good put for long messages (# 32kb * msg received / 2s), and also the latency (average, for both categories).

This test should be universally applicable for all communication protocols given the right pair of configuration files. Thus, the suffix of the test binary (i.e. test_communicator_basic_$SUFFIX) should be used to determine the configuration files (i.e. test_communicator_basic_$SUFFIX{1,2}.conf), so that the same test C code can be re-used for testing TCP, UDP, HTTP (with client & server) or any other communication protocol.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014661)
ch3   
2019-07-07 22:48   
This was started with test_communicator_unix.
transport-testing2.{h|c} provides a (communicator-independet) api for testing communicators. (Which is not finished, yet.)
The unix test should be able to be used as a generic template for testing other communicators.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5530 [GNUnet] TCP transport feature N/A 2019-01-28 19:24 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: add replay protection to TCP communicator
Description: As TCP is always bi-redirectional, we can easily add some weak form of replay protection by simply adding a nonce to the KX and requiring that the nonce is sent back. To avoid increasing latency on the initial handshake (and knowing that the first bytes sent will be CORE/CADET KX in all likelihood anyway) we would then simply require that after N bytes the nonce is played back to us.
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:
5529 [GNUnet] TCP transport feature have not tried 2019-01-28 19:21 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: TCP communicator does not support connection reversal yet
Description: For the autonomous NAT traversal method, TCP communicator still needs to implement the function for connection reversal. Shouldn't be too hard.
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:
5528 [GNUnet] TCP transport feature N/A 2019-01-28 19:19 2019-11-16 18:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: TCP *communicator* bindto option should support DNS names
Description: Right now, only numeric IPv4/IPv6 addresses are allowed.
Note that this might be a tad tricky, as DNS names can yield multiple IPs. But we should at least support just resolving a name to the first DNS response.
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:
5482 [GNUnet] testbed service minor sometimes 2018-11-23 08:00 2019-11-16 18:41
Reporter: Heiko Stamer Platform:  
Assigned To: OS: Gentoo Linux  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: Some CADET tests failed
Description: Unfortunately, now some CADET tests failed:

FAIL: test_cadet_2_keepalive
============================

Nov 23 00:27:53-526608 test-15804 DEBUG DIRECT CONNECTIONs
Nov 23 00:28:14-771784 test_cadet_small-15804 ERROR FAILED! (1/2)
FAIL test_cadet_2_keepalive (exit status: 1)

FAIL: test_cadet_5_speed_backwards
==================================

Nov 23 00:30:23-513143 test-16705 DEBUG 5 PEER LINE
Nov 23 00:30:23-513195 test-16705 DEBUG SPEED
Nov 23 00:30:23-513205 test-16705 DEBUG BACKWARDS (LEAF TO ROOT)
Nov 23 00:30:53-561549 testbed-api-topology-16705 WARNING Error while establishing a link: 0xb: Timeout while acquiring ATS of DK5W from cache -- Retrying
Nov 23 00:30:53-631548 test_cadet_small-16705 ERROR Some links failed (1), ending
Nov 23 00:30:53-638258 transport-16773 ERROR Assertion failed at peerinfo_api.c:567.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013674)
Christian Grothoff   
2019-02-12 09:06   
These are actually issues either from transport or testbed (most likely transport) that happen on a heisen-bug basis. Not something cadet can fix. I expect this will be addressed with TNG.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3896 [GNUnet] transport service feature always 2015-07-17 01:19 2019-11-16 18:41
Reporter: dangole Platform: any  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: GNUnet HELLOs break privacy, especially on IPv6
Description: GNUnet's transports publish all IPv6 addresses they listen on.
However, only globally routed addresses should be made available publicly. Also it is questionable whether EUI-64 addresses should be published at all, as users usually do not randomize their MAC addresses and thus leak their client device's indentity with every single network packet when using EUI-64 generated IPv6 addresses when using addresses using that scheme defined in RFC 2373 Appendix A.

This is even more of a problem if RFC 3041 privacy addresses are configured on the same interface and prefix, in that case only the Temporary Addresses as defined in RFC 3041 should be bound and used for GNUnet by default.

Similarly, leaking addresses allocated wthin (constant!) local ULAs as in RFC 4193 which should not be made available globally.
On IPv4, the same issue also exists as addresses within the private ranges defined by RFC 1918 (192.168/16, 10/8, 172.16/12)
The same applies to any non-globally addresses identifying local WiFi or bluetooth interfaces.
Generally, when using GNUnet inside private or local networks *as well as* public global internets, GNUnet should make sure not to leak the users identity on one network onto any other network.

Thus, peerinfo should be provided in a source-routing manner depending on who is asking and only provide addresses within the same family (v4,v6,802.1) and isolate public/private ranges.

Providing peering information over a certain interface which are outside of the routable range of that interface rarely provides any benefit compared to the huge privacy issue it creates.
Tags:
Steps To Reproduce: Install GNUnet. Oops, I just leaked my hardware MAC addresses...
Additional Information:
Attached Files: hide-lan-addresses-from-hello.patch (572 bytes) 2018-08-04 22:12
https://bugs.gnunet.org/file_download.php?file_id=780&type=bug
Notes
(0009462)
Christian Grothoff   
2015-07-17 22:54   
Ok, this is going to be a complicated discussion, but maybe worth it.

First of all, you're confusing 'user identity' and 'peer identity'.
HELLOs allow other peers to link your network addresses to your peer identity.
That's by design, and anonymous routing should be used to decouple the actions of your user(s) from your peer (so that it is no longer clear which actions/users are originating from which peer). If you want to globally hide your IP address, you need to configure GNUnet in F2F-mode and hope that your friends don't disclose the information (the code contains a flag to let them know that they shouldn't do this). But that's not quite the question here, I'm just explaining to make sure we're on the same page.

Now, I read two or three issues in your report, which is basically that we should disclose less information (which, I agree, would always be good):

1) with respect to private or link-local LAN IPs, you argue that they are useless beyond the link/LAN and should thus not be globally announced;

2) with respect to IPv6-addresses containing the user's MAC, you argue those should not be disclosed "ever"

3) with respect to an IPv6 interface having multiple IPv6-IPs, you argue we should then definitively only use the 'privacy' IP.

My problem is that I agree philosophically, but disagree technically. Let me explain: you may have two peers in the same LAN. They could nicely bypass the NAT, or not even configure global IPv6 addresses using local addresses. So those addresses *are* sometimes useful to talk to other peers --- and we may never know up-front that those peers are in our LAN. And if we get their global IP only, and the NAT doesn't support hairpinning, we'll just not be able to connect to them -- on the LAN!!! What a disaster. :-).

Anyway, this is why we typically grab all IPs we can get hold of, just in hope that they might be useful (note that the WLAN transport will quite explicitly advertise your MAC just for that very purpose!).

Now, I could imagine a compromise setting, where we use the existing IPv6 multicast and UDP/WLAN broadcasts to announce LAN/LL/MAC addresses, but don't stick those into "global" announcements. That'll limit the LAN-discovery to UDP/WLAN, but maybe that's enough (especially since that LAN discovery could still also discover TCP LAN addresses via the UDP announcements).

I think this would make a good default -- but it will be tricky to implement right (but likely worthwile, as shipping all of those LAN IPs globally is pretty useless/wasteful -- in addition to the privacy issue).


With respect to global IPv6 addresses including a MAC, that IS a fundamental configuration bug of the OS and not a GNUnet issue. For that, my answer would be that you should fix your OS setup. That's not GNUnet's fault.

Also, if a system has multiple globally routable IPv6 addresses, I don't see how we could decide which ones would be better to use. I do think the user can already specify a particular IP to use exclusively via config option. But automatically, I have no hope.

My 2 cents, comments welcome!

Oh, and thanks for the interesting report.
(0009465)
dangole   
2015-07-18 22:29   
You fully understood the issues and I agree with the solutions you suggest as well as with the fact that most problems on this planet are due to wrong configuration of all the other stuff out there ;)

You are right that this shouldn't directly compromise the privacy of GNUnet users. However, it exposes identifying bits about the system running GNUnet and it's network environment which is still a serious problem, given that this could be avoided.
I also agree that IPv4 addresses within the private ranges (RFC 1918) are sometimes useful for peers to connect when behind the same NAT but inside different isolated broadcast/multicast domains. The impact of making RFC 1918 addresses public is not that big when behind telco-supplied stock-routers, but may be more servere when inside a larger piece of non-globally-routed infrastructure such as DN42 or networks of big organizations.

Regarding the choice of IPv6 addresses to publish globally, it's easy to recognize globally routed addresses (2::/8 I guess). Classifying potentially privacy-breaking EUI-64 generated addresses is just as easy as their 12th and the 13th octect are always 0xff and 0xfe.
It is true that privacy-decissions have been pushed down from the OS level to the application level in the current IPv6 modell. Browsers and other applications responded and use only addresses chosen based on the purpose of the application (local/global, identifyable/anonymous) from a set of addresses (I'm not saying that I love the idea of browsers doing STUN in other places which has an impact similar to what's being discussed here).
Clearly, the current situation of IPv6 is not GNUnet's fault. Nevertheless GNUnet has to make wise choices to provide a maximum of safety to potentially naiive users. I kind of agree with your more-radical-than-intended re-phrasing of point 2), however, I believe that applies even more on systems with RFC 3041 privacy addresses configured where GNUnet's current behaviour also impacts other applications used on the same system as it practically undermines the whole concept of RFC 3041 which assumes that the permanent (= containing the MAC) address is never going to be associated to a temporary (= random) address...
(0010055)
dangole   
2016-01-15 11:08   
(Last edited: 2016-01-15 11:11)
This issue is similar to
http://www.heise.de/netze/meldung/Firefox-und-Chrome-verraten-IP-Adressen-trotz-VPN-2534438.html (article about Firefox leaking IPs of *other* interfaces if WebRTC is enabled).
Just like here, a method intended to easy NAT-traversal and allow peers to discover more feasible paths between each other can be a privacy-leak.

(0010087)
lynX   
2016-01-23 02:01   
(Last edited: 2016-01-23 02:04)
Fuck you Mantis, I wrote three paragraphs in here with useful information but Mantis told me my session has expired and when I went back in the browser it even deleted the input form.

Excuse me, this software is the greatest crap I've seen in a long while. Whoever wrote this code has no clue of website application design. Can we have something better real soon?

(0010088)
lynX   
2016-01-23 02:03   
I was saying, the WebRTC scandal cannot be compared because it exposes people using Tor or VPN to any website that comes asking... whereas GNUnet only exposes the fact that you are using GNUnet.

But still the info that is being exposed could be reduced by doing more pro-active broadcasting on the LAN as discussed in https://gnunet.org/bugs/view.php?id=3802 and similarly active announcements over local radio should be sufficient to make GNUnet nodes find each other via ad-hoc wifi.
(0010089)
Christian Grothoff   
2016-01-23 11:11   
You don't want to know how often that has hit me. But: most other systems are also crap, and then there is the question of how to migrate the info that is in Mantis right now...
(0010090)
Christian Grothoff   
2016-01-23 11:12   
As for the broadcasts, the issue is that AFAIK this will only work on the LAN if the ports match and if broadcasts are enabled, and then only for UDP. Neither of these assumptions will be certainly true.
(0010091)
lynX   
2016-01-23 14:38   
Ok, created https://gnunet.org/bugs/view.php?id=4143 to suggest a fix for the mantis problem.

Concerning broadcasts, well there was a time when it was normal that a program was going to broadcast on the LAN.. surprises me, that this has become such a big deal. When installing gnunet we have root permissions. When starting gnunet there are things that are executed as root. I think it should be the default behaviour to open up a UDP listen on a predefined port for LAN broadcasts and that at each change of LAN configuration some gnunet daemon issues a broadcast to see if there is life out there.

And I wonder what keeps us from sending local radio broadcasts in a similar way. From the description I really thought gnunet nodes would autodetect each other as soon as they are in radio vicinity.
(0010104)
dangole   
2016-01-27 09:50   
(Last edited: 2016-01-27 09:51)
lynX: Please understand all implications of the current behaviour. Apart from using the fact that GNUnet is being used, it does *associate* the different addresses of a box with each other (e.g. private and public IPv4, EUI-64 IPv6, temporary IPv6 -- and all that for *all* interfaces -- plus bluetooth MAC, wifi MAC which usually directly correlate with a unique piece of hardware).

Imho this is even worse than the so-called WebRTC scandal because:
* it's easy to disable WebRTC in Firefox whereas GNUnet depends on HELOs to work
* it exposes these highly identifying bits (MACs) combined with ARPA network location globally to everyone and not only to websites visited (usually this information remains local)
* even if people decide to entirely disable IPv6, this would still expose their wifi and bluetooth mac addresses *beyond the (local) scope* these details are useful.

(0011560)
dangole   
2016-12-02 00:23   
partially adressed by https://gnunet.org/git/gnunet.git/commit/?id=6aa3cedfa5e9df7aacbbdcf62c977e09b0e7f6c3
(0013173)
redfish   
2018-08-04 22:12   
FWIW, attached is the patch I'm using to hide private LAN addresses from my HELLO. I've raised this issue a few years ago on IRC, too, we didn't arrive at any action plan. Here's the patch, in case people find this and want to fix their HELLO.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3309 [GNUnet] core service feature N/A 2014-02-07 14:59 2019-11-16 18:41
Reporter: Bart Polot Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: Core needs to indicate a peer's willingness to accept traffic for other peers.
Description: Core should have 3 tiers of peers:
- Backbone peers: computers with good connectivity and no power limitations that are willing to route traffic for other peers.
- Limited peers: computers with either connnectivity limitations (NAT, Dial-up, Slow wireless, etc.) or power limitations (battery operated). Are willing to route traffic for other only if there is no backbone peer available to do so (due to wireless range, for instance).
- Restriced peers: computers/devices that are not willing to route traffic for others under any circumstance (for instance, smartphone using GSM while on roaming in a different country).
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:
5894 [GNUnet] build process minor have not tried 2019-09-13 19:38 2019-11-16 18:40
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: configure time option to optionally replace localhost with whatever is provided in numbers
Description: We should provide a configure time option to make this (taken from nixpkgs):

    # Brute force: since nix-worker chroots don't provide
    # /etc/{resolv.conf,hosts}, replace all references to `localhost'
    # by their IPv4 equivalent.
    find . \( -name \*.c -or -name \*.conf \) | \
      xargs sed -ie 's|\<localhost\>|127.0.0.1|g'

This however is not good, because 127.0.0.1 is not a hostname and some usages require the hostname mapping specifically.

We should get in touch with Nix and work out a proper solution.
Tags:
Steps To Reproduce:
Additional Information: please file bugs and feature requests with us instead of patching around them.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5633 [GNUnet] build process text have not tried 2019-03-07 01:05 2019-11-16 18:40
Reporter: ng0 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: investigate and fix wrong install location of libexec
Description: on macOS, Debian, pkgsrc-wip, and possibly other OS and package manager systems "libexec" ends up in
"lib/gnunet/libexec". This is an anomaly considering that our Makefiles look alright, our configure script
is possibly okay, and considering the fact that other EPREFIX candidates end up in $DESTDIR (for example bin
and lib). Because it ought to be EPREFIX/libexec/gnunet as per our Makefiles, something is wrong here.

The good part is, it is consistent in being wrong across all systems, so whatever is wrong works as intended.
For pkgsrc correctness, I prefer to have libexec really in $EPREFIX together with lib, bin, and other EPREFIX
folders. Guix and Nix where possible prefer this top level of libexec as well.

I've tried a couple of combinations and configure time options and variations in my pkgsrc package, nothing
can convince our buildsystem that libexec shouldn't be in lib/, and I don't want to patch in pkgsrc when I can
fix stuff where it should be fixed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014162)
Christian Grothoff   
2019-03-07 14:45   
Eh, but the correct location is lib/gnunet/libexec/, that's where we need the service binaries. You will also find similar things for other packages:

/usr/lib/llvm-3.8/libexec/c++-analyzer
/usr/lib/llvm-3.8/libexec/ccc-analyzer
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu_stub
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebDatabaseProcess
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebNetworkProcess
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebProcess


AFAIK, this is the canonical location for binaries that are executable but should NOT be in the $PATH.
(0014163)
ng0   
2019-03-07 19:10   
My ${LIBEXEC_DIR} begs to differ with "canonical" (as does nix and guix), the point being that we don't allow to switch the
location even when we set it.

Unless this is intended behavior by the autotools, in which case I would resolve this and file it under knowledge learned through packaging with expectations".
Note that pkgsrc does not mandate a "/libexec" in the destdir, but follows rather what upstream does.. upstream being
us. So it's not a mistake, I'm just trying to figure out why the configure switches are apparently being ignored by the build system
(0014164)
ng0   
2019-03-07 19:16   
Thing being why I ask: it's not so common in the pkgsrc tree to have lib/$name/libexec/, at least in my installed packages.
A search into the pkgsrc tree gives me: libmicro, gcc49, kde4, some special cases (cross compilers), fcitx, but not many more.
packages with lib/libexec/ containing binaries stand out, libexec/name/* is the default location.
(0014165)
schanzen   
2019-03-08 08:55   
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
(0014166)
ng0   
2019-03-08 11:34   
I know what the specs say.
Please read what the mentioned system do about it before just posting a link to something I already know, besides this is not the point.
The configure arguments are discussed here. If we don't hardcode the location of $thing/gnunet/libexec or rather $libexec, the modification of its location should work.
But it doesn't.
So it doesn't matter what the specs say when there's an individual or by chosen preference or norm of the packaging system to ignore parts of the spec.
If I can't conform to the specs I either need to acknowledge that and see if I can fix it here or if I can't fix it here for whatever reasons, I need to write a note about the ignorance of our buildsystem towards the responsible switches.
How we individually think or care about FHS is not relevant.
(0014167)
schanzen   
2019-03-08 12:07   
I think your interpretation of the spec is wron.
The libexec dir and putting non-user-executable binaries under <prefix>/lib/ (in our case gnunet/libexec) are two different things.
Changing the libexec dir is possible by default through autotools I assume. However, it does not have any effect because we do not install anything in the libexec dir.
In fact, we are not even allowed to do it because the spec says if we use <prefix>/lib for our binaries, we must not install anything into the libexec dir.
Just because it is convention to install binaries into <prefix>/lib/<name>/libexec (see gcc, llvm) it does not mean that this location suddenly becomes the libexec dir.
(0014168)
ng0   
2019-03-08 12:45   
Okay, I'll take another look at everything and reply. Can take a while.
(0014171)
schanzen   
2019-03-08 16:06   
Check src/include/gnunet_os_lib.h:165.
A quick grep also shows me that we also do not use LIBEXEC anywhere.
What we do use is GNUNET_OS_IPK_LIBEXECDIR, which is "lib/gnunet/libexec/" according to a comment in the file above

I think this issue's tl;dr is:
1. We do not install anything in LIBEXEC_DIR
2. A change in LIBEXEC_DIR through configure or the environment does not matter because we are not using it
3. We install everything under lib/gnunet/* so this issue might be invalid/wontfix unless we change the build system and install the binaries into LIBEXEC_DIR/gnunet which would also require changes in the source (see above)
(0014172)
ng0   
2019-03-08 17:29   
Okay, was busy elsewhere until a couple of minutes ago.
2 should be documented and 3 is in the scope of what I wanted to clarify here.it's definitely a feature bug,
but more involved.
(0014173)
Christian Grothoff   
2019-03-09 01:35   
Note that it won't be easy/possible to use LIBEXEC_DIR. The user can set LIBEXEC_DIR independently of lib/, and if they do that, we won't be able to find our executeables anymore. We determine the path for lib/gnunet/libexec/ *from* the path of lib/libgnunetutil.so (as that is our own code, we are sure we can ask Linux for its location). So given lib/libgnunetutil.so, we can determine lib/gnunet/libexec/. But if the user has set a LIBEXEC_DIR to foo/, we won't know where foo/ is! Sure, we could then hard-code foo/ into the libgnunetutil.so binary, but then the installation would no longer be relocatable. So the current method is a feature, not a bug.
(0014174)
ng0   
2019-03-09 11:58   
Alright, I think then it's enough to document this with the reasons provided in this ticket
and pointing to this ticket.
(0014175)
ng0   
2019-03-09 11:59   
Keeping this open until someone has added the appropriate documentation changes (README, configure.ac maybe, doc/handbook, doc/tutorial maybe).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5555 [GNUnet] ARM service minor have not tried 2019-02-10 22:09 2019-11-16 18:40
Reporter: ng0 Platform: amd64  
Assigned To: schanzen OS: NetBSD  
Priority: normal OS Version: CURRENT  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: arm: test_gnunet_service_arm fails on netbsd
Description: ================================================
   gnunet 0.11.0pre66: src/arm/test-suite.log
================================================

# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test_gnunet_service_arm
=============================

Feb 10 21:03:38-131511 resolver-29960 WARNING `accept' failed at service.c:843 with error: Resource temporarily unavailable
Feb 10 21:03:38-135891 test-gnunet-service-arm-28419 ERROR Failed to resolve our own hostname!
Feb 10 21:03:38-136020 test-gnunet-service-arm-28419 ERROR Assertion failed at test_gnunet_service_arm.c:118.
Feb 10 21:03:38-136457 resolver-29960 ERROR Assertion failed at gnunet-service-resolver.c:1249. Aborting.
Test failed with error code 3
FAIL test_gnunet_service_arm (exit status: 3)

Tags:
Steps To Reproduce: gmake clean; LDFLAGS=-L/usr/pkg/lib ./configure --prefix=/home/ng0/opt
gmake
su -
cd to source directory, gmake install
exit
PATH=$PATH:/home/ng0/opt/bin GNUNET_PREFIX=/home/ng0/opt gmake check
Additional Information:
Attached Files:
Notes
(0013676)
Christian Grothoff   
2019-02-12 09:23   
Did you run 'make install' first? Should this be RC for 0.11.0?
(0013678)
ng0   
2019-02-12 11:46   
As I wrote above, make install was run before the tests (gmake is gnu make).

I don't think this has to be 0.11.0, it can be 0.11.1 or later. Effectively if nothing major changes I can keep testing gnunet 0.11.0 in pkgsrc-wip. Once the testsuite passes I would ask a developer with commit access to move it to pkgsrc.
(0013681)
ng0   
2019-02-12 12:52   
Let's target 0.12.0 to be on the optimistic side and have enough wiggle and testing room.
(0014775)
schanzen   
2019-08-08 19:22   
Did we not fix this issue? Or at least traced it to a network issue (in IRC)?
(0014786)
ng0   
2019-08-17 11:32   
if we did, it was many months ago. I don't remember the results of what we looked into. We might have to do it again.
(0014787)
schanzen   
2019-08-17 12:04   
Ok. The problem was that if you execute gethostbyname() or gethostbyname2() and then try to resolve that hostname through DNS the results do not match.
This can be an issue with your local DNS router or the local setup of the hostname.

Considering that there is also the error "Feb 10 21:03:38-131511 resolver-29960 WARNING `accept' failed at service.c:843 with error: Resource temporarily unavailable" this might
also be a different issue. OTOH, this error is an EAGAIN and should not be fatal (hence it is just a warning) as the service probably retries.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2731 [gnunet-gtk] gnunet-setup feature always 2013-01-11 10:29 2019-11-16 18:40
Reporter: Matthias Wachs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 0.10.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: "Test configuration" Button does not show error message
Description: gnunet-setup transport configuration test prints error message on console on error, but just shows a red cross in gui ... more information for user required
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:
5507 [GNUnet] integration tests minor always 2019-01-12 01:38 2019-11-16 18:39
Reporter: Heiko Stamer Platform:  
Assigned To: OS: Debian GNU/Linux  
Priority: none OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: test_transport_api_manipulation_cfg fails
Description: FAIL: test_transport_api_manipulation_cfg
=========================================

Jan 12 01:20:12-838625 nat-5674 ERROR UPnP enabled in configuration, but UPnP client `upnpc` command not found, disabling UPnP
Jan 12 01:20:12-852633 nat-5679 ERROR UPnP enabled in configuration, but UPnP client `upnpc` command not found, disabling UPnP
Jan 12 01:20:14-268101 test_transport_api_manipulation_cfg-5654 ERROR Response message was delayed for unexpected duration 99 ms
Jan 12 01:20:14-277885 transport-5676 ERROR Assertion failed at peerinfo_api.c:567.
FAIL test_transport_api_manipulation_cfg (exit status: 1)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013475)
Christian Grothoff   
2019-01-27 11:56   
Note that the entire manipulation is being redesigned in TNG. So probably not worth the effort at this time.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4164 [GNUnet] DHT service feature have not tried 2016-02-03 21:42 2019-11-16 18:38
Reporter: Bart Polot Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: Sign record_route
Description: Sign record_route to avoid fake routes
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011849)
Christian Grothoff   
2017-02-26 01:47   
I'm not yet sure we want this, this will drive up the cost of the route recording dramatically, and to some degree CADET just has to deal with bad routes anyway.
(0011850)
Christian Grothoff   
2017-02-26 01:48   
Also note that we need two signatures for a link A-B: A's and B's. So that's an extra 128 byte per hop (in addition to the 32 right now!). In good news, we can at least only sign each link once, namely when it goes up.
(0013823)
Christian Grothoff   
2019-02-16 15:23   
Marking for 0.12.0 due to protocol change.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5712 [GNUnet] peerstore feature N/A 2019-05-04 23:34 2019-11-16 18:38
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.13.0  
Summary: add logic to preload peerstore with information
Description: PEERINFO is being replaced by PEERSTORE in the new design, but PEERSTORE doesn't yet have the ability to be pre-loaded with HELLOs. PEERINFO had logic to find bootstrap-HELLOs in some folder, but PEERSTORE is designed to be more generic.

What we need is a way to pre-populate PEERSTORE, so (1) logic to import data from some fixed location, and (2) to select (some) information stored in the local PEERSTORE and export it to then include it in the 'make dist' TGZ to be installed at that fixed location when GNUnet is installed.
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:
5893 [GNUnet] build process minor have not tried 2019-09-13 19:35 2019-11-16 18:38
Reporter: ng0 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: replace /tmp in src and elsewhere with something like GNUNET_TMP, again
Description: This comes from reading a bug report never filed with us from a rather creative nixpkg.

For pkgsrc I am in the same position as nixpkgs, /tmp might not always exist (see previous discussions on and the implementation of GNUNET_TMP for config files).
We still hardcode /tmp in some files, and we should use something which is similar to GNUNET_TMP.
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:
5835 [GNUnet] webpage text always 2019-08-18 14:15 2019-11-16 18:38
Reporter: xrs 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: Modify install guide on gnunet.org
Description: - Installtions for single user mode is supposed to be used by developers to test
- Multi user mode installation should be describe in two fashions
  - Use packages and package installer
  - Use install scripts

We need to create an install script (hopefully for many distributions).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014881)
ng0   
2019-09-10 19:15   
can we describe how we ideally want the multi-user setup as well? I'm still struggling with the rc.d script for gnunet, even more so when I follow our best practices wrt multi user mode packaging.
(0014891)
xrs   
2019-09-12 14:58   
Hey ng0, what do you mean exactly? What is your pain point?

With this issue I want to have hints in our installation guides to show people depending on their goal what installation process fits best. Related tasks are therefor packing and install-scripts for non-developers.

Christian Grotthoff gave some of the packagers in the GNUnet team the following requirement list, maybe this helps you.

* multi-user setup (unless not supportable by platform) with:
  - gnunet user/group
  - gnunetdns group
  - SUID helpers
  - /etc/gnunet.conf setup for launching system-wide services
  - integration with init system (systemd, upstart, whatever)
    to launch system-wide GNUnet peer on startup
* per-user configuration:
  - setup ($HOME/.config/gnunet.conf) to
    launch per-user GNUnet services installed in all
    normal user $HOME directories (unless already present!)
    and in /etc/skel/ for new users to be created after
    package installation
  - per-user launch of GNUnet services on graphical login
    (i.e. as systemd user service, or via /etc/X11/Xsession.d/)
    including launch of gnunet-gns-proxy (per user!); ideally
    port should vary by user, i.e. using 8000+UID for TCP port
  - configuration of Firefox, Chrome/Chromium to accept
    CA of gnunet-gns-proxy
  - modification of Firefox/Chrome/Chromium proxy settings
    to enable gnunet-gns-proxy (possibly with interactive question,
    asking which users to modify settings for)
    => for this, writing a NEW shell-script that performs the
       proxy setting should be written first (maybe as
       an extension of the existing script to generate and
       enable the CA?)
(0014896)
ng0   
2019-09-13 02:15   
(Last edited: 2019-09-13 02:18)
what you list in multi-user setup are the basics which I have understood so far, on the surface.

https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/files/gnunet.in;h=d9e6ac52f3e04bf8d703cd9eea01db43124606c5;hb=HEAD
coupled with
https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/files/gnunet.conf;h=3ded6eb4b31470567dc0e493c1a6f6c2ba416894;hb=HEAD
and the corresponding package files is what I have right now, setuids and more here:
https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/Makefile;h=4eff3fdaf7dd698c4d9d15e968306cf0862f3f3c;hb=HEAD#l31

This was mostly gathered from the gentoo init script and https://docs.gnunet.org/handbook/gnunet.html#The-Multi_002dUser-Setup

in this chrooted form as it should be, it does not work (permission issues, etc, filed somewhere in an open bug here).

The pain point is not the lack of examples, but knowing if this works, how some of the steps are supposed to look like, what the outcome should look like etc.
Stepping through a multi-user setup on the init system side with pseudo init script code or literal descriptions would be really helpful.

Our systemd example is not a good example because systemd hides what gentoo or rc.d don't hide that much in expression.

edit: reading through this again, a lack of good examples is what is confusing.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5922 [GNUnet] GNS minor always 2019-10-05 22:37 2019-11-16 18:34
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: urgent OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: Switch label processing to UTF-8
Description: According to LSD001, GNS labels/names must be in UTF-8.
Currently, internationalized GNS labels are interpreted as punycode.
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:
5927 [GNUnet] GNS minor always 2019-10-10 07:03 2019-11-16 18:32
Reporter: dvn Platform:  
Assigned To: schanzen OS:  
Priority: high OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: GNS/nss plugin fails on invalid IDN names
Description: When using a video downloading utility I became aware of some "interesting" domain names...

eg. 'r6---sn-5go7ynez.googlevideo.com'

Haven't looked into it much, but apparently google isn't the only one using domains like this breaking the "double-hyphen" standard.

With the nss plugin enabled:

`r6---sn-5go7yn7s.googlevideo.com' is not a valid domain name"

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014992)
schanzen   
2019-10-10 15:37   
Looking at the code it is not GNS that nags here, but libidn. This simply is not a valid domain name for IDNA-aware applications (or resolvers in this case).
See https://tools.ietf.org/html/rfc5890#section-2.3.1 second paragraph.
(0014993)
schanzen   
2019-10-10 16:19   
Also this seems to be a specific issue with IDN2. It works for IDN1.
(0014994)
schanzen   
2019-10-10 18:29   
For LSD001, this check will likely be removed alltogether.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5968 [GNUnet] util library feature always 2019-11-15 15:19 2019-11-16 18:32
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: urgent OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version: 0.12.0  
    Target Version: 0.12.0  
Summary: exchange should use a documented binary format for RSA public keys
Description: Currently the exchange uses a libgcrypt-specific and undocumented format for RSA public keys. This makes it more difficult than necessary for other software to interoperate with the exchange.

Instead, it should use a structure like this:

uint16_t modulus_length; // length of modulus in bytes
uint16_t public_exponent_length; // length of exponent in bytes
/* variable-size modulus and public exponent follows as big-endian encoded integers */
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015076)
Christian Grothoff   
2019-11-15 19:19   
3d3c271c2..3cb670b17 implements the new serialization format. Activating requires setting the NEW_CRYPTO #define in the code, marked with this bug ID.
(0015078)
Christian Grothoff   
2019-11-16 18:30   
Also implemented new serialization format for RSA signatures now (8a0e314c6..be6c14f2b).
(0015079)
Christian Grothoff   
2019-11-16 18:32   
Moving to GNUnet and scheduling for 0.12.0.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5969 [Taler] wallet (WebExtensions) feature N/A 2019-11-16 12:32 2019-11-16 12:32
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.6  
Summary: some components of taler:// URIs should be treated as case-insensitive
Description: In particular, the URI scheme, authority and first component that has the merchant's domain name.
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:
5788 [Taler] bank (demonstrator) crash have not tried 2019-06-30 23:14 2019-11-16 03:15
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: Malformed JSON on POST makes bank crash.
Description: POSTing malformed JSONs to those endpoints that process authentication credentials
make bank terminate with unhandled exception.

  File "/home/marcello/prog/taler/bank/talerbank/app/views.py", line 621, in _decorator
    user_account = auth_and_login(request)
  File "/home/marcello/prog/taler/bank/talerbank/app/views.py", line 837, in auth_and_login
    data = json.loads(request.body.decode("utf-8"))
  File "/usr/lib/python3.7/json/__init__.py", line 348, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.7/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.7/json/decoder.py", line 353, in raw_decode
    obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 68 (char 67)
Tags:
Steps To Reproduce: POST malformed JSON (e.g.: {"a":1, "b"}) to any API call that takes login credentials.
Additional Information:
Attached Files:
Notes
(0014905)
Christian Grothoff   
2019-09-16 09:50   
I guess given the relationship to 0005787, Marcello should fix this one after all ;-).
(0015077)
Marcello Stanisci   
2019-11-16 03:15   
bcb36f8..fd5b3e7 fixes this


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5740 [Taler] other feature have not tried 2019-05-29 17:28 2019-11-14 22:51
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: exchange should terminate to be restarted after handling $N requests
Description: This achieves two things:
1. it tests whether the exchange process is supervised correctly
2. it makes us resilient against memory leaks and fragmentation
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:
5967 [Taler] auditor feature N/A 2019-11-14 22:49 2019-11-14 22:49
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: auditor report should include range
Description: The report should include information on the data and database row-ranges that the audit covered.
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:
5965 [Taler] auditor text N/A 2019-11-14 22:28 2019-11-14 22:48
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: taler-auditor needs better documentation
Description: While there is now a short chapter on the auditor, key things are missing:
- auditor must probe link API
- auditor should do probabilistic checks on refreshed coins being reported
- need documentation on how the auditor CODE internally works (including auditor DB graphic!)
- need documentation on how the auditor TEST works
+ someone else should read over it to make sure it is clear
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:
5442 [Taler] exchange minor have not tried 2018-09-25 16:19 2019-11-14 22:48
Reporter: Florian Dold Platform:  
Assigned To: Jeff Burdges OS:  
Priority: normal OS Version:  
Status: feedback Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: implement protocol tweaks from thesis/paper
Description: Currently the implementation is a bit de-synced from the actual protocol, some signing steps are missing and some additional checks for /link are necessary.

We should look at the existing code and make sure it matches with what we've written down.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013264)
Christian Grothoff   
2018-10-06 15:07   
Please break down this bug into sub-reports for each issue. This is "too big" to be addressed as one.
(0015075)
Christian Grothoff   
2019-11-14 22:47   
Eh, I believe we addressed the issues we are aware of. Can this be closed???


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5758 [Taler] bank API (C) tweak N/A 2019-06-08 21:41 2019-11-14 22:46
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: test_bank_api_new does not test everything test_bank_api tests
Description: In particular, the history-r{1,2,3} labels are missing, so the /history post reject is not tested by test_bank_api_new.

Once this is implemented, we should drop the "old" test_bank_api.c (and rename test_bank_api_new.c to test_bank_api.c).
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:
5692 [Taler] mechant backend minor have not tried 2019-04-18 17:57 2019-11-14 22:46
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: texinfo documentation, build system: fails due to inability to build arch.pdf
Description: Here are 2 variations of errors, both related to the way texinfo is used.

A fix for all would be to rewrite it in a way which works cross-platform like I attempt for gnunet.
I have no point of reference for the problem in merchant/doc, so it might take longer.

attached are build logs for both problems.

Problem 1: NetBSD make (almost equal to 'bmake') trips on something (probably GNUmake'ism) and doesn't know how to make arch.pdf

Problem 2: is probably a more fine-grained articulation of problem 1, assuming that this is the real cause for Problem 1 to occur in the first place. NetBSD's texi2dvi doesn't support more than one argument for --output. As a brief reminder, we're on Texinfo 4.8, texi2dvi 1.34, here (for whatever reason).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014911)
ng0   
2019-09-17 20:50   
probably fixed in cb8472b5b0750c2e6ff22b8e111c220fa189ba4d back in August.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5899 [Taler] wallet (WebExtensions) minor have not tried 2019-09-18 15:21 2019-11-14 22:46
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: portable configure
Description: The configure script is rather unportable. This does not only consider my situation with a BSD rooted
implementation of find, xarg, getopt, but also Linux systems with no GNU userland tools (those exist
now).

Is there a specific reason why normal failing when base tools used in the Makefile are not enough?
I could rewrite the Makefile in a way that it considers all possible / for us relevant implementations of those
tools (or use more portable invocations).

All know make implementations in my experience support passing a prefix to it.

We could just get away with an empty ./configure (for those who need it, ie mostly automation being stupid), or none at all.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014914)
Florian Dold   
2019-09-18 15:27   
If portability is desired, we should rewrite ./configure in python3. Or rather, as a *very* simply shell (= /bin/sh) script that checks if python3 is installed and then executes some configure.py.

I don't really see any good reason to avoid the dependency on python3.

The reason I wrote the configure script: To be compatible with the GNU coding standards. There should be a configure script, and it should support --prefix.

We might even go the "Google approach" of having all build-related tooling in some git submodule. The ./configure would then make sure the submodule is initialized and run the python script from there.
(0014915)
ng0   
2019-09-18 15:35   
Hm, okay. I don't fully understand the reasoning since it is a should and not a must, but having it in a python3 file sounds better.
Okay if I take on this and test it in Debian and NetBSD for compatibility with userlands? I could then start and export this once
it works into "building.git" or something like that.
(0014916)
ng0   
2019-09-18 15:36   
probably configure (shell script, tests for possible python3 executable name) and then calls the python3 script is the better approach.
(0014917)
Florian Dold   
2019-09-18 15:37   
I agree that having it in Python3 sounds way better, even just because using argparse from the standard library is nicer than the current abomination in the ./configure.

Yes, please just start converting it into Python3 first. Later if we discover there's too much duplication on other repos, we can do some build.git.
(0014918)
Florian Dold   
2019-09-18 15:37   
> probably configure (shell script, tests for possible python3 executable name) and then calls the python3 script is the better approach.

Yes, that's exactly what I was suggesting :-)
(0014919)
ng0   
2019-09-18 15:39   
Okay, thanks for the explanation.

private is probably not necessary for this ticket, okay to make it public (if mantis supports this change)?
(0014920)
Florian Dold   
2019-09-18 15:41   
Sure, can be public!
(0014927)
ng0   
2019-09-20 18:58   
I'm about to push what I have.
This first version took so long because argparse is far from perfect and I needed to run into a couple of walls.
I learned that argparse is implemented in a way that it decides what your error handling should be, and opting out is not nice. In the end I decided to drop the 3rd branch I had and simply make argparse the default if no PREFIX environment variable is exported.
I expect that the prefix directory does exist. otherwise it becomes literally "None", which still has to be worked around.
(0014973)
ng0   
2019-10-02 23:39   
closing this, rest is ongoing work (migration, maintenance etc)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5929 [Taler] deployment and operations feature N/A 2019-10-15 09:03 2019-11-14 22:46
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: high OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: have a reliable way to start BB workers and master
Description: Currently we start them manually. This means, though, that after a restart, these services will be down.

Maybe systemd user units are appropriate for this? We want to avoid needing to be "root" for administering these services.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015015)
ng0   
2019-10-15 13:36   
system user files sounds good enough, I'll explore if this works or apply another solution.
(0015016)
ng0   
2019-10-16 10:26   
(Last edited: 2019-10-16 16:46)
Correction, for the record (and notes for myself): unless my information is too old, systemd user units only exist as long as a session of that user exists (and only start to exist once the user logs in). We want https://www.freedesktop.org/software/systemd/man/loginctl.html for that. user units + loginctl are what could get the job done.



- we also have to check if we need to add XDG_RUNTIME_DIR=/run/user/$UID to the environment before next reboot

(0015017)
Florian Dold   
2019-10-16 14:35   
You can configure systemd so that user units linger!

See here https://wiki.archlinux.org/index.php/systemd/User (search under the keyword linger).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5895 [Taler] deployment and operations minor have not tried 2019-09-14 20:17 2019-11-14 22:46
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: build gnurl from git tags
Description: Context-free conversation quotes for myself:

> See what I pointed out here:
> https://gnunet.org/en/gnurl.html#building
>
> As a safety precaution I would either use the tarball (could even
> be enumerated tried for new version) or pull from a git tag (same).

Note that each user on Gv that builds
Taler has a "envconfig" file in their directory that enumerates the tag
to use for each codebase.

So I would say that using tags is better than pulling the tarball, as this
is more consistent with the overall style.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015040)
ng0   
2019-10-28 12:48   
For now fixed, but the long-term maintenance should be more than search and replace.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5742 [Taler] auditor minor have not tried 2019-05-29 21:12 2019-11-14 22:43
Reporter: Marcello Stanisci 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.7  
Summary: final chart dropped a section
Description: auditor-report.tex.j2 (@ exchange.git) used to reference a section in the JSON report called "reserve_inconsistencies". This however is old API and got removed from the j2 in order to get the auditor BB worker working again. The j2 should be adapted to match the newest API and resort that content in the final chart.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014471)
Marcello Stanisci   
2019-05-31 00:01   
The auditor-report.tex.j2 that got changed was the one copy hosted at deployment.git. The original one under exchange.git is still outdated.
(0014507)
Marcello Stanisci   
2019-06-05 18:33   
Not sure if strictly related to this report, but this Jinja+Tex template keeps being problematic. Even after the
patch described above, it still breaks on some deployments: https://buildbot.taler.net/#/builders/13/builds/3

So it really needs some thorough review!
(0015073)
Christian Grothoff   
2019-11-14 22:24   
Except for coin history inconsistencies, the generator is fully tested. That said, this one is now blocked on the taler wallet integration test exercising refunds.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5274 [Taler] exchange minor have not tried 2018-02-05 17:29 2019-11-14 22:41
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: have (more?) tests for taler-exchange-wirewatch
Description: Clearly there are not enough tests, because the two issues in 0.5 weren't caught.

See 0005271 and 0005272
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:
5814 [Taler] documentation text N/A 2019-07-21 20:21 2019-11-14 22:40
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: database schema PNG is outdated
Description: https://docs.taler.net/exchange/html/taler-exchange.html#Database-Scheme shows a rather _old_ database schema, we should regenerate it with SchemaFuzz to have the current one properly documented.
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:
5409 [Taler] codeless payments minor have not tried 2018-07-21 00:11 2019-11-14 22:40
Reporter: shivamkohli Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: Payto URI
Description: Add paytoURI in the order.
Ask for payto URI while a new merchant is registering on codeless payment platform.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013153)
Christian Grothoff   
2018-07-28 11:46   
We'll need more than a payto://-URI from merchants, as per recent discussions with Marcello. Marcello has been working on a merchant registration page in the Taler backend. So please either coordinate with him, or just leave this one to Marcello entirely.
(0013155)
Marcello Stanisci   
2018-07-28 11:53   
Would also be great to know something more about 'codeless' payments; does a description exist somewhere?
(0013156)
Christian Grothoff   
2018-07-28 11:55   
I don't know if more documentation was written yet, but from GSoC we have this description: "To accept payments with GNU Taler currently some custom (though simple!) code must be written to integrate with an existing web shop or frontend. The goal of this project (codeless payments) is to create a component that sits between the seller's frontend and the GNU Taler merchant backend. This component should have a web interface, where payment buttons or payment forms can be configured that can by copy-pasted into the seller's frontend as static HTML/JS. Bonus goals are inventory management, where the seller can configure the available stock for an item, and will get notified when their stock runs low."
(0013157)
Christian Grothoff   
2018-07-28 11:56   
Anyway, Marcello, did you do any documentation / API specs on the 'merchant registration' logic that you proposed to add to the back office yet? Because I think this is precisely what this bug is about and how it should be addressed ;-)
(0013160)
Marcello Stanisci   
2018-07-28 13:34   
(Last edited: 2018-07-28 13:35)
I did not spec anything for now; as per recent discussion with you, it seems that this data should be collected at _installation_ time, that makes me wonder again if you intend to get the sysadmin enter this information. In this case, there is no need to spec anything for the back-office site.

(0013161)
Christian Grothoff   
2018-07-28 15:34   
Not the sysadmin, but the last step of the backend install could be something like telling the admin that to create/fully configure (?) in instance, they should point the business people to a particular form that they should fill out (per instance).
(0013162)
shivamkohli   
2018-07-28 16:25   
Codeless payment is a platform for the merchant where they can manage their inventory and simultaneously create a 'Buy Now' button for the specific product. This code can be directly copy pasted on the seller's frontend and can be used for 'Pay with Taler'. The documentation for 'codeless' payment is under progress and with be available soon.
For the payto://-URI, I will contact Marcello.
(0014878)
Christian Grothoff   
2019-09-09 15:56   
shivam: do you still plan to work on this?
(0014885)
shivamkohli   
2019-09-11 15:16   
Yes, I can work on this. Please, can you help me get started?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5787 [Taler] bank (demonstrator) minor have not tried 2019-06-30 23:07 2019-11-14 22:38
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Make exception handling less confusing.
Description: Exception handling is ALL put into the middleware module, which makes hard to map exceptions to where those occur in the code. Also, the code errors are computed with a unnecessary/easy-to-break/cryptic arithmetic ([1]). Ultimately, new-comers who aren't aware of this module will naturally put their handlers NOT in that module, resulting in a mixed exception-handling style!

The suggestion is to place obvious exception handlers in the middleware module (malformed JSON / "bad requests" / ..), and spread other less obvious exceptions handlers to where in the code those could be raised.

[1] https://git.taler.net/bank.git/tree/talerbank/app/middleware.py#n149
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014928)
Marcello Stanisci   
2019-09-21 19:22   
4043cac..0025956 defines custom exception objects raised when a bank account or transaction aren't found in DB; this way we can get more information when such queries fail.
(0014956)
Marcello Stanisci   
2019-09-25 11:45   
Also to consider:

right now, the bank has multiple flavours for any type of error. For example,
it defines one error code for error X generated by endpoint Y, and defines *another*
error for (same) error X generated by endpoint Z.

Do we really need this level of precision? The requester should always know from
which endpoint it got the error.
(0014969)
Marcello Stanisci   
2019-09-29 14:24   
Readability improved due to removing unnecessary granularity of error codes (baee420..cba0af7).
(0015072)
Marcello Stanisci   
2019-11-11 17:42   
Not a bug anymore. Same style (*) used in Libeufin.

*: it means all the exceptions get managed in one place of the codebase (middleware.py).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4513 [Taler] deployment and operations feature have not tried 2016-05-20 15:14 2019-11-14 22:35
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8  
Summary: save screenshot and browser logs for failing selenium test
Description: Selenium has screenshotting and browser log access already built in, so when a selenium test case failed, we should query for these.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013545)
ng0   
2019-01-31 20:40   
(Last edited: 2019-01-31 20:48)
How do I fit in here in this context-free assignment?
Can you provide me with a bit more detail (for example which repository)?

(0014035)
Christian Grothoff   
2019-02-25 21:53   
Selenium is controlled via the 'deployment.git' repository. That's most of what I know (and that it is a CI system for testing the Wallet).
(0014106)
Marcello Stanisci   
2019-02-28 18:17   
Not quite. The Selenium script (= the "recipe" that dictates how Selenium should behave) is located within the wallet-webex.git repository, under selenium/ directory. Instead, what you will find inside deployment.git is the logic to *launch* that script; this logic is spread across buildbot/master.cfg and selenium/launch_selenium_test. It is meant to run Selenium tests automatically via the Buildbot. However, during the development phase (of that recipe file) you don't need those launchers, since you can / have to manully launch it along your editing.

p.s.: I just saw this discussion by chance, as I wasn't made aware by Mantis.
(0014209)
ng0   
2019-03-15 15:38   
Okay, thanks.
(0014672)
ng0   
2019-07-14 14:05   
Because this is open for quiet some time, but marked as "feature": I have no idea what got in the way, but I'll pick this up after GSoC, at the end of August if I remember correctly.
Sorry for the long silence.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5862 [Taler] other tweak have not tried 2019-08-30 16:08 2019-11-14 22:35
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 0.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: date format is weird and unnecessary
Description: Parsing and creating it is annoying. There is no real reason for the weird

  stamp_expire: "/Date(123234)/"

shenanigans.

Either we shoud use a number, a string, or some actual JSON wrapper, like

  stamp_expire: { timestamp_sec: 1234 }

which would be easier to parse and generate, and convey the same information with less weirdness.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014868)
Christian Grothoff   
2019-09-06 02:12   
(Last edited: 2019-09-16 09:17)
Hmm. I thought the current "/Date(X)/" had been created based on quite *extensive* discussions between us, with you basically pushing for exactly this format for various JS-related reasons (and other constraints).
Addendum: [1] https://weblogs.asp.net/bleroy/dates-and-json was the original reasoning.

Reasons why we don't just have a number is that it is unclear: is it a time?, also relative time vs. absolute time, and which unit (seconds, nanoseconds, etc.).

Reasons to not use the nested JSON like timestamp_sec include it being even longer, and not really simplifying parsing.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5937 [Taler] bank (demonstrator) block always 2019-10-19 18:59 2019-11-14 22:34
Reporter: Torsten Grothoff Platform: APK (App)  
Assigned To: Florian Dold OS: Android  
Priority: immediate OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: (Android): Taler Test: withdraw not working
Description: The funds get taken out of the account but they never go into the wallet on the phone
Tags:
Steps To Reproduce: == Without QR Code ==
Tap on "Withdraw Testkudos"
Wait forever...
== With QR Code ==
(if you have the wallet, remove wallet from browser)
Withdraw testkudos, scan the QR code.
Confirm withdraw
Wait forever - funds do not change
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5966 [Taler] other minor N/A 2019-11-14 22:30 2019-11-14 22:33
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: code duplication between HTTPDs
Description: We currently have some massive code duplication between the various HTTPDs in the Taler project (merchant, exchange, auditor, sync, anastasis). They all share some parsing and response generation logic, which could likely be unified. The main obstacle seems to be the "-C" flag global variable, but that shouldn't be a deal-breaker either.
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:
5470 [Taler] auditor feature N/A 2018-11-04 17:45 2019-11-14 22:25
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: auditor needs proper testing
Description: Currently, taler-auditor-httpd and taler-auditor and taler-wire-auditor are not tested at all by automated tests.

We need to have some of the usual scripted tests (via interpreter loop) plus should deploy schema fuzz to improve coverage.

The auditor is likely full of holes in terms of properly handling violations in the database (i.e. report+crash or crash instead of just report+continue).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0015074)
Christian Grothoff   
2019-11-14 22:25   
Blocked on taler-wallet-cli exercising refunds and payback.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5964 [Taler] sync feature N/A 2019-11-14 22:23 2019-11-14 22:23
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8  
Summary: sync needs to be implemented
Description: Overall status:
1) API design (done)
2) Database backend (done, needs testing)
3) Sync HTTP service
4) Sync HTTP client
5) Sync integration tests ('make check')
6) Sync CI setup
7) Sync deployment (sync.test.taler.net, sync.int.taler.net, sync.demo.taler.net)
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:
5963 [Taler] other minor have not tried 2019-11-09 19:07 2019-11-09 19:07
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: buildbot should reload its own master on deployment.git change
Description: This can be done by another worker running as buildbot-master.
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:
5962 [libeufin] other minor have not tried 2019-11-08 19:46 2019-11-08 19: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:  
Summary: find out details about 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:
5902 [GNUnet] binary packages block always 2019-09-23 21:09 2019-11-08 15:14
Reporter: xrs Platform: x86_64  
Assigned To: xrs OS: Alpine  
Priority: normal OS Version: 3.10  
Status: assigned Product Version: 0.11.6  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: make fails (using tarball on Alpine-Linux)
Description: Making all in nt
make[3]: Entering directory '/home/xrs/aports/testing/gnunet/src/gnunet-0.11.6/src/nt'
  CC nt.lo
  CCLD libgnunetnt.la
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: .libs/nt.o: undefined reference to symbol 'libintl_dgettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/libintl.so.8: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:533: libgnunetnt.la] Error 1
make[3]: Leaving directory '/home/xrs/aports/testing/gnunet/src/gnunet-0.11.6/src/nt'
make[2]: *** [Makefile:564: all-recursive] Error 1
make[2]: Leaving directory '/home/xrs/aports/testing/gnunet/src/gnunet-0.11.6/src'
make[1]: *** [Makefile:629: all-recursive] Error 1
make[1]: Leaving directory '/home/xrs/aports/testing/gnunet/src/gnunet-0.11.6'
make: *** [Makefile:519: all] Error 2
>>> ERROR: gnunet: build failed
Tags:
Steps To Reproduce: On alpine:
./configure --prefix=/usr
make
Additional Information: In the annex you find a diff taken from configure right before running autoreconf heading to the afore mentioned error and after running autoreconf which leads to a successful build.
Attached Files: configure.alpine.diff (11,012 bytes) 2019-09-23 21:09
https://bugs.gnunet.org/file_download.php?file_id=852&type=bug
config.log.diff (214,047 bytes) 2019-09-26 14:11
https://bugs.gnunet.org/file_download.php?file_id=853&type=bug
config.status.diff (1,592 bytes) 2019-09-26 14:11
https://bugs.gnunet.org/file_download.php?file_id=854&type=bug
Notes
(0014930)
ng0   
2019-09-23 23:24   
Hi,

can you please share the config.log and config.status with the same diff (2 files would be ideal)? The diff you shared shows nothing related to libintl at first reading, most netbsd related removals are exactly like the generated configure my system ends up (on netbsd).
(0014966)
xrs   
2019-09-26 14:11   
Hi ng0,
here your requested files :-)
(0015052)
xrs   
2019-11-07 16:26   
This bug continues to exist for the new tarball for GNUnet 0.11.8.
(0015054)
xrs   
2019-11-08 10:51   
This has been resolved in dfcab34c5af80c0068299bacb16ffc461bf3c1ad.
(0015071)
xrs   
2019-11-08 15:13   
I have to reopen this. My fix only did help partly.

It works on the tarball on an alpine system. But in the alpine build system this bug continues to exist.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5782 [GNUnet] GNS minor always 2019-06-27 00:48 2019-11-08 11:25
Reporter: rockxo Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 0.11.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Activated gns plugin never returns with stopped GNUnet
Description: When nsswitch is configured to use gns prior to dns, but GNUnet is not running at all, it will wait forever and block a DNS request that comes from a application like ping or wget.
Tags:
Steps To Reproduce: Install GNUnet (do not start it)
Follow docs.gnunet.org, section 4.5 “Installation”:
Copy libnss_gns.so* into system-wide lib dir
Modify /etc/nsswitch.conf to activate the plugin

-> Try any non-browser activity that requires DNS resolving (ping, wget, …)
Additional Information:
Attached Files:
Notes
(0014604)
schanzen   
2019-06-27 08:40   
We should probably add a timeout option to gnunet-gns and use that in the nsswitch plugin
(0014605)
schanzen   
2019-06-27 09:09   
Attempted fix in e0698f82e..92a2b1758. Can you test?
(0014606)
rockxo   
2019-06-27 21:23   
Fixes the forever-blocking.
Now it fails after 10 seconds with:
“No address associated with hostname”

However, when docs recommends
<quote>
Add the text "gns [NOTFOUND=return]" after "files".
</quote>
it still fails, due to the NOTFOUND=return.

Did you consider checking for the presence of a GNUnet instance at this point?
(0014607)
schanzen   
2019-06-27 21:39   
I see. The problem is that we cannot distinguish between GNUnet not running and GNS not providing a reply in the lookup.
Both results in a timeout.
In the GNS API we actually first check if the TLD used in the domain _can_ be found in GNS, but the last step in this check requires the identity service -> hangs if GNUnet not running. (identity_api_suffix_lookup.c)

When GNS times out and it is/was a GNS name, we want to return "NOTFOUND" to nss.
However, if GNUnet is not running, we actually want to return "UNAVAIL" so that NSS continues with DNS.
Not sure how we can fix that without a hack (e.g. first checking if we can iterate over Egos).
(0014608)
schanzen   
2019-06-27 21:40   
As far as I remember, GNS had a timeout in the API a long time ago. If we could distinguish between that timeout and a timeout in the gnunet-gns CLI we could address this.
But that would require a significant change in GNS and its API.
(0014609)
schanzen   
2019-06-27 21:47   
(Last edited: 2019-06-27 22:02)
@grothoff: Maybe we can add an identity function that _only_ checks if the TLD is available as ego without querying the service?
The egos are key files anyway, right?
Of course, this would fail if the service is running somewhere wehere we do not have access to those files. Which is theoretically possible.
Then, we would be left only with the option above.

(0014616)
Christian Grothoff   
2019-06-29 10:46   
Well, the issue with "just access the files directly" is that rexxnor pointed out that deleting an ego today doesn't delete the associated zone (which is a UX issue).
Moreover, we're currently *duplicating* the private keys in the Namestore database.

So really, we should eventually fuse (!) namestore and identity and have both use the *same* database (and drop the zone if the respective ego is deleted, i.e. via CASCADE on DELETE).
Plus the API needs to be changed to properly support transactions, so quite a bit of work on that front in the future, which makes the "just bypass identity" hack not really working.

The real issue is that we have a confidentiality/availability trade-off here: if we just fall back to DNS whenever GNUnet is not running, we might expose sensitive GNS names to DNS; but if we block DNS because GNUnet is not running, we're creating a serious availability issue. One thing we could _consider_ is to detect that GNUnet is not running and auto-launch GNUnet. What do you think of this option?
(0014617)
schanzen   
2019-06-29 15:11   
"The real issue is that we have a confidentiality/availability trade-off here: if we just fall back to DNS whenever GNUnet is not running, we might expose sensitive GNS names to DNS; but if we block DNS because GNUnet is not running, we're creating a serious availability issue. "

That is the issue I was trying to explain. This is why we need functionality to determine if GNS should be queried for a name. This check must work
_without_ the need of a running gnunet instance.
Then, the nss plugin can return the correct code which will hand the request over to DNS (or other subsystems) or stop the resolution correctly.

This worked before because we knew ".gnu" was GNS's only namespace. Now it is more complicated, but we still need to address it.
This issue shows us that we cannot just break nsswitch like that. We must be able to correctly do the following when receiving a request through NSS:

1. Check if GNS is authoritative for this name
-> If not, return -2 => continue in nss with next plugin
-> If yes, continue
2. Check if GNUnet is running
-> If not, return -3 (NOTFOUND) (Here you could implement an autostart)
-> If yes, continue
3. Query GNS
-> If timeout, return -3
-> If found, return result
(0014618)
schanzen   
2019-06-29 15:13   
"1." In the above comment is currently broken or requires "2." which we should avoid.
(0014619)
Christian Grothoff   
2019-06-30 16:39   
Well, checking if GNS is authoritative means talking to identity (or in the future possibly namestore). I don't like the idea of just breaking the existing encapsulation of the state apart and implementing a "mini" version of idenity/namestore in gnunet-gns. Which is why I propose to just launch GNUnet in this case. Note that this would be the per-user instance, not the per-host peer instance (if the system is configured for the split-mode). Which means we _only_ learn if GNS is applicable, but wouldn't actually launch network activities.
(0014872)
dvn   
2019-09-06 21:08   
> Which is why I propose to just launch GNUnet in this case. Note that this would be the per-user instance, not the per-host peer instance (if the system is configured for the split-mode). Which means we _only_ learn if GNS is applicable, but wouldn't actually launch network activities.

This idea seems fair. What about explicitly only launching the services needed for GNS and Identity?
(0014873)
schanzen   
2019-09-06 23:19   
Three problems I have with that:

1. gnunet-arm -i gns will also hang if gnunet is not (yet) running which means we need to somehow detect if it is already running and then otherwise start gnunet (first).
2. We do not know if that how gnunet should be/can be run on that system if it is not running (per user / system service etc).
3. What do we do if the connection between gnunet-gns and the service is not working as expected? It will hang as well. So we might need a timeout in either case where we do not know if that is because gns is still resolving or it is just broken.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5582 [GNUnet] namestore service minor have not tried 2019-02-16 23:56 2019-11-08 11:25
Reporter: schanzen Platform:  
Assigned To: schanzen OS: macOS  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.11.0  
Summary: namestore tests fail on macOS
Description: The namestore tests, in particular those related to the sqlite plugin, fail with a segfault.
The segfault occurs _after_ the main of the test returns, which indicates a stack corruption.
Unfortunately, for macOS 10.14 there is no valgrind yet and I had to luck with gdb until now.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013842)
schanzen   
2019-02-17 15:03   
My lldb output:

(lldb) run
Process 60864 launched: '.libs/test_plugin_namestore_sqlite' (x86_64)
Process 60864 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10042e637)
    frame #0: 0x000000010042e637
error: memory read failed for 0x10042e600
Target 0: (test_plugin_namestore_sqlite) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10042e637)
  * frame #0: 0x000000010042e637
    frame #1: 0x0000000100086938 dyld`initialPool + 40
    frame #2: 0x0000000100086938 dyld`initialPool + 40
    frame #3: 0x000000010001cff3 dyld`ImageLoaderMachO::doTermination(ImageLoader::LinkContext const&) + 251
    frame #4: 0x0000000100006824 dyld`dyld::runAllStaticTerminators(void*) + 68
    frame #5: 0x00007fff61395ef2 libsystem_c.dylib`__cxa_finalize_ranges + 351
    frame #6: 0x00007fff613961de libsystem_c.dylib`exit + 55
    frame #7: 0x00007fff612ecee0 libdyld.dylib`start + 8
(0013843)
schanzen   
2019-02-17 16:28   
Commenting line 191 (get_record). Makes the test pass without corruption.
The tests is kind of strange anyway... maybe it needs to be rewritten...
(0013845)
schanzen   
2019-02-17 16:37   
To be honest I find this test rather odd to begin with. I mean, what are we testing here exactly? The service loads and uses the plugin differently and we shouldn't really duplicate that code in the test and instead... test it.
And this is what we do in the rest of the tests. So I think before fixing this mess we should replace it with something simpler or drop it.
(0013959)
schanzen   
2019-02-23 13:08   
Added this as target for 0.11.1 for now.
(0015001)
schanzen   
2019-10-11 18:37   
This is still a valid issue
(0015002)
schanzen   
2019-10-11 18:40   
For now ifdef'd test for macos to make it work.
(0015003)
Christian Grothoff   
2019-10-11 20:50   
I don't understand what you think is wrong about the test. It has to load the plugin before using it (especially given that its written independent of the specific plugin under test), and then unloads it (which tests plugin unloading). Looks logical to me.
(0015004)
schanzen   
2019-10-11 21:36   
There is nothing wrong with the test. But for some reason the unload segfaults on macOS. This is an issue we already talked about. I cannot track it down. The bug is not in our code (presumably).
The plugin also "works" w/o segfault in the actual service.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5921 [GNUnet] GNS tweak have not tried 2019-10-05 22:31 2019-11-08 11:24
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: Simplify/harmonize GNS key derivations
Description: The GNS key derivations are kind of all over the place, e.g. for the derivation of the symmetric encryption key we
calculate:
       PRK_kiv := HKDF-Extract (zk, label)
       K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
       IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)

This means that we use the zone key (zk) as salt and label as initial keying material.
Usually, we use a string as salt and key as IKM, for example when we derive the zone key for signing:
PRK_h := HKDF-Extract ("key-derivation", zk)
         h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)

In order to harmonize this, LSD001 specifies:
         PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
         PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
         K := HKDF-Expand (PRK_k, label, 512 / 8);
         IV := HKDF-Expand (PRK_iv, label, 256 / 8)

This is already implemented but guarded by the define "LSD001" in src/gnsrecord/gnsrecord_crypto.c.
Define for 0.12.
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:
5961 [GNUnet] documentation block always 2019-11-08 11:11 2019-11-08 11:11
Reporter: xrs Platform: x86_64  
Assigned To: ng0 OS: Alpine  
Priority: normal OS Version: latest  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: gnunet-tutorial.texi:1565: @include: could not find fdl-1.3.texi
Description: > cd src/doc/tutorial
> make
MAKEINFO gnunet-tutorial.info
gnunet-tutorial.texi:1565: @include: could not find fdl-1.3.texi
make: *** [Makefile:574: gnunet-tutorial.info] Error 1
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:
5851 [Taler] merchant backend API (C) feature have not tried 2019-08-23 19:37 2019-11-07 22:04
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: /check-payment should support long polling and a 2nd, public endpoint
Description: Ideally we'd be able to specify a timeout=... query parameter.

The second public endpoint is necessary for JS in the browser to check if a mobile payment has happened.

Unlike the private /check-payment, the public version must be provided with both the order ID as well as the contract hash, and the backend must validate the contract hash. This prevents enumeration of orders and their status when order IDs have low entropy.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014903)
Christian Grothoff   
2019-09-16 09:42   
Florian, I'm not sure this bug note (still) properly describes the endpoint(s) we had discussed in the API spec. Could you please update the description (or link to spec) to make sure we are agreed on what should be done here?
(0015048)
Christian Grothoff   
2019-11-02 13:44   
44b5eaf..0d42e6b specifies a new /public/poll-payment endpoint.
ae06bf1..ea48d9f implements this endpoint.
C API and test cases are still missing.
(0015049)
Christian Grothoff   
2019-11-02 14:34   
ea48d9f..3a22e60 implements the C API.
(0015051)
Christian Grothoff   
2019-11-03 00:01   
Test command API added in e3db526..ce7ed80. Actual integration into a TEST is still missing.
(0015053)
Christian Grothoff   
2019-11-07 22:04   
add8722..edfc078 fixes a few bugs and adds a now passing test for /public/poll-payment to the merchant. Bug resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5960 [libeufin] sandbox minor have not tried 2019-11-06 11:12 2019-11-06 11:12
Reporter: Marcello Stanisci 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:  
Summary: All exceptions lead to "500 Internal server error"
Description: Even if the client POSTs invalid data, they get a "500 Internal server error" response.

This happens since now there is only one default exceptions handler that catches *all*
exceptions and respond with 500. Eventually, any exception should be managed according
to the context it originates from.
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:
5823 [GNUnet] cadet service feature N/A 2019-08-01 22:02 2019-11-04 23:05
Reporter: t3sserakt Platform:  
Assigned To: t3sserakt OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CADET message drop API for testing
Description:  The CADET monitoring API should be able to tell CADET to drop the next message of some type send from node A to node B.
Tags:
Steps To Reproduce:
Additional Information: This shall help to write test cases for bug 0005822.
Attached Files:
Notes
(0014779)
t3sserakt   
2019-08-08 21:44   
(Last edited: 2019-08-13 08:02)
How can I prevent misuse in a GNUnet multi user scenario. Can I check for the user who is using the cadet api?

(0014886)
schanzen   
2019-09-11 16:17   
The service API is protected because the UNIX socket is only accessible to the user that started the service. So you do not need to worry about that.
If the service is listening on a TCP socket, you can't have it. Any user is a valid user because he has access to the system.

But that does not address the original issue right? I am unsure what exactly you are proposing and what you need it for.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5818 [GNUnet] cadet service minor have not tried 2019-07-23 14:40 2019-11-04 23:05
Reporter: schanzen 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:  
Summary: test_cadet_2_keepalive always fails
Description: Looking at the test, it seems to run fine. But the success condition is odd:
/* Test is supposed to generate the following callbacks:
  * 1 incoming channel (@dest)
   * [wait]
    * 1 received channel destroy (@dest)
    */

This does not make sense as the test simply times out without incrementing the "ok" counter on channel destroy. Hence ok == 1 and never 2.
This should reliably fail though?
Tags:
Steps To Reproduce: Jul 23 14:32:40-606276 test-92298 DEBUG DIRECT CONNECTIONs
Jul 23 14:32:40-609447 test_cadet_small-92298 DEBUG Starting HELPER process `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-testbed'
Jul 23 14:32:40-611112 test_cadet_small-92298 DEBUG Transmitted 4425 bytes to /Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-testbed
Jul 23 14:32:40-633349 test_cadet_small-92298 DEBUG Got 4522 bytes from helper `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-testbed'
Jul 23 14:32:40-872335 transport-92336 ERROR Assertion failed at nt.c:332.
Jul 23 14:32:40-873045 transport-udp-92336 WARNING Failed to join IPv6 multicast group: IPv6 broadcasting not running
Jul 23 14:32:40-873063 transport-92336 ERROR Assertion failed at nt.c:332.
Jul 23 14:32:40-873071 transport-udp-92336 WARNING Failed to join IPv6 multicast group: IPv6 broadcasting not running
Jul 23 14:32:40-879325 transport-92337 ERROR Assertion failed at nt.c:332.
Jul 23 14:32:40-879964 transport-udp-92337 WARNING Failed to join IPv6 multicast group: IPv6 broadcasting not running
Jul 23 14:32:40-880099 transport-92337 ERROR Assertion failed at nt.c:332.
Jul 23 14:32:40-880208 transport-udp-92337 WARNING Failed to join IPv6 multicast group: IPv6 broadcasting not running
Jul 23 14:32:40-885894 gnunet-rest-server-92326 ERROR `bind' failed at gnunet-rest-server.c:942 with error: Address already in use
Jul 23 14:32:40-890447 gnunet-rest-server-92327 ERROR `bind' failed at gnunet-rest-server.c:942 with error: Address already in use
Jul 23 14:32:40-901361 gnunet-rest-server-92327 ERROR `bind' failed at gnunet-rest-server.c:963 with error: Address already in use
Jul 23 14:32:40-901767 util-os-installation-92338 WARNING `access' failed on file `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-nat-server' at os_installation.c:938 with error: No such file or directory
Jul 23 14:32:40-902567 util-os-installation-92338 WARNING `access' failed on file `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-nat-server' at os_installation.c:938 with error: No such file or directory
Jul 23 14:32:40-907283 util-os-installation-92339 WARNING `access' failed on file `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-nat-server' at os_installation.c:938 with error: No such file or directory
Jul 23 14:32:40-907743 util-os-installation-92339 WARNING `access' failed on file `/Users/schanzen/gnunet/build/lib//gnunet/libexec/gnunet-helper-nat-server' at os_installation.c:938 with error: No such file or directory
Jul 23 14:32:40-927484 util-network-92337 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-927572 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::1]:12035': `No route to host'
Jul 23 14:32:40-942732 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::1c33:88ed:2960:3e2d]:12043': `No route to host'
Jul 23 14:32:40-942762 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::aede:48ff:fe00:1122]:12043': `No route to host'
Jul 23 14:32:40-942774 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::ed58:df6b:2fb6:8179]:12043': `No route to host'
Jul 23 14:32:40-942785 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::74b5:23ff:fe6e:793d]:12043': `No route to host'
Jul 23 14:32:40-942795 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::8d0:6427:a15d:80aa]:12043': `No route to host'
Jul 23 14:32:40-942806 transport-udp-92336 WARNING UDP could not transmit message to `[fe80::1]:12043': `No route to host'
Jul 23 14:32:40-942901 util-network-92336 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-969043 util-network-92336 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-970264 util-network-92337 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-970336 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::1c33:88ed:2960:3e2d]:12035': `No route to host'
Jul 23 14:32:40-970358 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::aede:48ff:fe00:1122]:12035': `No route to host'
Jul 23 14:32:40-970370 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::ed58:df6b:2fb6:8179]:12035': `No route to host'
Jul 23 14:32:40-970381 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::74b5:23ff:fe6e:793d]:12035': `No route to host'
Jul 23 14:32:40-970393 transport-udp-92337 WARNING UDP could not transmit message to `[fe80::8d0:6427:a15d:80aa]:12035': `No route to host'
Jul 23 14:32:40-975875 util-network-92336 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-991040 util-network-92336 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:40-998913 util-network-92337 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:41-008635 util-network-92337 WARNING `setsockopt' failed at network.c:355 with error: Invalid argument
Jul 23 14:32:41-031864 test_cadet_small-92298 DEBUG Testbed up, 2 peers and 1 links
Jul 23 14:32:41-031909 test_cadet_small-92298 INFO Connecting to cadet 0
Jul 23 14:32:41-031924 test_cadet_small-92298 INFO op handle 0x7fe6bdd00430
Jul 23 14:32:41-031928 test_cadet_small-92298 INFO Connecting to cadet 1
Jul 23 14:32:41-031934 test_cadet_small-92298 INFO op handle 0x7fe6bdd00620
Jul 23 14:32:41-038231 test_cadet_small-92298 DEBUG Listening to CADET port 38KQGBKV
Jul 23 14:32:41-038255 test_cadet_small-92298 INFO ...cadet 0 connected
Jul 23 14:32:41-038912 test_cadet_small-92298 DEBUG Listening to CADET port 38KQGBKV
Jul 23 14:32:41-038922 test_cadet_small-92298 INFO ...cadet 1 connected
Jul 23 14:32:41-038928 test_cadet_small-92298 DEBUG test main
Jul 23 14:32:41-038959 test_cadet_small-92298 DEBUG requested peer ids
Jul 23 14:32:41-039595 test_cadet_small-92298 DEBUG ID callback for 0
Jul 23 14:32:41-039613 test_cadet_small-92298 DEBUG id: 6DEV
Jul 23 14:32:41-040131 test_cadet_small-92298 DEBUG ID callback for 1
Jul 23 14:32:41-040154 test_cadet_small-92298 DEBUG id: 6YNB
Jul 23 14:32:41-040159 test_cadet_small-92298 DEBUG Got all IDs, starting test
Jul 23 14:32:41-040188 test_cadet_small-92298 DEBUG start_test: (null)
Jul 23 14:32:41-040196 test_cadet_small-92298 DEBUG Creating channel to peer 6YNB at port 38KQGBKV
Jul 23 14:32:42-090712 test_cadet_small-92298 INFO Incoming channel from 6DEV to 1: 0x7fe6bdc1f450
Jul 23 14:32:42-090777 test_cadet_small-92298 INFO ok: 1
Jul 23 14:33:02-096195 test_cadet_small-92298 INFO gathering statistics from line 952
Jul 23 14:33:02-096255 test_cadet_small-92298 INFO Destroying channel due to GNUNET_CADET_channel_destroy()
Jul 23 14:33:02-103272 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# keepalives received]: 19
Jul 23 14:33:02-103337 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# decrypted bytes]: 152
Jul 23 14:33:02-103374 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# keepalives received]: 19
Jul 23 14:33:02-103389 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# encrypted bytes]: 152
Jul 23 14:33:02-103414 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# decrypted bytes]: 152
Jul 23 14:33:02-103426 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# keepalives sent]: 19
Jul 23 14:33:02-103451 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# encrypted bytes]: 152
Jul 23 14:33:02-103480 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# keepalives sent]: 19
Jul 23 14:33:02-103509 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# DHT announce]: 5
Jul 23 14:33:02-103777 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# DHT announce]: 5
Jul 23 14:33:02-103858 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# channels]: 2
Jul 23 14:33:02-103885 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# KX_AUTH received]: 1
Jul 23 14:33:02-103897 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# KX_AUTH transmitted]: 1
Jul 23 14:33:02-103916 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# KX transmitted]: 1
Jul 23 14:33:02-103926 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# Fresh KX setup]: 1
Jul 23 14:33:02-103942 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# channels]: 1
Jul 23 14:33:02-103952 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# KX received]: 1
Jul 23 14:33:02-103970 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# DHT search]: 1
Jul 23 14:33:02-103981 test_cadet_small-92298 INFO STATS PEER 1 - cadet [# clients]: 1
Jul 23 14:33:02-104334 test_cadet_small-92298 DEBUG Cleaning all up
Jul 23 14:33:02-104644 test_cadet_small-92298 INFO STATS PEER 0 - cadet [# clients]: 1
Jul 23 14:33:02-104677 test_cadet_small-92298 INFO KA sent: 19, KA received: 19
Jul 23 14:33:02-105062 test_cadet_small-92298 DEBUG Cleaning all up
Jul 23 14:33:02-105275 test_cadet_small-92298 INFO disconnecting cadet service of peers, called from line 952
Jul 23 14:33:02-105293 test_cadet_small-92298 INFO Destroying channel due to GNUNET_CADET_channel_destroy()
Jul 23 14:33:02-106016 test_cadet_small-92298 DEBUG Ending test.
Jul 23 14:33:02-133134 test_cadet_small-92298 ERROR FAILED! (1/2)
Additional Information:
Attached Files: test_cadet_2_keepalive.log (86,836 bytes) 2019-08-04 18:40
https://bugs.gnunet.org/file_download.php?file_id=845&type=bug
Notes
(0014727)
ch3   
2019-07-23 15:41   
For me it looks like this:
Jul 23 15:31:40-907517 gnunet-rest-server-13886 ERROR `bind' failed at gnunet-rest-server.c:942 with error: Address already in use
Jul 23 15:31:40-907620 gnunet-rest-server-13886 ERROR `bind' failed at gnunet-rest-server.c:963 with error: Address already in use
Jul 23 15:31:40-934118 gnunet-rest-server-13882 ERROR `bind' failed at gnunet-rest-server.c:942 with error: Address already in use
Jul 23 15:31:40-946850 gnunet-rest-server-13882 ERROR `bind' failed at gnunet-rest-server.c:963 with error: Address already in use
Jul 23 15:32:02-479956 transport-api-core-13888 ERROR Error receiving from transport service (1), disconnecting temporarily.

Returning with a successful return value.

(I hat a gnunet peer running in parallel.)
(0014728)
ch3   
2019-07-23 15:46   
Without running gnunet peer and debug messages enabled:

$ GNUNET_FORCE_LOG="test_cadet_small;;;;DEBUG" ./test_cadet_2_keepalive
Jul 23 15:42:10-346039 test-16447 DEBUG DIRECT CONNECTIONs
Jul 23 15:42:10-350543 test_cadet_small-16447 DEBUG Starting HELPER process `/home/gnunet/prefix_gn/lib//gnunet/libexec/gnunet-helper-testbed'
Jul 23 15:42:10-353270 test_cadet_small-16447 DEBUG Transmitted 5204 bytes to /home/gnunet/prefix_gn/lib//gnunet/libexec/gnunet-helper-testbed
Jul 23 15:42:10-371664 test_cadet_small-16447 DEBUG Got 5281 bytes from helper `/home/gnunet/prefix_gn/lib//gnunet/libexec/gnunet-helper-testbed'
Jul 23 15:42:10-493588 gnunet-rest-server-16482 ERROR `bind' failed at gnunet-rest-server.c:942 with error: Address already in use
Jul 23 15:42:10-493687 gnunet-rest-server-16482 ERROR `bind' failed at gnunet-rest-server.c:963 with error: Address already in use
Jul 23 15:42:10-521677 util-plugin-16475 ERROR `lt_dlopenext' failed for library `libgnunet_plugin_rest_identity_provider' with error: file not found
Jul 23 15:42:10-650032 test_cadet_small-16447 DEBUG Testbed up, 2 peers and 1 links
Jul 23 15:42:10-650094 test_cadet_small-16447 INFO Connecting to cadet 0
Jul 23 15:42:10-650131 test_cadet_small-16447 INFO op handle 0x55ecbc627f70
Jul 23 15:42:10-650151 test_cadet_small-16447 INFO Connecting to cadet 1
Jul 23 15:42:10-650173 test_cadet_small-16447 INFO op handle 0x55ecbc628390
Jul 23 15:42:10-657460 test_cadet_small-16447 DEBUG Listening to CADET port 38KQGBKV
Jul 23 15:42:10-657505 test_cadet_small-16447 INFO ...cadet 0 connected
Jul 23 15:42:10-659092 test_cadet_small-16447 DEBUG Listening to CADET port 38KQGBKV
Jul 23 15:42:10-659127 test_cadet_small-16447 INFO ...cadet 1 connected
Jul 23 15:42:10-659152 test_cadet_small-16447 DEBUG test main
Jul 23 15:42:10-659189 test_cadet_small-16447 DEBUG requested peer ids
Jul 23 15:42:10-661700 test_cadet_small-16447 DEBUG ID callback for 0
Jul 23 15:42:10-661739 test_cadet_small-16447 DEBUG id: 6DEV
Jul 23 15:42:10-661782 test_cadet_small-16447 DEBUG ID callback for 1
Jul 23 15:42:10-661803 test_cadet_small-16447 DEBUG id: 6YNB
Jul 23 15:42:10-661824 test_cadet_small-16447 DEBUG Got all IDs, starting test
Jul 23 15:42:10-661859 test_cadet_small-16447 DEBUG start_test: (null)
Jul 23 15:42:10-661887 test_cadet_small-16447 DEBUG Creating channel to peer 6YNB at port 38KQGBKV
Jul 23 15:42:11-736693 test_cadet_small-16447 INFO Incoming channel from 6DEV to 1: 0x55ecbc644900
Jul 23 15:42:11-736751 test_cadet_small-16447 INFO ok: 1
Jul 23 15:42:31-757008 test_cadet_small-16447 INFO gathering statistics from line 952
Jul 23 15:42:31-757164 test_cadet_small-16447 INFO Destroying channel due to GNUNET_CADET_channel_destroy()
Jul 23 15:42:31-772470 test_cadet_small-16447 INFO Channel disconnected at 1
Jul 23 15:42:31-772697 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# encrypted bytes]: 164
Jul 23 15:42:31-772873 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# decrypted bytes]: 164
Jul 23 15:42:31-772991 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# keepalives received]: 19
Jul 23 15:42:31-773126 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# decrypted bytes]: 152
Jul 23 15:42:31-773181 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# keepalives received]: 19
Jul 23 15:42:31-773220 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# keepalives sent]: 19
Jul 23 15:42:31-773270 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# encrypted bytes]: 152
Jul 23 15:42:31-773307 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# DHT announce]: 5
Jul 23 15:42:31-773356 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# keepalives sent]: 19
Jul 23 15:42:31-773394 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# KX_AUTH received]: 1
Jul 23 15:42:31-773442 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# DHT announce]: 5
Jul 23 15:42:31-773480 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# KX transmitted]: 1
Jul 23 15:42:31-773529 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# channels]: 2
Jul 23 15:42:31-773565 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# channels]: 1
Jul 23 15:42:31-773614 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# KX_AUTH transmitted]: 1
Jul 23 15:42:31-773650 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# DHT search]: 1
Jul 23 15:42:31-773698 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# Fresh KX setup]: 1
Jul 23 15:42:31-773735 test_cadet_small-16447 INFO STATS PEER 0 - cadet [# clients]: 1
Jul 23 15:42:31-774011 test_cadet_small-16447 DEBUG Cleaning all up
Jul 23 15:42:31-774076 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# KX received]: 1
Jul 23 15:42:31-774377 test_cadet_small-16447 INFO STATS PEER 1 - cadet [# clients]: 1
Jul 23 15:42:31-774439 test_cadet_small-16447 INFO KA sent: 19, KA received: 19
Jul 23 15:42:31-774700 test_cadet_small-16447 DEBUG Cleaning all up
Jul 23 15:42:31-774771 test_cadet_small-16447 INFO disconnecting cadet service of peers, called from line 952
Jul 23 15:42:31-775695 test_cadet_small-16447 DEBUG Ending test.
Jul 23 15:42:31-797608 test_cadet_small-16447 DEBUG success
(0014730)
schanzen   
2019-07-23 16:44   
(Last edited: 2019-07-23 17:15)
test_cadet.c seems to think the CADET_channel_destroy() API still calls the disconnect callback. But it doesn't as of 7caba06019.
The whole test is thus build on a flawed assumption and probably must be rewritten.

(0014731)
schanzen   
2019-07-23 16:59   
This happens on both Debian 9 and macOS for me.
(0014732)
schanzen   
2019-07-23 17:23   
I shaved off the requirement of the disconnect ACKs in 91fa8e7cab1fdfcb4c52f79f459b899c7d9302f0 for now.
Still, this test needs be rewritten at some point...
(0014771)
xrs   
2019-08-04 18:40   
test_cadet_2_keepalive only fails sometimes for me.

@schanzen: The success condition for this test is that keepalives have been seen by the receiving peer. This is done by asking gnunet-statistics. Thus, the two endpoints just have to establish a connection and do nothing and let cadet do the tunnel maintanance by processing keepalives.

Should we close this ticket?
(0014772)
schanzen   
2019-08-04 18:41   
No, because this test needs to be rewritten to reflect the API change (see above). It currently has broken logic.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5946 [GNUnet] build process minor have not tried 2019-10-24 15:16 2019-11-04 23:05
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 0.11.7  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.11.7  
    Target Version:  
Summary: fix texi2mdoc generation
Description: if set, in 0.11.6 make fails to find one of the .7 files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015037)
ng0   
2019-10-27 15:49   
Probably fixed (confirmed by 2 people) by adjusting the Makefile in doc/man.
(0015038)
ng0   
2019-10-27 19:39   
still an issue


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5822 [GNUnet] cadet service major always 2019-08-01 21:43 2019-11-04 23:05
Reporter: t3sserakt Platform:  
Assigned To: t3sserakt OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.11.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No tunnel destroy after channel destroy was not received
Description: We have two nodes A and B. Node B opened a CADET port, and node A created a channel to that port. The channel was working fine. Now node A left the channel and has no tunnel anymore towards node B. Node B still has a tunnel and a channel to node A. This can happen for several reasons. Node A had send a channel destroy node B never got. Node A was not able to send a channel destroy, because node A was shutdown in an uncontrolled manner (hard reboot of the system). When node A is trying to open up the channel to node B again this will not work, because for some pair of nodes the method alice_or_betty in gnunet-service-cadet_tunnels.c might stop node A from starting the key exchange. Node B has no reason to start the key exchange, because node B still has a tunnel to node A.
Tags:
Steps To Reproduce: For two nodes A and B check when the method alice_or_betty returns GNUNET_NO. If PeerIdentity of node B given to alice_or_betty returns GNUNET_NO, node B has to open the cadet port. Node A has to open a channel to node B. After the channel is working do a hard reset of the system node A is running on. After node A is running again try to create a channel to node B.
Additional Information: My first thought to solve this problem was to introduce some message node A sends to node B asking to destroy an existing tunnel, and to start key exchange. Then I saw that cadet connections are sending keepalive messages, but at the receiving node this keepalive message is not processed. There could be some recurring task checking for keepalives and if there are none after some timeout we destroy the tunnel and every channel for that tunnel.
Attached Files:
Notes
(0014766)
Christian Grothoff   
2019-08-01 22:23   
Timeouts are OK for tunnels (low-ish timeout, maybe depending on path length!) and maybe for a channel's KX, but should not be applied to sessions; thus a timeout on the communication link may tear down a tunnel, if all tunnels go down for a while we may decide a channel's KX is invalid, but as long as there are any sessions, the channel itself must not be destroyed (as sessions must not fail, and if a session exists, a channel must _exist_ -- that's in invariant we have). That said, we could/should (probably) decide to 'reset' the KX to the uninitialized/just starting up state after some timeout and force the setup to begin from "fresh".

With regards to KEEPALIVE, maybe a good option would be to include the current CADET channel state in the keepalive, and if one peer thinks the channel was destroyed and the other thinks it is still up, well, with KEEPALIVE we can detect it, and then figure out how to resolve the situation. Here, I'd think that if either side has active sessions, the correct process is to reinitialize the channel, and if neither side has active sessions, to destroy it completely. So maybe KEEPALIVE should include the # sessions in the message as well.
(0014770)
xrs   
2019-08-04 16:56   
For further analysis: With regards to the keepalive, I saw that these are processed indirectly by gnunet-service-cadet_core.c:route_message(). Every time a message is routed the respective route is updated (r->last_use).

The function gnunet-service-cadet_core.c:timeout_cb() checks for this value and if expired sends a GNUNET_MESSAGE_TYPE_CADET_CONNECTION_BROKEN message to destroy the respective connection. The timeout task is set when a connection is created.
(0014773)
t3sserakt   
2019-08-05 09:23   
The timeout of connections is only loosely connected to the keepalive, because there is just no keepalive send if a connection is timing out. But there is no keepalive processed indirectly. There is no problem with connections in the context of this bug, but with missing handling of keepalive messages not arriving anymore.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5860 [Taler] wallet (WebExtensions) minor have not tried 2019-08-29 10:07 2019-11-02 21:27
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:  
Summary: browser wallet should allow completing an operation with a mobile/cli wallet
Description: There should be some button/link, and it should cause the wallet to render a QR code and link in lieu of the merchant/bank/audtior doing that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015050)
Florian Dold   
2019-11-02 21:27   
For this, the taler://pay QR code needs to be able to also transmit the nonce to the mobile wallet, as the browser wallet will have already claimed it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5959 [Taler] deployment and operations minor have not tried 2019-11-02 18:08 2019-11-02 18:08
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:  
Summary: buildbot workers do not pull deployment.git before proceeding
Description: This means that that there will be problems when deployment.git changes.

The workers should handle this automatically and fetch the latest version of deployment.git as the first step.
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:
5098 [Taler] Web site(s) tweak have not tried 2017-06-29 11:29 2019-11-01 23:22
Reporter: Marcello Stanisci Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: --prefix option would be useful
Description: Given that now it is a BB worker which builds the site, it needs to copy all the
HTML/CSS/static files in a separate directory. The woker does that becasue it wipes the local checkout before building the site, and that erases useful files too. So the useful files are to be copied in a safer place.

A './confifure --prefix' option would save the BB worker from manually copying HTML/CSS/static file into the safer place.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014683)
ng0   
2019-07-15 19:18   
Ack, will get to this after GSoC.
(0014823)
Florian Dold   
2019-08-29 22:55   
I don't think --prefix is the right way to do this.

Websites that are served with python are already packaged like normal python packages, either installed globally or per-user. There's nothing more we need to do there.

For websites that have just static files, the build system should produce a "dist" dir that contains all the files, and we then just need to copy this one directory instead of collecting together files manually. No need to complicate things with a --prefix argument and an "install" process that just copies data.
(0014833)
ng0   
2019-09-02 09:54   
Okay, this is what I did with gnunet.org
(0014841)
ng0   
2019-09-03 16:55   
I've switched the sh file used in the job for stage to copy file from the directory 'rendered' which contains all files (similar to how gnunet.org should be build once we have a buildbot doing this). Is this what you wanted, Marcello?
(0015047)
Florian Dold   
2019-11-01 23:22   
I've actually revised my opinion on this issue. The landing.git repository already supports --prefix, and www.git should do so too.

The main reason why I changed opinion on this matter is that we now have the taler-build-scripts.git, which makes setting up the build system to do this much easier and uniform across repositories.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5864 [Taler] other feature have not tried 2019-08-30 22:35 2019-11-01 23:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: refund URL should be derived from contract
Description: Currently the wallet only gets to know the refund URL when we the merchant is giving us a refund. This is awkward for mobile wallets, where the triggering of the refund could happen on a different device. In this case, it wouldn't even be necessary to scan a QR code if the wallet knew where to ask the merchant for the refund status.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015046)
Florian Dold   
2019-11-01 23:19   
The contract terms now contain a merchant_base_url field, which refers to the merchant backend or merchant backend instance.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5958 [Taler] bank (demonstrator) feature always 2019-11-01 22:50 2019-11-01 22:50
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: some accounts should not have a spending limit
Description: Accounts like "survey" shouldn't run out of funds, since this disrupts the tipping demo!

Maybe these can be marked as "service accounts".
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:
5957 [Taler] merchant backend API (C) minor have not tried 2019-11-01 18:23 2019-11-01 18:23
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: provide more convenient way to handle refund deadline
Description: Right now the frontend needs to compute the refund deadline if refunds should be allowed.

Ideally, either the config or the order creation just specifies a "refund delay", such as "30m" for 30 minutes.
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:
5956 [Taler] deployment and operations minor have not tried 2019-11-01 12:40 2019-11-01 12: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:  
Summary: replace the larger bash scripts in deployment.git with python
Description: ... this is already work in progress, but some are still there and especially atrocious, such as the ones using bash arrays (!!).
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 [libeufin] sandbox minor have not tried 2019-10-31 19:48 2019-10-31 19:48
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:  
Summary: use return codes from 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:
5948 [GNUnet] util library minor have not tried 2019-10-26 12:06 2019-10-31 09:25
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.11.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: idn / idn2 detection logic must be improved
Description: it works in not so obvious ways right now, not as intended
Tags:
Steps To Reproduce:
Additional Information: dnsparser.c: In function 'GNUNET_DNSPARSER_check_label':
dnsparser.c:65:7: error: 'IDNA_SUCCESS' undeclared (first use in this function); did you mean 'EXIT_SUCCESS'?
   if (IDNA_SUCCESS != idna_to_ascii_8z (label, &output, IDNA_ALLOW_UNASSIGNED))
       ^~~~~~~~~~~~
       EXIT_SUCCESS
dnsparser.c:65:7: note: each undeclared identifier is reported only once for each function it appears in
dnsparser.c:65:23: warning: implicit declaration of function 'idna_to_ascii_8z' [-Wimplicit-function-declaration]
   if (IDNA_SUCCESS != idna_to_ascii_8z (label, &output, IDNA_ALLOW_UNASSIGNED))
                       ^~~~~~~~~~~~~~~~
dnsparser.c:65:57: error: 'IDNA_ALLOW_UNASSIGNED' undeclared (first use in this function)
   if (IDNA_SUCCESS != idna_to_ascii_8z (label, &output, IDNA_ALLOW_UNASSIGNED))
                                                         ^~~~~~~~~~~~~~~~~~~~~
dnsparser.c: In function 'GNUNET_DNSPARSER_check_name':
dnsparser.c:101:7: error: 'IDNA_SUCCESS' undeclared (first use in this function); did you mean 'EXIT_SUCCESS'?
   if (IDNA_SUCCESS != idna_to_ascii_8z (name, &output, IDNA_ALLOW_UNASSIGNED))
       ^~~~~~~~~~~~
       EXIT_SUCCESS
dnsparser.c:101:56: error: 'IDNA_ALLOW_UNASSIGNED' undeclared (first use in this function)
   if (IDNA_SUCCESS != idna_to_ascii_8z (name, &output, IDNA_ALLOW_UNASSIGNED))
                                                        ^~~~~~~~~~~~~~~~~~~~~
dnsparser.c: In function 'parse_name':
dnsparser.c:232:3: error: unknown type name 'Idna_rc'
   Idna_rc rc;
   ^~~~~~~
dnsparser.c:256:11: error: 'IDNA_SUCCESS' undeclared (first use in this function); did you mean 'EXIT_SUCCESS'?
       if (IDNA_SUCCESS !=
           ^~~~~~~~~~~~
           EXIT_SUCCESS
dnsparser.c:257:17: warning: implicit declaration of function 'idna_to_unicode_8z8z' [-Wimplicit-function-declaration]
           (rc = idna_to_unicode_8z8z (tmp, &utf8, IDNA_ALLOW_UNASSIGNED)))
                 ^~~~~~~~~~~~~~~~~~~~
dnsparser.c:257:51: error: 'IDNA_ALLOW_UNASSIGNED' undeclared (first use in this function)
           (rc = idna_to_unicode_8z8z (tmp, &utf8, IDNA_ALLOW_UNASSIGNED)))
                                                   ^~~~~~~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_crypto_lib.h:59,
                 from ../../src/include/gnunet_util_lib.h:64,
                 from dnsparser.c:44:
dnsparser.c:262:21: warning: implicit declaration of function 'idna_strerror'; did you mean 'gcry_strerror'? [-Wimplicit-function-declaration]
                     idna_strerror (rc));
                     ^~~~~~~~~~~~~
../../src/include/gnunet_common.h:554:39: note: in definition of macro 'GNUNET_log'
           GNUNET_log_nocheck ((kind), __VA_ARGS__); \
                                       ^~~~~~~~~~~
dnsparser.c:260:24: warning: format '%s' expects argument of type 'char *', but argument 4 has type 'int' [-Wformat=]
                     _ ("Failed to convert DNS IDNA name `%s' to UTF-8: %s\n"),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/include/gnunet_common.h:554:39: note: in definition of macro 'GNUNET_log'
           GNUNET_log_nocheck ((kind), __VA_ARGS__); \
                                       ^~~~~~~~~~~
dnsparser.c:260:21: note: in expansion of macro '_'
                     _ ("Failed to convert DNS IDNA name `%s' to UTF-8: %s\n"),
                     ^
dnsparser.c: In function 'GNUNET_DNSPARSER_builder_add_name':
dnsparser.c:900:3: error: unknown type name 'Idna_rc'
   Idna_rc rc;
   ^~~~~~~
dnsparser.c:905:7: error: 'IDNA_SUCCESS' undeclared (first use in this function); did you mean 'EXIT_SUCCESS'?
   if (IDNA_SUCCESS !=
       ^~~~~~~~~~~~
       EXIT_SUCCESS
dnsparser.c:906:50: error: 'IDNA_ALLOW_UNASSIGNED' undeclared (first use in this function)
       (rc = idna_to_ascii_8z (name, &idna_start, IDNA_ALLOW_UNASSIGNED)))
                                                  ^~~~~~~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_crypto_lib.h:59,
                 from ../../src/include/gnunet_util_lib.h:64,
                 from dnsparser.c:44:
dnsparser.c:910:19: warning: format '%s' expects argument of type 'char *', but argument 4 has type 'int' [-Wformat=]
                   "Failed to convert UTF-8 name `%s' to DNS IDNA format: %s\n"),
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/include/gnunet_common.h:554:39: note: in definition of macro 'GNUNET_log'
           GNUNET_log_nocheck ((kind), __VA_ARGS__); \
                                       ^~~~~~~~~~~
dnsparser.c:909:17: note: in expansion of macro '_'
                 _ (
                 ^
*** [dnsparser.lo] Error code 1

make[3]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6/src/util
1 error

make[3]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6/src/util
*** [all-recursive] Error code 1

make[2]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6/src
1 error

make[2]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6/src
*** [all-recursive] Error code 1

make[1]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6
1 error

make[1]: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6
*** [all] Error code 2

make: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6
1 error

make: stopped in /usr/work/wip/gnunet/work/gnunet-0.11.6
*** Error code 2

Stop.
make[1]: stopped in /usr/pkgsrc/wip/gnunet
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wip/gnunet
Attached Files: gnunet_config.h (24,114 bytes) 2019-10-26 15:10
https://bugs.gnunet.org/file_download.php?file_id=859&type=bug
config.log (548,627 bytes) 2019-10-26 15:31
https://bugs.gnunet.org/file_download.php?file_id=860&type=bug
Notes
(0015028)
Christian Grothoff   
2019-10-26 14:41   
Please attach the gnunet_config.h you got on the platform.
(0015029)
ng0   
2019-10-26 15:14   
(Last edited: 2019-10-26 15:17)
I do not get this with master in my user environment.

also the gnunet_config.h seems pretty clear about the problem, reading it now - there is no IDN at all.

in pkgsrc, relevant snippet I pass in:

# idn is mandatory but idn or idn2 can be used with a preference
# for idn2.
.if !empty(PKG_OPTIONS:Midn)
.include "../../devel/libidn2/buildlink3.mk"
CONFIGURE_ARGS+= --with-libidn2=${BUILDLINK_PREFIX.libidn2}
.else
.include "../../devel/libidn/buildlink3.mk"
CONFIGURE_ARGS+= --with-libidn=${BUILDLINK_PREFIX.libidn}
.endif


so the configure switch + the path is passed, which is confusing why we end up with no idn at all in this context.
It works when I don't add the "idn" option - then I had "idn 1".

(0015031)
ng0   
2019-10-26 15:25   
(Last edited: 2019-10-26 15:26)
This results in idn2_msg being "yes", ie idn2 is found:

checking idna.h usability... no
checking idna.h presence... no
checking for idna.h... no
checking idn/idna.h usability... no
checking idn/idna.h presence... no
checking for idn/idna.h... no
checking if libidn can be used... configure: Checking for libidn2
checking for idn2_to_unicode_8z8z in -lidn2... yes

I think I'll have a look at the detection code. Of course some of these messages could be wrong since autotools does sometimes not include necessary libraries on other systems.

(0015032)
ng0   
2019-10-26 15:31   
the config.log results seem suspicious.
(0015045)
ng0   
2019-10-31 09:15   
I'll fix the configure script.


Niclas Rosenvik / NetBSD:

I don't know really but I believe that the problem is in the configure
script. Setting --with-libidn2 makes configure search for idna.h when
it should search for idn2.h. I tried using --with-libidn=no without
setting --with-libidn2, that makes configure search for idn2.h after
it finds libidn2. --with-libidn2 disables search of idn2.h for me at
least. And for me it is the same behavior of I call ./configure
directly as if I run bmake configure. You can try to have
--with-libidn=no in options.mk instead of
--with-libidn2=${BUILDLINK_PREFIX.libidn2} and see how that works.
I know its a little backwards to have the idn option turn of libidn but
it seems to work.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5954 [libeufin] other minor have not tried 2019-10-29 18:00 2019-10-29 18:00
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:  
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:
5952 [Taler] Web site(s) feature N/A 2019-10-28 13:08 2019-10-28 13:26
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: move www.git to GNU-style build system and allow "make install"
Description: This has already been done for landing.git. We should use the new (submodule-based) build system. This makes it easy to do a "make install" instead of having to copy stuff manually in the BB jobs.

See the Makefile in landing.git for where/how to copy the website contents.
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:
5840 [Taler] deployment and operations minor have not tried 2019-08-18 15:24 2019-10-28 13:01
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:  
Summary: set up buildbot to run taler-wallet-cli periodically against test and demo
Description: Buildbot should
 * download the latest wallet from NPM
 * use the CLI to trigger the integration test against {test,demo}.taler.net
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015043)
ng0   
2019-10-28 12:57   
More along the lines of "what makes a complete test" as I'm not yet testing all subcommands of integration test.
A complete test == all subcommands, but for {demo, test} depending on the runner?
(0015044)
Florian Dold   
2019-10-28 13:01   
Right now the headless wallet doesn't implement tests for certain functionality. While this functionality will be exposed separately as well, it should be part of the "integrationtest" subcommand as well.

Of course in the future some modifications might be needed, for example when "integrationtest" learns to also run some auditor-related checks.

("integrationtest" runs a bunch of tests against the specified URLs but doesn't depend on any local state, while the other subcommands manipulate your local wallet database.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5951 [gnunet-gtk] build system minor have not tried 2019-10-27 19:02 2019-10-28 00:32
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: Fails to test / link gtk+ on alpine
Description: Config.log attached.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: config.log (57,530 bytes) 2019-10-27 19:02
https://bugs.gnunet.org/file_download.php?file_id=861&type=bug
Notes
(0015039)
ng0   
2019-10-28 00:32   
It looks as if musl requires some more work / other tests, xrs might know something about how to build this?

/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/libxkbcommon.so.0: undefined reference to `secure_getenv'


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5944 [libmicrohttpd] build system block always 2019-10-22 17:48 2019-10-26 19:43
Reporter: pierrey Platform: Win32  
Assigned To: Christian Grothoff OS: Windows 7  
Priority: normal OS Version: 7  
Status: resolved Product Version: 0.9.66  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.69  
    Target Version: 0.9.69  
Summary: Cannot build with Visual Studio 2017
Description: Linker says symbol _MHD_send_on_connection2_ cannot be resolved.
Tags:
Steps To Reproduce: # Start the Visual Studio 2017 Developer Command Line
C:\Users\Pierre\> git clone https://git.gnunet.org/libmicrohttpd.git
C:\Users\Pierre\> cd libmicrohttpd\w32\VS2017
C:\Users\Pierre\> msbuild /m /v:n /p:Configuration="Release-static" /p:Platform=Win32 libmicrohttpd.sln
Additional Information: Found a fix, mhd_send.{c,h} must be referenced in w32\common\libmicrohttpd-files.vcxproj :

 w32/common/libmicrohttpd-files.vcxproj | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/w32/common/libmicrohttpd-files.vcxproj b/w32/common/libmicrohttpd-files.vcxproj
index 512c18bb..e4f2cada 100644
--- a/w32/common/libmicrohttpd-files.vcxproj
+++ b/w32/common/libmicrohttpd-files.vcxproj
@@ -21,6 +21,7 @@
     <ClCompile Include="$(MhdSrc)microhttpd\mhd_sockets.c" />
     <ClCompile Include="$(MhdSrc)microhttpd\mhd_itc.c" />
     <ClCompile Include="$(MhdSrc)microhttpd\mhd_compat.c" />
+ <ClCompile Include="$(MhdSrc)microhttpd\mhd_send.c" />
   </ItemGroup>
   <ItemGroup>
     <ClInclude Include="$(MhdSrc)include\autoinit_funcs.h" />
@@ -48,6 +49,7 @@
     <ClInclude Include="$(MhdSrc)microhttpd\mhd_itc.h" />
     <ClInclude Include="$(MhdSrc)microhttpd\mhd_itc_types.h" />
     <ClInclude Include="$(MhdSrc)microhttpd\mhd_compat.h" />
+ <ClInclude Include="$(MhdSrc)microhttpd\mhd_send.h" />
     <ClInclude Include="$(MhdW32Common)MHD_config.h" />
   </ItemGroup>
   <ItemGroup>
Attached Files:
Notes
(0015033)
Christian Grothoff   
2019-10-26 19:43   
Fixed as suggested by reporter in 86186edb..fccdf422


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5896 [GNUnet] transport service minor have not tried 2019-09-16 12:31 2019-10-26 11:05
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: investigate if we can drop or replace our bundled ieee80211_radiotap.h depending in systems we build on
Description: our bundled src/transport/ieee80211_radiotap.h which hasn't been touched for 0000013:0000010 years is very close to the original import of this work which started in NetBSD (as net80211/ieee80211_radiotap.h etc) and was imported in Linux as net/ieee80211_radiotap.h.

this ticket serves to remind me to find a solution for this, however hybrid or not. ideally the file can be dropped.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015027)
ng0   
2019-10-26 11:05   
Note for myself:
This is conditional, depending on Kconfig values which can be set on a range of systems, but can also not exist on others.

I will look into how this can be solved conditionally.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5934 [libeufin] sandbox minor have not tried 2019-10-18 18:30 2019-10-23 13:52
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Return _EBICS_ specific error responses
Description: Right now the sandbox returns error responses in a native JSON format, even when those are generated under /ebicsweb. Instead, it should return proper EBICS-compliant error messages.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015023)
Marcello Stanisci   
2019-10-23 13:52   
14cabeb..fa2705f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5940 [libeufin] sandbox minor have not tried 2019-10-22 12:02 2019-10-23 10:20
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Avoid duplication of Java classes
Description: The JAXB packages automatically imported have several classes in common. Ideally, we should merge all the "tech.libeufin.messages.ebics.*" packages into one. And moreover, only one ObjectFactory class should exist.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015022)
Marcello Stanisci   
2019-10-23 10:18   
(Last edited: 2019-10-23 10:20)
Automatically generated code *can* have some duplicate parts.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5945 [Taler] Web site(s) minor have not tried 2019-10-22 19:17 2019-10-22 19:17
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: buildbot: add job for demo.taler.net website
Description: the demo pages seem to have no automatic rebuild, elements I removed are still present.
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:
5931 [Taler] deployment and operations major have not tried 2019-10-16 17:30 2019-10-22 17:28
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: modify walletbuilder builder to split out into 2 new jobs
Description: > - worker-demo
> - worker-test

AFAIK these are just some *very* basic health checks that see via curl if the exchange/merchant are reachable.

the taler-wallet-cli health checks should replace those two workers, and they should be given a better name.
Like taler-{test,demo}-healthcheck
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015021)
ng0   
2019-10-22 17:28   
The builders exist since yesterday, but I'm waiting on the reply for the email dated from
Fri, 18 Oct 2019 17:48:59 +0000
to proceed with this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5942 [libeufin] nexus minor have not tried 2019-10-22 16:21 2019-10-22 16:22
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:  
Summary: design API for transaction history and transaction triggering
Description: The transaction triggering must work in a "prepare and commit" fashion, where prepare and commit and *separate* API requests. This allows recovering from crashes by first committing operations and later re-trying 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:
5941 [libeufin] sandbox minor have not tried 2019-10-22 16:19 2019-10-22 16: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:  
Summary: spec and implement bank account and transaction API
Description: This is basically the "bank core" part of the sandbox. There is only one underlying schema, and the different backends (EBICS, FinTS, ...) all access the same schema.
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:
5939 [Taler] mechant backend feature have not tried 2019-10-21 10:21 2019-10-21 10:22
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: expose protocol version for merchant backend
Description: Similarly to the exchange, the merchant API protocol version should be exposed, probably by a *public* /config endpoint.
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 [libeufin] sandbox minor have not tried 2019-10-18 19:16 2019-10-18 19:17
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:  
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.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5932 [GNUnet] webpage feature have not tried 2019-10-16 18:27 2019-10-16 18:35
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: improve copyright assignment page
Description: in simpler language explain the scope of it (and tl;dr the assignment);
translate the eV satzung;
add a html output of the copyright assignment;
explain that it is unlike bigger corporate projects, changes and questions are worked on etc.

all of this comes from questions and people who didn't understand parts of the process or simply
have some reason to refuse assignments 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:
5930 [Taler] mechant backend feature N/A 2019-10-16 15:46 2019-10-16 15:46
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: low OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: control of instances over contract terms should be restricted
Description: Currently, instance A can "pretend" to be instance B, by supplying the information of B in the contract terms.

Unless *explicitly* configured, an instance should not be able to set certain fields of the contract terms, such as the merchant field. This field should be taken from the instance configuration instead.
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:
5369 [GNUnet] cadet service crash sometimes 2018-06-27 17:13 2019-10-13 21:43
Reporter: ch3 Platform:  
Assigned To: ch3 OS: archlinux  
Priority: normal OS Version: 2018-06-27  
Status: feedback Product Version: 0.11.0pre66  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Process terminating with default action of signal 6 (SIGABRT)
Description: I see valgrind reporting
Process terminating with default action of signal 6 (SIGABRT)
I don't know which subsystem this belongs to.
Tags:
Steps To Reproduce: Run rps tests (make check in src/rps/).
Additional Information: Valgrind output:

==25468== Memcheck, a memory error detector
==25468== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25468== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25468== Command: [...]/lib//gnunet/libexec/gnunet-service-rps -c /tmp/testbedukvI9i/2/config
==25468== Parent PID: 25461
==25468==
==25468==
==25468== Process terminating with default action of signal 6 (SIGABRT)
==25468== at 0x6FC586B: raise (in /usr/lib/libc-2.27.so)
==25468== by 0x6FB040D: abort (in /usr/lib/libc-2.27.so)
==25468== by 0x505711E: GNUNET_abort_ (common_logging.c:282)
==25468== by 0x52CF354: reconnect (cadet_api.c:1163)
==25468== by 0x52CCF70: reconnect_cbk (cadet_api.c:371)
==25468== by 0x50A251E: GNUNET_SCHEDULER_do_work (scheduler.c:2104)
==25468== by 0x50A3439: select_loop (scheduler.c:2405)
==25468== by 0x509D851: GNUNET_SCHEDULER_run (scheduler.c:725)
==25468== by 0x50A94AA: GNUNET_SERVICE_run_ (service.c:1875)
==25468== by 0x11D72F: main (gnunet-service-rps.c:4419)
==25468==
==25468== HEAP SUMMARY:
==25468== in use at exit: 68,775 bytes in 2,598 blocks
==25468== total heap usage: 23,242 allocs, 20,644 frees, 812,897 bytes allocated
==25468==
Attached Files:
Notes
(0013091)
Christian Grothoff   
2018-06-27 21:46   
I thought you had some much longer valgrind use-after-free issue?
(0013096)
Christian Grothoff   
2018-06-28 10:24   
Possible fix in 6bba039b3..aab6c1174. Feedback requested.
(0015009)
schanzen   
2019-10-13 21:43   
Removing from 0.11.7 as reporter seems awol.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5733 [Taler] mechant backend crash have not tried 2019-05-24 19:50 2019-10-11 23:52
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: merchant does not recover from restarted postgres
Description: If you restart the database while the merchant is running, the merchant does not seem to recover from it.

Additionally, there are a *lot* of subsequent log lines where the merchant is presumably trying to get keys from the exchange. Maybe this has to do with some retry logic that is going haywire?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014438)
Florian Dold   
2019-05-24 19:52   
Of course, a taler-deployment-restart "fixes" this, but the merchant backend must be able to recover from this on its own.
(0014451)
Marcello Stanisci   
2019-05-27 19:25   
How exactly the merchant crashes?

Do you have any logs?

How can I reproduce this?
(0014904)
Christian Grothoff   
2019-09-16 09:47   
I will try to look into this.
(0014997)
Christian Grothoff   
2019-10-11 14:37   
I've started work on a larger patch to address this. Uncommittable so far.
(0015005)
Christian Grothoff   
2019-10-11 23:52   
Fixed with recent GNUNET_PQ API change. Basically, after DB reconnect, the current (or next) transaction fails (with a SOFT error), but then things should be back in order (GNUNET_PQ auto-reconnects).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5928 [libeufin] sandbox minor have not tried 2019-10-11 13:09 2019-10-11 13:45
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: new warning appeared after upgrading Java to 11. To be fixed.
Description: WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (file:/home/user/.gradle/caches/modules-2/files-2.1/org.glassfish.jaxb/jaxb-runtime/2.3.0/c50f1a599ff0fcf3944e7467cf3cfae1374f4fd6/jaxb-runtime-2.3.0.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014996)
Marcello Stanisci   
2019-10-11 13:45   
fixed here: e492d02..402ae71


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5650 [GNUnet] statistics service minor always 2019-03-16 17:55 2019-10-10 22:46
Reporter: ic.rbow Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Metrics collected by statistics lack canonical identifiers
Description: $ gnunet-statistics -s nse

          nse # flood messages received: 13
          nse # peers connected: 4
          nse # nodes in the network (estimate): 203
          nse # flood messages started: 5
          nse # estimated network diameter: 3
          nse # flood messages transmitted: 10

With such verbose keys there's no easy way to form compact JSON document or entries for time-series database.

And you can't query single stats without having to copypaste the line exactly and put in quotes:

    $ gnunet-statistics -s nse -n "# nodes in the network (estimate)"

instead of

    gnunet-statistics -s nse -n network.nodes
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014776)
schanzen   
2019-08-08 19:41   
This is a good point. Any change will likely result in touching a lot of code, though, so we should work out a reasonable way to do this.
(0014995)
ic.rbow   
2019-10-10 22:46   
The process can be gradual, at the expense of having to duplicate metrics, if the services would do the same operation for both "fully readable" and "compact" keys.
Maybe it can even be configured and/or CPPd out of the code.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5920 [GNUnet] GNS tweak always 2019-10-05 22:25 2019-10-10 18:30
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.0  
Summary: LSD001 meta issue
Description: This issue tracks all changes to LSD001 (GNS Specification).
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:
5914 [libeufin] sandbox minor have not tried 2019-09-30 08:49 2019-10-09 15:22
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: configure logging
Description: We don't want to see debug logs from stuff like the Netty web server!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014985)
Marcello Stanisci   
2019-10-08 18:11   
cffa45651040778354c73ddc sets up the logging via the logback.xml file(s). It also attempts to turn logs from Ktor off, but currently fails.
(0014988)
Marcello Stanisci   
2019-10-09 15:22   
0511ac5ec54e69d fixes it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5918 [libeufin] nexus feature N/A 2019-10-03 16:23 2019-10-08 15:43
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create nexus project skeleton
Description: The nexus code should live in the same repo as the sandbox, but in a different module.

Basically both sandbox and nexus should be a gradle module inside the libeufin.git repo. The layout will look like this:

+ libeufin
++ README
++ build.gradle (top-level build file)
++ sandbox (sandbox module)
+++ build.gradle (build file for sandbox)
+++ README (for sandbox module)
+++ ...
++ nexus
+++ build.gradle
+++ README

For a tutorial on how to do this, see https://guides.gradle.org/creating-multi-project-builds/

For the nexus skeleton, we need to set up the following
* an HTTP server (using ktor)
* an HTTP client (*also* using ktor, which has client support as well)
* the database (again using exposed)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014981)
Marcello Stanisci   
2019-10-08 12:34   
323e08712336ae3 gets it quite done. However, the 'org.jetbrains.kotlin.jvm' plugin gave problems when tried to be loaded from the global Gradle configuration file. As a workaround (?), it needed to be imported from all the Gradle build files. Supposedly, there is a way to include it only once and globally.
(0014984)
Marcello Stanisci   
2019-10-08 15:43   
40811b1ccee closes this; addressing also the note above.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5926 [GNUnet] TCP transport tweak always 2019-10-08 11:05 2019-10-08 14:07
Reporter: corvuscorax Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: service configuration inconsistent for ipv6 environment
Description: service configuration for tcp service is inconsistent with other services in regard to binding to a specific IPv6 address/port
while other services offer two config options
BINDTO=
and
BINDTO6=

each accepting a respective IPv4/6 address

the tcp service has only BINDTO= which - according to source code (tcp_service_legacy.c) - accepts a hostname, which is then resolved to either a v4 or a v6 address

Tags: configuration
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014983)
Christian Grothoff   
2019-10-08 14:07   
True, albeit with TNG we're hoping to replace that entire piece of code. Hence I'm not sure it's worth fixing this issue at this time.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5923 [libeufin] sandbox feature N/A 2019-10-07 13:49 2019-10-07 17:15
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: add unit tests for schema validation
Description: We should have unit tests that validate example XML files against the xsd files.

For unit tests, we should follow these guidelines: https://phauer.com/2018/best-practices-unit-testing-kotlin/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014980)
Marcello Stanisci   
2019-10-07 17:14   
Done: a7f51ef..87974b4. For now tries HEV and INI (that fails).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5924 [libeufin] sandbox feature N/A 2019-10-07 13:58 2019-10-07 13: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:  
Summary: implement helper functions to do XML Signing/Encryption for EBICS
Description: Basically we need helper functions to sign, validate, encrypt and decrypt XML using the XML Signing/Encryption standards.
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:
5913 [libeufin] command-line tools feature N/A 2019-09-30 08:26 2019-10-03 17:53
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: implement command line tool in Python to access sandbox APIs
Description: The tool should be written in Python, as the JVM has unacceptable startup performance for CLI tools.

In particular, we shall:
* use click (https://click.palletsprojects.com/) to implement the command line interface
* have git-style subcommands for each sub-task

Basically every API endpoint should be covered by one CLI command.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014971)
Marcello Stanisci   
2019-10-02 16:01   
The tool is now usable, it is found under "libeufin.git/src/main/python/libeufin-cli".

bffb1419c23708dd9fd4
(0014972)
Marcello Stanisci   
2019-10-02 16:02   
Setting as 'feedback' in case of suggestions, otherwise shall be closed.
(0014975)
Marcello Stanisci   
2019-10-03 17:52   
closing after removing the mock (d025bc5b1ee362a1527..)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5901 [libeufin] sandbox minor have not tried 2019-09-19 16:15 2019-10-03 17: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:  
Summary: design database schema and implement DB bindings
Description: For DB bindings, we should use this: https://github.com/JetBrains/Exposed

There are multiple separate components that need to use the database:
* bank account data and transactions
* EBICS key management
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:
5888 [libeufin] General minor have not tried 2019-09-10 18:40 2019-10-03 16:17
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: urgent OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create project skeleton for libeufin and sandbox
Description: The sandbox and the rest of libeufin should live in the same repository for now.

In particular:

* it should be a kotlin project (you can use IntelliJ to create it)
* the build system must be gradle (https://gradle.org/)
  (the IntelliJ template should offer gradle as an option!)
* gradle should be used to manage all dependencies (Ktor, XML libraries, ...)
* create demo HTTP server using Ktor (https://github.com/ktorio/ktor), which should answer the ebicsHEVRequest.
* to allow our testing, the sandbox should just print request messages it doesn't understand into a log file
* the incoming messages should be validated using the EBICS *.xsd schema files (it's probably best to start with EBICS 3.0), with whatever XML validation library is appropriate.
* the sandbox service should be deployed to libeufin@gv, which might require the installation of some additional packages (JVM, Kotlin).

Other things we need to choose include:
* database bindings for kotlin (to talk to postgres)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014888)
Marcello Stanisci   
2019-09-11 16:25   
(Last edited: 2019-09-11 16:26)
import ktor into gradle: https://ktor.io/quickstart/quickstart/gradle.html

(0014890)
Florian Dold   
2019-09-12 13:36   
Some other things that need to be part of the skeleton:

* A readme that explains the steps to build and run the sandbox server (using the command line, not IntelliJ)
* The license (AGPL)
* License headers
(0014892)
Marcello Stanisci   
2019-09-12 16:56   
fixed here 5818bd6..aaa7ada.
(0014893)
Florian Dold   
2019-09-12 19:53   
I don't see the XML request+response schema validation yet.

The "RUN" file should also be just called "README", since that's the standard name where everybody looks!

And ideally, the server should already be able correctly respond to the "version request" EBICS message. Then it's a good starting point for further investigating the protocol.
(0014894)
Marcello Stanisci   
2019-09-12 22:43   
Native Java library offering crypto for XML:
https://www.oracle.com/technetwork/articles/javase/dig-signatures-141823.html#intro
(0014921)
Marcello Stanisci   
2019-09-19 02:09   
Initial setup completed here: 3c51352..08b9a9d
(0014923)
Florian Dold   
2019-09-19 14:47   
Since there will be *lots* of sharing between sandbox and nexus, there should really only be one repository.

We can have multiple entry points still for sandbox, nexus and various tools
(0014925)
Florian Dold   
2019-09-19 16:10   
Also, the Kotlin Coding Style should be followed, and ideally enforced via the ktlint tool.
(0014970)
Marcello Stanisci   
2019-10-01 13:41   
(Last edited: 2019-10-01 13:42)
Coding style was manually reviewed, but not ktlint-ed. Given that linting is something that makes _always_ sense to do, I don't think the linter part should keep this bug still open. Shall we close it?

(0014974)
Florian Dold   
2019-10-03 16:17   
Looks good to me.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5917 [GNUnet] webpage minor have not tried 2019-10-02 14:05 2019-10-02 14:05
Reporter: ng0 Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: write subpages for projects and structure them (gns, gnurl, fs, etc)
Description: we should have something like /projects/{projectname} where
/projects/ gives a full listing of {projectname}s and
/projects/{projectname}/ contains information related to the project.
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:
5916 [GNUnet] webpage minor have not tried 2019-10-02 14:01 2019-10-02 14:01
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: redirect script
Description: write a script to automate the creation of static redirect pages
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:
5855 [Taler] other minor have not tried 2019-08-27 15:16 2019-09-27 18:33
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: get rid of copylib in favor of using real python packaging
Description: We can simply upload a taler helper package to the python package archive. There is no need to copy around code ...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014913)
ng0   
2019-09-18 15:25   
this is basically copylib -> packaging -> pypi; adjust code which now copies around code to pypi install that pypi file.
correct me if I missed a detail, I can do this.
(0014922)
Florian Dold   
2019-09-19 11:03   
Yes. The library should probably be named something like "taler-util".

Then I should be able to do something like

  import taler.util.Amount as Amount

(For a technical explanation of namespaces, see this <https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-packages>. We also have other taler python packages, but we might wanna have them under the same "taler" namespace prefix.)
(0014926)
ng0   
2019-09-19 17:42   
Okay, thanks.
(0014931)
ng0   
2019-09-24 09:47   
So about the kleingedrucktes TODO item point:

is the identification for author and copyright right?
see https://git.taler.net/taler-util.git/tree/setup.py
(0014932)
Florian Dold   
2019-09-24 09:58   
I'd put "Utility library for GNU Taler" as a description, as it's not really related to any build process!

Generally we want to keep version numbers roughly consistent between components. Thus the version should be 0.6.0rc1 (a pre-release version, see https://www.python.org/dev/peps/pep-0440/#pre-releases). When we release 0.6, it should be bumped to "0.6.0".

When you upload to PyPI, could you please also add Marcello and me as a maintainer?
(0014933)
ng0   
2019-09-24 10:39   
(Last edited: 2019-09-24 10:41)
> When you upload to PyPI, could you please also add Marcello and me as a maintainer?

if it's not clear from within pypi (I have an account), can you tell me your names on pypi?
I also assume from this statement that you want to handle the uploading of wheel files, correct?

(0014934)
Florian Dold   
2019-09-24 10:48   
Ah, I don't have an account there yet, neither does Marcello.

I don't want to handle the upload myself, I assumed you'd put yourself as the owner of the package. If you don't want to do this, we can just use an @taler.net email alias as a "team account" to handle PyPI uploads. But I guess they require a person and not an org to sign up.

I just want Marcello and me to have upload access too to increase the "bus factor", in case you're not able to do uploads for a longer stretch of time, somebody else should be able to do it too.
(0014935)
ng0   
2019-09-24 11:02   
Okay, that's more clear and I agree.
I assume pypi is easy, I only signed up ahead of time because I intended to publish some packages I work on myself, I just have to read into the whole process. Looked easy so far, guess we just got terminology mixed up.

Thanks!
(0014936)
ng0   
2019-09-24 11:20   
if we have LGPL2.1 code with the "and later", and now LGPL3 is out, some systems consider this
LGPL3 code. should we go with this, or how should we handle these lgpl2.1+ files?
(0014937)
Florian Dold   
2019-09-24 11:28   
It should indeed be just LGPL3 then, good catch!
(0014938)
ng0   
2019-09-24 12:04   
is the distributed wheel then "AGPL3+ AND LGPL3+" or "AGPL3+"? So far I have it as a list ["AGPL3", "LGPL2.1"].
I'm no fan of "or later" license definitions, but if we still want to put it as LGPL3+ it seem lined up with what
Marcello did with LGPL2.1+
(0014939)
Florian Dold   
2019-09-24 12:07   
Since this is a GNU project, we're going with LGPL3+.

I don't really know how the AGPL got into this. At some point we decided that the helper libraries should be LGPL, not AGPL.

Only components that are services (exchange, merchant, ...) have AGPL.
(0014940)
ng0   
2019-09-24 12:07   
I think I have to be more precise: distributors choose version 3 when presented with a choice, but 2.1+ still means as a developer you got to pick any of 2.1 or 3. so unconditionally bumping is not necessary.
(0014941)
ng0   
2019-09-24 12:09   
(Last edited: 2019-09-24 12:11)
> I don't really know how the AGPL got into this. At some point we decided that the helper libraries should be LGPL, not AGPL.

Okay, can you then do the relicensing, or is it enough for the record if I point to this ticket and your okay? Formally only the copyright holders can relicense, and the agpl3 files are (c) INRIA.
better safe than sorry, even though I know it's minimal and probably no one will care, but I learned to nitpick when it comes to licenses.

(0014942)
ng0   
2019-09-24 14:07   
okay, so what I have is ready for release and would push to pypi.org once you commit the license change. assign back to me when you're done.
(0014943)
Florian Dold   
2019-09-24 14:10   
Could you please just change the license headers yourself? Christian and me both approved the change, and it reflects wrong information (as copyright was assigned to Taler Systems SA) anyway.
(0014944)
ng0   
2019-09-24 14:16   
Ah, okay. I thought we needed this additional step because nothing of this was mentioned. I'll do it. Thanks.
(0014945)
ng0   
2019-09-24 14:38   
On both NetBSD and Linux I get a reliable test failure. Before I push to pypi, is this something I am supposed to fix (as in: can we ignore this or not?) or will anyone of you get to it?

python3.7 setup.py test
running test
running egg_info
writing taler_util.egg-info/PKG-INFO
writing dependency_links to taler_util.egg-info/dependency_links.txt
writing top-level names to taler_util.egg-info/top_level.txt
writing manifest file 'taler_util.egg-info/SOURCES.txt'
running build_ext
test_force_logfile (tests.log_test.TestGnunetLog) ... ok
test_forced_env_AND_nonforced_env (tests.log_test.TestGnunetLog) ... ok
test_manual_loglevel_AND_forced_env (tests.log_test.TestGnunetLog) ... ok
test_manual_loglevel_AND_nonforced_env (tests.log_test.TestGnunetLog) ... ok
test_no_env_and_no_setup (tests.log_test.TestGnunetLog) ... ok
test_non_forced_env (tests.log_test.TestGnunetLog) ... FAIL
test_only_forced_env (tests.log_test.TestGnunetLog) ... ok
test_only_manual_loglevel_setup (tests.log_test.TestGnunetLog) ... ok
test_add_and_dump (tests.test_amount.TestAmount) ... ok
test_bad_stringification (tests.test_amount.TestAmount) ... ok
test_negative_value (tests.test_amount.TestAmount) ... ok
test_parse_and_cmp (tests.test_amount.TestAmount) ... ok
test_stringify (tests.test_amount.TestAmount) ... ok
test_subtraction (tests.test_amount.TestAmount) ... ok
test_very_big_number (tests.test_amount.TestAmount) ... ok

======================================================================
FAIL: test_non_forced_env (tests.log_test.TestGnunetLog)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/pkg/lib/python3.7/site-packages/mock/mock.py", line 1330, in patched
    return func(*args, **keywargs)
  File "/home/ng0/src/taler/taler-util/tests/log_test.py", line 131, in test_non_forced_env
    mocked_setLevel.assert_called_with(level=logging.ERROR)
  File "/usr/pkg/lib/python3.7/site-packages/mock/mock.py", line 944, in assert_called_with
    six.raise_from(AssertionError(_error_message(cause)), cause)
  File "<string>", line 3, in raise_from
AssertionError: expected call not found.
Expected: setLevel(level=40)
Actual: setLevel(level=20)

----------------------------------------------------------------------
Ran 15 tests in 0.032s

FAILED (failures=1)
Test failed: <unittest.runner.TextTestResult run=15 errors=0 failures=1>
error: Test failed: <unittest.runner.TextTestResult run=15 errors=0 failures=1>
(0014946)
Florian Dold   
2019-09-24 14:40   
Yes, the tests should all pass before we upload the package.
(0014947)
ng0   
2019-09-24 14:55   
Okay, I'm looking into it again.
(0014948)
ng0   
2019-09-24 16:06   
It's not recent, this fails in copylib for me as well.
(0014949)
Florian Dold   
2019-09-24 16:07   
That's possible. If you can't figure out why the test case fails yourself or if you're unsure about the functionality it should provide, please ask Marcello, as he originally wrote the code in copylib.git
(0014950)
ng0   
2019-09-24 16:13   
I have been trying to wrap my head around it, but marcello would likely be faster - I found out that this is a part I have to learn about mock.
(0014951)
ng0   
2019-09-24 16:16   
(Last edited: 2019-09-24 16:16)
Essentially I don't know where this magic(?) linenumber comes from (the 99) or how it relates to the test (which call is not found? in gnunet_logger? do I need any prerequisites running, even though the mock test does not read like I do need more than the python modules and a /tmp?)

(0014953)
ng0   
2019-09-24 19:51   
is the expected assert maybe wrong?

git commit 2f9384498f26f382452e41440dd0fa1f45935ea1 and this diff:

diff --git a/tests/log_test.py b/tests/log_test.py
index 268e176..9758476 100755
--- a/tests/log_test.py
+++ b/tests/log_test.py
@@ -128,7 +128,8 @@ class TestGnunetLog(TestCase):
         os.environ["GNUNET_LOG"] = "gnunet-pylog;log_test.py;test_non_forced_env;99;ERROR" # lineno is not 100% accurate.
         gl = GL("gnunet-pylog")
         gl.log("msg", gl.DEBUG)
- mocked_setLevel.assert_called_with(level=logging.ERROR)
+ # mocked_setLevel.assert_called_with(level=logging.ERROR)
+ mocked_setLevel.assert_called_with(level=logging.INFO)
 
     ##
     # This function tests the case where *only* the GNUNET_FORCE_LOG


lead to this test output:

running test
running egg_info
writing taler_util.egg-info/PKG-INFO
writing dependency_links to taler_util.egg-info/dependency_links.txt
writing top-level names to taler_util.egg-info/top_level.txt
writing manifest file 'taler_util.egg-info/SOURCES.txt'
running build_ext
test_force_logfile (tests.log_test.TestGnunetLog) ... ok
test_forced_env_AND_nonforced_env (tests.log_test.TestGnunetLog) ... ok
test_manual_loglevel_AND_forced_env (tests.log_test.TestGnunetLog) ... ok
test_manual_loglevel_AND_nonforced_env (tests.log_test.TestGnunetLog) ... ok
test_no_env_and_no_setup (tests.log_test.TestGnunetLog) ... ok
test_non_forced_env (tests.log_test.TestGnunetLog) ... ok
test_only_forced_env (tests.log_test.TestGnunetLog) ... ok
test_only_manual_loglevel_setup (tests.log_test.TestGnunetLog) ... ok
test_add_and_dump (tests.test_amount.TestAmount) ... ok
test_bad_stringification (tests.test_amount.TestAmount) ... ok
test_negative_value (tests.test_amount.TestAmount) ... ok
test_parse_and_cmp (tests.test_amount.TestAmount) ... ok
test_stringify (tests.test_amount.TestAmount) ... ok
test_subtraction (tests.test_amount.TestAmount) ... ok
test_very_big_number (tests.test_amount.TestAmount) ... ok

----------------------------------------------------------------------
Ran 15 tests in 0.030s

OK
(0014954)
Florian Dold   
2019-09-24 21:39   
Yeah looks like the assert was wrong.
(0014955)
ng0   
2019-09-24 22:36   
Okay, committing the diff.
Thanks.
At least I learned more about mock today :)
(0014960)
ng0   
2019-09-25 13:48   
Okay, I thought I was done, but I just checked bank.git.

Next step I'm working on now is syncing the individual copylib forks back into taler-util.
Then I'll do a new release of taler-util (rc2 I guess...),
and then move all copylib users to just use taler-util.
(0014961)
ng0   
2019-09-25 13:58   
(Last edited: 2019-09-25 16:21)
Not trying to be too chatty about this work, but on further looks I'll just merge what I know can not backfire, then compare the individual changes and get back to you if I see any large changes.

(0014962)
ng0   
2019-09-25 14:39   
(Last edited: 2019-09-27 18:24)
For myself as reference, remaining:
./django-payments-taler/payments/taler/amount.py
./playground/talerplayground/talerconfig.py [where did this repo disappear to in the last months?]

(0014967)
ng0   
2019-09-27 18:33   
what is playground and where did it move to?
I don't have all the repos but this one turned up to contain talerconfig.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5912 [Taler] django-payments minor have not tried 2019-09-27 18:32 2019-09-27 18:32
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: update to the newest protocol version
Description: there's a new saleor update for django-payments, we should update 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:
5908 [libeufin] sandbox minor have not tried 2019-09-26 16:34 2019-09-26 16:34
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:  
Summary: sandbox should distinguish between client and server error
Description: The sandbox returns "400 Bad request" whenever a JSON fails to parse. Although this is almost always a client's fault, sometimes it might be the server's (therefore a 500 status code ought be returned.)
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:
5903 [Taler] auditor minor have not tried 2019-09-24 09:16 2019-09-26 10:32
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: incomprehensible error message "Did not update auditor DB: value existed"
Description: This happens on the automated build for taler-test@gv.

It probably has something to do with the exchange already being in the database of the auditor. However, it is not clear whether this represents an error condition that must cause the build to fail.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014957)
Christian Grothoff   
2019-09-25 13:14   
I'm not sure what is incomprehensible about the message, or how to improve it:

Somebody is running

$ taler-auditor-exchange

to *add* an exchange to the list of audited exchanges. That exchange is _already_ in the list of audited exchanges, and since we can have each exchange at most once (UNIQUE constraint), we return this message. The status code is set to "4", in contrast to other errors (1/2/3) that indicate failures for other reasons (failure to connect to DB, etc.). 0 is returned on success.

Now, I do agree that this is possibly OK for the buildbot (except maybe the DB should have been *reset* to test everything from scratch, but that's a question of what we intend to do/test/deploy here). So for a build of demo/test, I think it's OK to continue if the status code is 0 or 4, while for an integration test that did reset the DB we should check for 0 only.
(0014958)
Florian Dold   
2019-09-25 13:26   
(Last edited: 2019-09-25 13:42)
Ah. So the solution is to simply check for the respective exit status code I guess. Still, the error message should be improved. I was confused by "value existed". It's not even grammatically correct. What value?

Also, some programs write their own name before the error message. Otherwise, there is not enough context to diagnose where the problem even came from.

(Just try "cat --foobar" to see an example of this.)

How about something like:

"taler-auditor-exchange: The exchange '%s' is already audited by this auditor. Refusing to update auditor DB."

That's much more user-friendly.

(0014959)
Florian Dold   
2019-09-25 13:30   
(I'm not saying that we should prefix *all* outputs with the program name, but in this case, it would've added the required context to make the problem easier to diagnose.)
(0014963)
Christian Grothoff   
2019-09-25 17:43   
I guess then in this context we should simply switch to GNUNET_log() and log at the ERROR level. That'll give us all the information, and not create yet another special case.
(0014965)
Christian Grothoff   
2019-09-26 10:32   
5e859bae..3b3daa75 fixes the error message by using GNUNET_log () and changing the text a bit.
7d8b8ba..41e0280 documents the return codes of taler-auditor-exchange in docs.git.
3b3daa75..14c7e45e improves the error message in case removal fails.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5905 [GNUnet] other minor have not tried 2019-09-24 12:33 2019-09-24 12:33
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: infrastructure: add uncrustify git hook
Description: > we should also again strongly consider adding a hook that
> requires proper indentation upon commit for *certain* repos and
> *certain* paths (src/*). Uncrustify is now installed on both of our
> 'git' servers, so this just a matter of adding the hook in Gitolite.
>
> ng0: May I assume you'll add this to your plate?
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:
5898 [Taler] Web site(s) minor have not tried 2019-09-17 21:16 2019-09-17 21:31
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: improve buildbot jobs for www and stage
Description: At the very least the builds for the www and stage are not good.

> builds need to be 1.) idempotent 2.) ephemeral 3.) self-contained
as suggested and observed by myself and Devan.

Right now them not being any of this lead to yet another series of commits which not only on my computers is not fully
rendered as it should be.
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:
5763 [Taler] twister text N/A 2019-06-12 09:58 2019-09-17 21:02
Reporter: Christian Grothoff Platform: i7  
Assigned To: Marcello Stanisci OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Twister should have a Web site
Description: We should have a simple Web site (twister.taler.net) introducing Twister. The slides Marcello made a few months ago should be used as illustrations. The site should explain what Twister does and of course link to the code. I recently got a guy from F-Secure interested in Twister, and same for the ROS people. It's a shame that there is not even a simple page yet we can point these people to...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014538)
Christian Grothoff   
2019-06-12 09:59   
Oh, and ideally the Twister page should use the Taler i18n style.
(0014540)
Marcello Stanisci   
2019-06-13 02:00   
A very first version of this Website is available at: https://twister.wild.gv.taler.net/.

The code is versioned at twister.git/web, and it triggers the relevant BB worker upon pushes.

Improvements can be made from now on!
(0014541)
Marcello Stanisci   
2019-06-13 02:13   
Migrated to "twister.taler.net".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5872 [Taler] Web site(s) text have not tried 2019-09-03 17:29 2019-09-17 14:02
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: improve and verify texts on website
Description: From 0005287 : we probably should go together over all of the English text again to polish it a bit before giving it out for translation at scale.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014847)
ng0   
2019-09-03 22:09   
related: I recommend to turn off everything but English until we have a proper translation. The moment we merge master into stable and have no fix for the translations, it will leave a bad impression for those who get automatically redirected to their browser/OS set language sites.
(0014848)
ng0   
2019-09-03 22:11   
I'll go ahead and comment the sections next monday, unless you have reasons not to do this.
(0014849)
Christian Grothoff   
2019-09-04 07:00   
Sounds reasonable.
(0014856)
ng0   
2019-09-04 19:20   
From a usertest, on the front page: "What does this mean, 'Not a new currency!' ?"
(0014874)
rabassi   
2019-09-07 23:02   
> related: I recommend to turn off everything but English until we have a proper translation

I would like to second this. The French translation includes what looks like jokes about the members on the Team page. https://taler.net/fr/team.html

Better hide this for the moment!
(0014902)
ng0   
2019-09-14 12:41   
Those are not jokes but the translation is way off because of how much changed in the website (almost a rewrite of the texts and positions). We have the same issue on the gnunet website in some places.

Thanks for pointint this out.
(0014910)
ng0   
2019-09-17 14:02   
rabassi, grothoff: done, merging into stable now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5897 [GNUnet] GNS tweak have not tried 2019-09-17 09:52 2019-09-17 09:52
Reporter: schanzen 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.12.0  
Summary: Harmonize HKDF arguments for GNS block key derivations
Description: So currently it looks like this in the code:

PRK_h := HKDF-Extract ("key-derivation", x*P)
h := HKDF-Expand (PRK_h, l | "gns", 512 / 8)
d := h*x mod p
PRK_kiv := HKDF-Extract (d*P, l)
K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8)
IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)

In the case of PRK_kiv we use d*P as the "salt" value. For PRK_h we use a static public string.
I propose we modify the derivation of K and IV to:

PRK_h := HKDF-Extract ("key-derivation", x*P)
h := HKDF-Expand (PRK_h, l, 512 / 8) <== CHANGED: Removed "gns"
d := h*x mod p
PRK_k := HKDF-Extract ("gns-aes-ctx-key", d*P) <== CHANGED: Split into two PRKs and use string as salt and d*P as IKM
PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", d*P) <== CHANGED: Split into two PRKs and use string as salt and d*P as IKM
K := HKDF-Expand (PRK_k, l, 512 / 8) <== CHANGED: Use only l as info
IV := HKDF-Expand (PRK_iv, l, 256 / 8) <== CHANGED: Use only l as info

we _may_ also change the "key-derivation" string to something else, suggestions welcome.

This change will break backwards compatibility for GNS.
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:
5769 [Taler] merchant backend API (C) major always 2019-06-18 17:17 2019-09-16 22:14
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: memory leaks in test
Description: I've looked into this one, but it was not obvious where it came from. Could be a reference-counting issue for the json_t.

==84582== 835 (61 direct, 774 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 30
==84582== at 0x483577F: malloc (vg_replace_malloc.c:299)
==84582== by 0x4AF3AF8: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF9036: json_object_set_new_nocheck (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF50FD: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF5255: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF50E6: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF5395: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF5638: json_loadb (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4A56682: download_get_result (curl.c:467)
==84582== by 0x4A56AEA: GNUNET_CURL_perform2 (curl.c:542)
==84582== by 0x4A571B3: context_task (curl_reschedule.c:148)
==84582== by 0x4AC446D: GNUNET_SCHEDULER_do_work (scheduler.c:2132)
==84582==
==84582== 1,043 (80 direct, 963 indirect) bytes in 2 blocks are definitely lost in loss record 28 of 30
==84582== at 0x483577F: malloc (vg_replace_malloc.c:299)
==84582== by 0x4AF869A: json_array (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF51DC: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF50E6: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF5395: ??? (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4AF5638: json_loadb (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.1)
==84582== by 0x4A56682: download_get_result (curl.c:467)
==84582== by 0x4A56AEA: GNUNET_CURL_perform2 (curl.c:542)
==84582== by 0x4A571B3: context_task (curl_reschedule.c:148)
==84582== by 0x4AC446D: GNUNET_SCHEDULER_do_work (scheduler.c:2132)
==84582== by 0x4AC52F4: select_loop (scheduler.c:2431)
==84582== by 0x4ABF90E: GNUNET_SCHEDULER_run (scheduler.c:732)
Tags:
Steps To Reproduce: $ valgrind --trace-children=yes --leak-check=yes .libs/test_merchant_api_twisted
Additional Information:
System Description
Attached Files:
Notes
(0014908)
Christian Grothoff   
2019-09-16 21:52   
After re-running this ,it seems I was confused and the leak is in the test case, not in twister.
(0014909)
Christian Grothoff   
2019-09-16 22:13   
Fixed in 2772096..2a84699


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5889 [Taler] bank (demonstrator) crash have not tried 2019-09-11 00:05 2019-09-16 21:21
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Reject logic crashes for across-the-zero reimbursements.
Description: Say account A gave 10 KUDOS to account B with transaction T, and at some point B rejects transaction T *but* has only 4 KUDOS left on their account. The operation is legitimate if the bank allows their account to reach - for example - 10 KUDOS debit.

Nonetheless, the current logic would not accomplish this operation because it will try to subtract 10 KUDOS (T's amount) from 4 KUDOS (B's balance), and raise (unhandled) ValueError!

The solution would be for the subtraction to go debit until the allowed threshold, and only raise exception if this limit is surpassed.
Tags:
Steps To Reproduce:
Additional Information: Some logs.

Sep 10 23:40:12-997764 test-bank-api-with-(fake)bank-new-8179 DEBUG Running command `reject-1'
Sep 10 23:40:12-997785 test-bank-api-with-(fake)bank-new-8179 INFO Account 2 rejects deposit
Internal Server Error: /reject
Traceback (most recent call last):
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3.7/contextlib.py", line 74, in inner
    return func(*args, **kwds)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/views/decorators/http.py", line 40, in inner
    return func(request, *args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/views.py", line 561, in _decorator
    return view_func(request, user_account, *args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/views.py", line 807, in reject
    trans.credit_account.amount.subtract(trans.amount)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/amount.py", line 224, in subtract
    raise ValueError('self is lesser than amount to be subtracted')
ValueError: self is lesser than amount to be subtracted
2019-09-10 21:40:13,155 log ERROR Internal Server Error: /reject
Traceback (most recent call last):
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3.7/contextlib.py", line 74, in inner
    return func(*args, **kwds)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/django/views/decorators/http.py", line 40, in inner
    return func(request, *args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/views.py", line 561, in _decorator
    return view_func(request, user_account, *args, **kwargs)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/views.py", line 807, in reject
    trans.credit_account.amount.subtract(trans.amount)
  File "/home/marcello/.local/lib/python3.7/site-packages/talerbank/app/amount.py", line 224, in subtract
    raise ValueError('self is lesser than amount to be subtracted')
ValueError: self is lesser than amount to be subtracted
10/Sep/2019:21:40:12 +0000 HTTP/1.1 POST /reject HTTP/1.1 => 500
Attached Files:
Notes
(0014907)
Christian Grothoff   
2019-09-16 21:20   
First of all, I think in the case of a transaction being cancelled, it is OK if the usual account limits are being violated. So that check is not required.

c540308..4043cac should fix the crash itself, by properly handling negative balances. All tests still pass. However, as there is no way to 'reject' transactions in the Web interface, I did not test the actual logic in question. But it's pretty simple. Still, if you have an easy way to reproduce it, please give it a spin.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5874 [Taler] documentation text have not tried 2019-09-04 15:36 2019-09-16 09:54
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: taler error codes should be listed in the documentation
Description: Right now they're only listed in the source code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014906)
Christian Grothoff   
2019-09-16 09:54   
Are you proposing listing each error code in the respective API call where it can be generated, or a central list of all error codes?

I'm all for having a list of all error codes with the respective API call, but would (at this point) not favor basically a 1:1 duplication of the C enumeration in the documentation (we should eventually have a database with the error codes and generate the C header, Java, Python and other sources *and* documentation from that).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5871 [Taler] other feature have not tried 2019-09-02 16:48 2019-09-16 09:30
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: package android wallet and merchant terminal for F-Droid
Description: Especially the wallet has non-trivial dependencies.

F-Droid wants only source packages, so we have to build everything (including nodejs and the wallet web assembly) from scratch on a fresh debian VM.
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:
5282 [Taler] other tweak have not tried 2018-02-20 16:18 2019-09-16 09:30
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: style demo pages for better usability on mobile
Description: Now that Firefox on Android can use the Taler wallet, we should make sure that the demo is less awkward to use on mobile.

Currently the layout is not fit at all for smaller screens.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013556)
LUG   
2019-02-01 22:38   
I was trying to push changes addressing the mobile friendliness to feature/mobile-friendly but get the following git error:
"fatal: remote error: access denied or repository not exported: /landing.git

What's the contribution workflow here?
(0013557)
Christian Grothoff   
2019-02-02 10:49   
For now, please attach patches to the bug report; if we find you're a consistent contributor, we'll give you the ability to push changes directly to our main Git.
(0014349)
LUG   
2019-04-26 20:18   
I'm giving this another try.
@Florian, have you done something in that direction already that I should consider or do I start from the latest repo version?
(0014675)
ng0   
2019-07-15 15:43   
ack. Will work on this after GSoC.
(0014858)
ng0   
2019-09-04 20:12   
<code>
      <h2>Step 4: Check money flow</sup></h2>
</code>

is there any purpose for these seemingly misplaced sup tags I don't get immediately?
(0014859)
ng0   
2019-09-04 20:14   
I would just remove them, but there are too many of them to be random mistakes:

./demo/common/base.j2:81: <h2>Step 3: Pay</sup></h2>
./demo/common/base.j2:97: <h2>Step 4: Back office</sup></h2>
./demo/common/base.j2:113: <h2>Step 5: Reach out to us</sup></h2>
./demo/index.html.j2:84: <h2>Step 3: Pay</sup></h2>
./demo/index.html.j2:100: <h2>Step 4: Check money flow</sup></h2>
./demo/index.html.j2:112: <h2>Step 5: Merchant? Consult back-office</sup></h2>
./demo/index.html.j2:121: <h2>Step 6: Reach out to us</sup></h2>
(0014860)
ng0   
2019-09-04 20:20   
I have to ask because:

> The HTML Superscript element (<sup>) specifies inline text which is to be displayed as superscript for solely typographical reasons. Superscripts are usually rendered with a raised baseline using smaller text.

I assume it's leftover code unless you use this for something I have yet to find in the other code bases?
(0014861)
ng0   
2019-09-04 20:46   
sorry for the noise. 2 more git wrapper scripts later and finding 4767b306 in the repository: those are leftovers.
(0014866)
Florian Dold   
2019-09-05 16:39   
It's very likely some left-over markup from copy&pasting the headings. It can definitely be removed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5859 [Taler] other feature have not tried 2019-08-28 22:41 2019-09-16 09:29
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:  
Summary: back office lacks in user experience and functionality
Description: Currently it is not really clear at all what the back office does from just looking at it.

It also doesn't do basic stuff like show the contents of contract terms.
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:
5857 [Taler] documentation text have not tried 2019-08-27 22:39 2019-09-16 09:28
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:  
Summary: document various possibilities for withdraw flow
Description: In particular:
 * where does the interaction start
 * where does it end
 * what is the order? there are many possibilities, for example: Does the bank do authentication for a withdrawal operation before or after exchange selection and reserve creation in 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:
5887 [Taler] exchange minor have not tried 2019-09-10 12:56 2019-09-16 09:26
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Order tests under bank-lib/
Description: The codebase got bloated by a combination of tests, namely each test has multiple "flavours": "_with_fakebank", "_new", "_with_pybank", and possibly others. We should, first of all, discard the old-style tests (the ones not using libtalertesting), and then condensate all the logic in one source file that runs once against fakebank and once against pybank.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014882)
Marcello Stanisci   
2019-09-11 00:54   
(Last edited: 2019-09-11 00:55)
The condensation happened (ee6d7d75..e362c786), there is one file for non-twisted tests (test_bank_api_new.c) and one for twisted ones (test_bank_api_twisted.c). Now old tests need to be either discarded, or integrated into the new ones.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5537 [Taler] Web site(s) block always 2019-02-01 22:09 2019-09-16 09:25
Reporter: LUG Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Make fails for setting up landing page repo
Description: The last step of the setup instructions

  git submodule init
  git submodule update --remote
  AUTOMAKE="automake --foreign" autoreconf -fiv
  ./configure
  make

fails with the following error:

Making all in static
make[1]: Entering directory '/taler_landing/demo/static'
Making all in web-common
make[2]: Entering directory '/taler_landing/demo/static/web-common'
make[2]: *** No rule to make target 'logo-2015-medium.png', needed by 'all-am'. Stop.
make[2]: Leaving directory '/taler_landing/demo/static/web-common'
Makefile:295: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/taler_landing/demo/static'
Makefile:347: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
Tags:
Steps To Reproduce: git clone git://git.taler.net/landing.git
cd landing
git submodule init
git submodule update --remote
AUTOMAKE="automake --foreign" autoreconf -fiv
./configure
cd demo
make
Additional Information:
Attached Files:
Notes
(0013555)
LUG   
2019-02-01 22:26   
An attempt to fix this is available in the web-common repo in branch bugfix/remove-logo-from-makefile
(0013782)
Marcello Stanisci   
2019-02-14 19:41   
I can't see that branch, did you push it?
(0013783)
Marcello Stanisci   
2019-02-14 20:01   
2b9168365c39e23 should fix this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5649 [Taler] bank API (C) major have not tried 2019-03-15 17:35 2019-09-16 09:24
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: high OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Specify default value for 'start' from /history
Description: When 'start' is not given, the current API specs do not mention any difference in the logic when 'delta' is given positive or negative, they only say "delta youngest results will be returned".
It is also worth noting, that the current implementation does NOT ignore delta's sign, and makes 'start' default to UINT64_MAX.

We have two choices to make the situation clearer:

1) we _ignore_ delta's sign, and specify that *abs(delta)* youngest results are returned.
2) we do not ignore delta's sign, but rather make clear in the docs what the default for 'start' is.

Option 2) seems better, as it avoids exceptional cases in the interpretation of 'delta'.

On the other hand, this would impact (a little) the wirewatch, as it currently issues *all* the requests with a positive 'delta':

#1st request
/history?auth=basic&delta=1024&direction=both

#2nd to infinite-th request
/history?auth=basic&delta=1024&direction=both&start=<latest_row>

So with option 2) put in place, the two patterns above would become:

#1st request, note the negative sign of 'delta'.
/history?auth=basic&delta=-1024&direction=credit

#2nd to infinite-th request (no change here).
/history?auth=basic&delta=1024&direction=credit&start=<latest_row>

As for the default value of 'start', UINT64_MAX seems a better choice than 0 or -1 for the following reasons: since the result having row_id == 'start' is excluded from the results, by picking zero as the default we would surely exclude row_id == 0 for some databases, whereas picking -1 can easily confuse the reader. Clearly, also row_id == UINT64_MAX can be excluded from the result, but this is very unlikely since databases should never reach the point where all the rows got occupied.
Tags:
Steps To Reproduce:
Additional Information: The current situation puts in danger the wirewatch, since by using a _positive_ delta and omitting the 'start' value, it asks for row_ids bigger the UINT64_MAX!

The reason why it _seems_ to work right now is that the exchanges' databases - both from Tripwire and on devs' machines - usually have old entries about previous wire transfers, therefore the wirewatch _tends_ to put a 'start' parameter in the /history requests.
Attached Files:
Notes
(0014218)
Marcello Stanisci   
2019-03-18 19:32   
This commit: 59075946de79276104c1, adapts the wirewatch behaviour to switch the 'delta' sign after the very first /history request.
(0014219)
Marcello Stanisci   
2019-03-18 19:37   
API documentation was _already_ matching option 2) in the description; sorry, but https://docs.taler.net isn't updating its content due to 0005490!

I'm closing, as all got addressed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5636 [Taler] bank (demonstrator) minor have not tried 2019-03-07 23:20 2019-09-16 09:24
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Reduce code for /history.
Description: Right now, when a /history request arrives, the bank goes through _three_ functions that have all almost the same signature.
There must be the way to have only one function with that signature, and either use the other as "helpers" or just incorporate
their logic into the unique "mother" function.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014221)
Marcello Stanisci   
2019-03-20 17:14   
Fixed in be54c58..105f09c.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5643 [Taler] other tweak have not tried 2019-03-12 14:20 2019-09-16 09:24
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Survey site has user UNfriendly date shown.
Description: The /survey-stats page from the survey site shows the "expiration date" field with the "/Date(xxx)/" format. That should be shown in a prettier format.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014222)
Marcello Stanisci   
2019-03-20 17:47   
d71b77a addresses this; testing needed.
(0014223)
Marcello Stanisci   
2019-03-20 22:56   
Tested (and fixed!) at: 49c3ca5. Closing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5697 [Taler] documentation minor have not tried 2019-04-19 17:40 2019-09-16 09:24
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Polishnig onboard.texi.
Description: The file deployment/doc/onboard.texi has been partially obsoleted by readme.md from gv-maintenance.git. It should be seen whether this file should be simply polished, or entirely disposed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014304)
Marcello Stanisci   
2019-04-19 17:49   
first cleaning: 42a3311..ddcfb1b
(0014310)
Christian Grothoff   
2019-04-20 12:08   
I generally believe the onboarding.texi should be kept. It should have a much broader scope than just gv-maintenance.git, which is about system administration. Onboarding is about "everything" a new dev should know (from Git write access to Bugtracking to CI to coding conventions, etc. etc.). Naturally details about system administration might be better kept in the gv-maintenance.git readme.
(0014327)
Marcello Stanisci   
2019-04-22 15:58   
Okay for all, but 'CI' needs some clarification: this aspect has the sysadmin side (accounting for which users are running which workers, or where in the system some worker outputs some files, etc.) and the user side (like letting the user know where the BB Website is, or what happens after they push their changes, etc.).

We should agree that the first part goes in gv-maintenance.git, and the second goes in onboarding.texi at deployment.git.
(0014329)
Marcello Stanisci   
2019-04-22 18:24   
In 875fdb95058e0..c42dbea3cda4a2ab, I reviewed and polished the per-user setup environments. Actually, we should also agree about keeping this feature around or not.
(0014330)
Marcello Stanisci   
2019-04-22 18:30   
Commit 99a3eee..5536720 finishes polishing the current content, and so this can be closed. New sections, like about Git / Bugtracking / Buidlbot for *users* needs to be added.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5700 [Taler] documentation minor have not tried 2019-04-22 20:21 2019-09-16 09:24
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: More sections needed at onboarding.texi
Description: This document, from deployment.git, needs at least the following sections:

* Git, explain where all the Taler code can be downloaded.
* CI, explain how we do and how to monitor CI.
* Bugtracker, explain how we track bugs.

More ideas are welcome.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014333)
Marcello Stanisci   
2019-04-22 21:10   
f2be0b3..11d5545


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5703 [Taler] bank (demonstrator) minor have not tried 2019-04-24 11:30 2019-09-16 09:24
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: tsc conditional block in web-common produces bad Makefile if condition is false, leading to bank build failure
Description: It is not clear if tsc (and web-common) is a hard dependency for bank, or if some conditional
exception can be applied.

See also #5702
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014339)
ng0   
2019-04-24 13:41   
However it could be that I have it wrong, because it's been too long since I installed ntsc (https://www.npmjs.com/package/ntsc).

tsc now reads:

> Use ntypescript https://www.npmjs.com/package/ntypescript as it follows a simple original -> noriginal name transform for require as well as globals tsc & tsserver.
(0014377)
ng0   
2019-05-02 16:03   
As per Email of 2019-05-02, this is a no-issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5714 [Taler] bank (demonstrator) minor have not tried 2019-05-07 18:52 2019-09-16 09:24
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: upgrade to Django 2+
Description: Django 2 is years old now, there is no reason to stick with 1.9
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014384)
Marcello Stanisci   
2019-05-10 18:24   
4f1f7590879789d895 does.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5717 [Taler] bank (demonstrator) minor have not tried 2019-05-08 07:21 2019-09-16 09:24
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: transaction history is shown as empty
Description: Despite withdrawal working, the bank shows an empty transaction history. The signup bonus is also missing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014396)
Marcello Stanisci   
2019-05-14 22:43   
hotfixed here:

801d703..3ac4046 stable -> stable


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5725 [Taler] exchange minor have not tried 2019-05-15 19:21 2019-09-16 09:23
Reporter: Marcello Stanisci Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: same header included twice
Description: After setting the COMPRESS_BODIES symbol to 1, the "Content-Encoding: deflate" header line gets included twice in the request.

Observed in the /reserve/withdraw request.
Tags:
Steps To Reproduce: Run any test case that requests "/reserve/withdraw" with COMPRESS_BODIES set to 1.
Additional Information:
Attached Files:
Notes
(0014404)
Marcello Stanisci   
2019-05-16 18:04   
95933156a6d477460a20 fixes it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5727 [Taler] bank (demonstrator) minor have not tried 2019-05-16 13:23 2019-09-16 09:23
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: DEBIAN_PIP3_SYSTEM should also be passed in the env.
Description: DEBIAN_PIP3_SYSTEM now is only a symbol replaced by autoconf with "--system" or "". However, on newer systems this flag should not be set even if autoconf does. Therefore, we should change the configure script to use the environment variable DEBIAN_PIP3_SYSTEM whenever this one was defined by the user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014415)
Marcello Stanisci   
2019-05-20 17:55   
was implemented here: d406255efad0988f04b1.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5726 [Taler] twister minor have not tried 2019-05-16 12:00 2019-09-16 09:23
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Compression needs tests
Description: In particular, the test should POST a compressed JSON and check that decompression and parsing both worked.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014416)
Marcello Stanisci   
2019-05-20 18:43   
made here: 65bd48c..7d9642f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5720 [Taler] bank (demonstrator) minor have not tried 2019-05-12 22:23 2019-09-16 09:23
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: bank should support compressed POST request bodies
Description: AFAIK this is not supported natively by Django.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014422)
Marcello Stanisci   
2019-05-21 13:33   
implemented here 12f2db66dc43d66a.
(0014423)
Marcello Stanisci   
2019-05-21 13:42   
tested here: 0a02bfc..a670306; so far was only tested via exchange's bank-lib.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5728 [Taler] deployment and operations minor have not tried 2019-05-20 13:53 2019-09-16 09:23
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Dump log file from failing test case.
Description: Whenever a Buildbot build fails for a C component, the Web console prints just the libtool output, so it is not possible
to understand what the specific failure was. Instead, it would be great to have the .log from the failing test case printed
somehow in the Web console.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014417)
Marcello Stanisci   
2019-05-20 18:49   
https://stackoverflow.com/questions/20961959/autotools-output-test-suite-log-contents-on-test-failure
(0014419)
Christian Grothoff   
2019-05-20 23:21   
Why don't you just add an extra buildbot command to

$ cat `find * -name "*.log"`

No need to modify what we usually do, and users usually wouldn't want even more output.
(0014434)
Marcello Stanisci   
2019-05-23 16:36   
I did something similar. When the test fails, a "dumper" (see [1]) script starts looking for failed tests and dumps the respective .log whenever it finds one. Currently testing it..

[1] https://git.taler.net/deployment.git/tree/taler-build/cat_failed.sh
(0014435)
Marcello Stanisci   
2019-05-23 17:45   
It functions, and here's how it looks:
https://buildbot.wild.gv.taler.net/#/builders/1/builds/14

Can be closed now.
(0014436)
Marcello Stanisci   
2019-05-23 17:45   
99ca39b38bf7cc12e6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5718 [Taler] mechant backend minor have not tried 2019-05-08 11:52 2019-09-16 09:23
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Implement body compression
Description: The merchant should compress data that it sends via POST and PUT.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014437)
Marcello Stanisci   
2019-05-24 16:39   
implemented here: 55b6620.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5732 [Taler] mechant backend minor have not tried 2019-05-24 19:13 2019-09-16 09:22
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: refund sometimes fails with insufficient logging
Description: This *might* happen when the refund+withdraw fees are too high, and the customer effectively wouldn't get any money back. That's just a wild guess though.

May 24 19:00:09-304538 taler-merchant-httpd-317(Y4Z523NJH7HSB560YTQD0P5808) INFO Handling request (POST) for URL '/refund'
May 24 19:00:09-304602 taler-merchant-httpd-317(Y4Z523NJH7HSB560YTQD0P5808) INFO Handling request (POST) for URL '/refund'
May 24 19:00:09-304627 taler-merchant-httpd-317(Y4Z523NJH7HSB560YTQD0P5808) INFO Handling request (POST) for URL '/refund'
May 24 19:00:09-306314 taler-merchant-httpd-317(Y4Z523NJH7HSB560YTQD0P5808) ERROR increase refund returned 1
May 24 19:00:09-344120 taler-merchant-httpd-317(Y4Z523NJH7HSB560YTQD0P5808) INFO Finished handling request for `/refund' with status 0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014446)
Marcello Stanisci   
2019-05-27 15:54   
3f6d32f..3e295bc fixes this. The real problem was the loglevel set as ERROR; now put as DEBUG.
(0014447)
Marcello Stanisci   
2019-05-27 15:58   
In fact, that "ERROR" line is telling that the refund got accepted.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5723 [Taler] deployment and operations minor always 2019-05-13 21:28 2019-09-16 09:22
Reporter: LUG Platform: virtual machine  
Assigned To: LUG OS: xUbuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Undocumented environment dependencies for bootstrap-standalone deployment
Description: Since setting up the repos individually didn't work out for me, I wanted to follow the developers' advice to run a system wide setup from the official deployment repo, following the onboarding guide:
https://docs.taler.net/onboarding/pdf/onboarding.pdf

When running "./deployment/bootstrap-standalone" I get the following error:
  fatal: repository '/var/git/twister.git' does not exist

Looking into the bootstrap-standalone script it looks like numerous repos from git.taler.net are required to be present in /var/git/
I'd like to suggest adding this information as a requirement to the onboarding documentation.

Also, the package libpq-dev seemed to be needed as well to support the pg_config call in bootstrap-standalone:14
Tags:
Steps To Reproduce: - Install clean xUbuntu 18.04
- clone deployment repo into ~/deployment
- ./deployment/bootstrap-standalone
Additional Information:
Attached Files:
Notes
(0014392)
LUG   
2019-05-13 21:30   
(Last edited: 2019-05-13 21:33)
Alternatively we could adjust the standalone deployment script to clone the relevant repos from git.taler.net instead of /var/git
Let me know what you prefer and I'm happy to help however I can.

(0014393)
LUG   
2019-05-13 21:37   
And "libpq-dev" doesn't seem to be enough. Installing the "postgresql" server package as a whole seems necessary.
(0014394)
LUG   
2019-05-13 21:42   
When I follow the setup to:
# Then we need to install GNUnet beforehand, as it provides the ’ARM’# utility that is used to start the database service.
$ cd deployment/taler-arm/
$ make gnunet-stamp

I get "make: *** No rule to make target 'gnunet-stamp'. Stop."

The content of deployment/taler-arm/ is:
-rwxrwx--- 1 user user 656 Mai 13 21:15 arm.conf
-rwxrwx--- 1 user user 630 Mai 13 21:15 defaults.conf
-rwxrwx--- 1 user user 116 Mai 13 21:15 taler-aggregator.conf
-rwxrwx--- 1 user user 104 Mai 13 21:15 taler-auditor.conf
-rwxrwx--- 1 user user 150 Mai 13 21:15 taler-backoffice.conf
-rwxrwx--- 1 user user 125 Mai 13 21:15 taler-blog.conf
-rwxrwx--- 1 user user 127 Mai 13 21:15 taler-demobank.conf
-rwxrwx--- 1 user user 140 Mai 13 21:15 taler-donations.conf
-rwxrwx--- 1 user user 107 Mai 13 21:15 taler-exchange.conf
-rwxrwx--- 1 user user 130 Mai 13 21:15 taler-exchange-wirewatch.conf
-rwxrwx--- 1 user user 107 Mai 13 21:15 taler-merchant.conf
-rwxrwx--- 1 user user 134 Mai 13 21:15 taler-playground.conf
-rwxrwx--- 1 user user 192 Mai 13 21:15 taler-postgres-standalone.conf
-rwxrwx--- 1 user user 131 Mai 13 21:15 taler-survey.conf
(0014405)
Christian Grothoff   
2019-05-19 02:00   
I fixed this:
  When running "./deployment/bootstrap-standalone" I get the following error:
  fatal: repository '/var/git/twister.git' does not exist

The old script would have only worked on git.taler.net as it assumed that the master Git repositories were one the same machine. I've now changed the script to clone from remote.
(0014406)
Christian Grothoff   
2019-05-19 02:03   
libpq-dev is enough to build the code, of course a Postgres server is required "somewhere", but at least in theory it doesn't have to run on the same physical machine.
(0014407)
Christian Grothoff   
2019-05-19 02:03   
On the "make gnunet-stamp" bug, I am confused: the Makefile in that directory contains that target for me. Did you clone the deployment.git from git.taler.net?
(0014408)
LUG   
2019-05-19 02:11   
Thanks for the git repo fix.

True, the database server doesn' t need to run on the same machine as well. In the context of the bootstrap-standalone deployment I understood that it requires a Postgrees server on the same machine though, right? If I didn' t misunderstand, it might be nice to add a matching hint to the onboarding documentation.

Thanks for trying this locally yourself, I'll try to replicate the issue again and provide more detailed information.
(0014409)
Marcello Stanisci   
2019-05-19 02:44   
LUG, that gnunet-stamp is to be mentioned inside the *taler-build* directory, and NOT inside taler-arm. Like this:

$ cd deployment/taler-build
$ make gnunet-stamp
(0014410)
LUG   
2019-05-19 12:55   
(Last edited: 2019-05-19 14:56)
Thanks Marcello, there are make recipes in that directory. Would you then be so kind to correct this directory in the onboarding document?

And while that new directory enables me to run make, I needed to satisfy these additional dependencies:
autoconf autopoint libtool gnutls-dev texinfo libgcrypt20-dev libunistring-dev libjansson-dev

And run
$ cd ~/libmicrohttpd
$ autoreconf -fi

Then I can successfully run:
$ make gnunet-stamp
$ taler-deployment-arm -s
$ taler-deployment-arm -i taler-postgres-standalone

For running "taler-deployment-config-generate" I first needed to:
$ export LC_ALL=C.UTF-8
$ export LANG=C.UTF-8

(0014411)
LUG   
2019-05-19 14:56   
(Last edited: 2019-05-19 16:53)
To get "taler-deployment-build" to work until the error below, the following steps were necessary:

Install missing python dependencies
$ apt install python3-pip python3-click python3-babel python3-jinja2 python3-jsmin python3-requests

Install nodejs package manager yarn (following https://yarnpkg.com/en/docs/install#debian-stable)
$ apt install apt-transport-https
$ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
$ echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
$ apt update
$ apt install yarn

Install recent version of nodejs (following https://downloads.nodesource.com/)
$ curl -sL http://nsolid-deb.nodesource.com/nsolid_setup_3.x | bash -
$ apt -y install nsolid-dubnium nsolid-console

$ taler-deployment-build

After a lot of successful stuff, it comes to "deployment/taler-build/update_exchange.sh" where the following line causes an error
$ ./configure CFLAGS='-ggdb -O0' --with-libgnurl=$HOME/local --with-microhttpd=$HOME/local --with-twister=$HOME/local --prefix=$HOME/local --with-gnunet=$HOME/local --enable-logging=verbose
./configure: line 17352: ac_fn_c_check_decl: command not found
configure: error:
***
*** You need libmicrohttpd >= 0.9.39 to build this program.
***
Makefile:40: recipe for target 'exchange-stamp' failed
make: *** [exchange-stamp] Error 1

And I have "$HOME/local/lib/libmicrohttpd.so.12.50.0"

(0014412)
Marcello Stanisci   
2019-05-19 23:26   
re 14410:

LUG, that directory looks already good on the manual, see here:
https://git.taler.net/deployment.git/tree/doc/onboarding.texi#n127

Then, as for your other observations: you are basically saying that the onboarding manual
doesn't tutor the user along the installation of the various components (exchange / bank / ..)
and dependencies (GNUnet / libmicrohttd / ..).

The point is that we already have such instructions for all the components, under each
component's repository; you might want to have a look under "doc/" directories, or READMEs,
or just find ".texi" files and compile them.

And to tell the whole story, the onboarding manual was meant to onboard sysadmins at
our servers, and not as a tutorial to build Taler on arbitrary machines. In fact, it forces the
machine to have a specific layout of directories, disallowing the reader to freely choose their
"--prefix"(es). That said, feel free to run it where you want!
(0014413)
Marcello Stanisci   
2019-05-20 14:07   
Here: 4de683a..e468ab0, I put a note that invites the reader to go through each component's building instructions.

If you think this is solved, please either remove the 'block' status or just close; thanks!
(0014418)
LUG   
2019-05-20 20:44   
(Last edited: 2019-05-20 20:54)
Marcello, thanks for your input and the explanations. If that is the intention of the onboarding document I missed its use case, indeed.
What would you recommend for repos like "donations" or "survey" where there seems to be neither README nor doc/ directory?

The directory on the manual source is correct but the compiled version that is linked from the website is still outdated: https://docs.taler.net/onboarding/pdf/onboarding.pdf
Is there maybe a way to build that linked document automatically to ensure that it's always up to date?

Thanks for your support with enabling me.

(0014420)
Marcello Stanisci   
2019-05-21 00:38   
Thanks for reporting!

donations (27e5a47), blog (2fd1669), and survey (d382fb1) got all updated to contain a README file.
However, please note that those three repos are not officially part of Taler, but are just examples.

Then, the docs building automation was already put in place, except that for deployment.git was never
started! Now it SHOULD be fixed (here, at deployment.git: 82b748694d), but I can't test it right now because
Gitolite doesn't update its repository upon pushes. I filed a new bug for this: 0005729.
(0014424)
LUG   
2019-05-21 13:51   
Much appreciated! I'll close this issue and work my way through the repos to hopefully soon provide a consistent update in terms of 0005704 to all demo relevant repos.
(0014429)
Marcello Stanisci   
2019-05-22 10:47   
As for the docs automated building: please consider going to docs.wild.gv.taler.net now.
(0014433)
LUG   
2019-05-22 17:44   
It seems that I can't. When opening https://docs.wild.gv.taler.net/ I get a certificate error that I can't ignore due to HTTP Strict Transport Security (HSTS).
(0014462)
Marcello Stanisci   
2019-05-30 14:29   
Hello LUG.

The whole site got migrated to: https://docs.taler.net/

Please try there (and reopen if need be)!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4938 [Taler] deployment and operations tweak have not tried 2017-03-06 00:58 2019-09-16 09:22
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: low OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: add buildbot task to run html-tidy on our webpages
Description: Preferably a very recent version of http://www.html-tidy.org/ should be run on at least www.taler.net and stage.taler.net.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014466)
Marcello Stanisci   
2019-05-30 15:01   
Is this still valid?
(0014467)
Marcello Stanisci   
2019-05-30 16:22   
Well, here's added for the 3 sites (www/stage/docs-landing): 4d81c44.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5741 [Taler] deployment and operations minor have not tried 2019-05-29 17:35 2019-09-16 09:22
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: auditor reports should not be in the top-level $HOME of the demo/test account
Description: Please fix the configuration for this in deployment.git and apply this to test-{green,blue}.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014459)
Marcello Stanisci   
2019-05-29 21:20   
fixed here, and tested with forced builds: 4883a76. Next build is at 6AM; if it behaves well, I'll close this.
(0014460)
Marcello Stanisci   
2019-05-30 09:38   
Made this (4883a76..e406458) to remove the .txt(s) from $HOME, but the PDF got placed under "shared-data/". Closing.
(0014473)
Florian Dold   
2019-05-31 09:53   
I'm still seeing audit reports as of now on test-green:

audit_report.2019-05-31.txt
...
(0014474)
Marcello Stanisci   
2019-05-31 10:27   
(Last edited: 2019-05-31 10:28)
The .txt from the 30 may are due to a bug that made .txt not deleted (fixed here: e4064589a77bbe). The txt/tex from the 31 may are there because the builder failed this morning, and so the script didn't reach the point where it actually deletes those.

See here: https://buildbot.taler.net/#/builders/2/builds/28

That's odd because the PDF transformation was working fine unitil yesterday, and there isn't even any change in the JSON ouput of the taler-auditor command. Well, I've patched it anyway: 4d81c44..03d1186 (@ deployment.git).

Ah, 0005742 is there to track this problem!

(0014475)
Marcello Stanisci   
2019-05-31 10:32   
Also to be noted: strictly speaking, those are not reports, but just some intermediate data that is used to produce the final report in PDF. This one then gets moved under ~/shared-data/auditor/reports, and served at https://auditor.test.taler.net/reports


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5713 [Taler] deployment and operations minor have not tried 2019-05-07 18:41 2019-09-16 09:21
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: database setup should be documented and automated
Description: Right not it looks like it's done manually for {demo,test}-{blue,green}. Nothing is documented.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014509)
Marcello Stanisci   
2019-06-05 20:01   
(Last edited: 2019-06-05 20:02)
1fb101b extends the README explaining the DB layout, and add a "db.sh" script (into gv-maintenance.git) that automates db/roles creation.

(0014510)
Marcello Stanisci   
2019-06-05 20:13   
Just a side note: the script was tested locally on my laptop so as to not ruin the current layout on Gv.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4643 [Taler] deployment and operations tweak have not tried 2016-09-06 13:25 2019-09-16 09:21
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: exchange sometimes runs into permission problems with keys
Description: Since
 taler-exchange-keyup creates keys with "rw-------", we run into
problems when {test,demo}-blue creates keys and {test,demo}-green wants
to read them.

Either taler-exchange-keyup should learn an option to create keys with
group permissions, or we should have some wrapper script to fix up
permission afterwards.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014518)
Marcello Stanisci   
2019-06-07 15:51   
Fixed @ 0c3c165 @ deployment.git

The keyup wrapper script chmods to g+rwx ALL the shared-data/ directory.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5760 [Taler] documentation minor have not tried 2019-06-10 14:01 2019-09-16 09:21
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: mention taler-deployment-hier in the manuals
Description: The manual that explains how to set a test/demo environment up can now introduce "taler-deployment-hier".

At the same time, it can be more appropriate to move such content from gv-maintenance.git to deployment.git/doc/, since those operations can be done without root privileges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014527)
Marcello Stanisci   
2019-06-10 15:32   
deployment.git, extended at: baa8833
gv-maintenance.git, cleaned at: 6422137


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5706 [Taler] merchant frontend (donations) minor have not tried 2019-04-27 19:38 2019-09-16 09:20
Reporter: LUG Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Add README to donations repo
Description: It seems to me that installing the talerdonations package and running taler-merchant-donation could work stand-alone but I'm at least missing the expected config files[1, 2], along with a clue about how they should look.
What do you think about adding a README to the donations repo where the basic requirements for running the dontaion frontend are listed?

[1] can't read config directory '/usr/local/share/taler/config.d'
[2] Configuration file (/home/lukas/.config/taler.conf) not found
Tags:
Steps To Reproduce: $ pip install -e .
Obtaining file:///home/lukas/Workspace/taler/donations
Collecting Flask>=0.10 (from talerdonations==0.0) [...]
Collecting itsdangerous>=0.24 (from Flask>=0.10->talerdonations==0.0) [...]
Collecting click>=5.1 (from Flask>=0.10->talerdonations==0.0) [...]
Collecting Werkzeug>=0.14 (from Flask>=0.10->talerdonations==0.0) [...]
Collecting Jinja2>=2.10 (from Flask>=0.10->talerdonations==0.0) [...]
Collecting MarkupSafe>=0.23 (from Jinja2>=2.10->Flask>=0.10->talerdonations==0.0) [...]
Installing collected packages: itsdangerous, click, Werkzeug, MarkupSafe, Jinja2, Flask, talerdonations
  Running setup.py develop for talerdonations
Successfully installed Flask-1.0.2 Jinja2-2.10.1 MarkupSafe-1.1.1 Werkzeug-0.15.2 click-7.0 itsdangerous-1.1.0 talerdonations

$ taler-merchant-donations
can't read config directory '/usr/local/share/taler/config.d'
Configuration file (/home/lukas/.config/taler.conf) not found
Additional Information:
Attached Files:
Notes
(0014358)
LUG   
2019-04-27 19:58   
I'm also trying to go via make devinstall, but fail to set it up in userspace (i.e. not in /usr/local/ but somewhere in /home/user/ and in an isolated python environment instead of with system python).
(0014359)
LUG   
2019-04-27 20:40   
Found https://docs.taler.net/exchange/html/taler-exchange.html#Configuration-format as well as https://docs.taler.net/backoffice/html/manual.html and will try if I can come up with a README suggestion for the donations repo. Please feel free to interrupt me in case running this stand alone doesn't make sense in the big picture, even for development.
(0014448)
Marcello Stanisci   
2019-05-27 17:43   
Starting from, 0d9da52dc5c05524be8c5adf84d, the donations repo does have a README file.
(0014449)
Marcello Stanisci   
2019-05-27 17:44   
Starting from: 62b549f47e86634b8e, donations does provide a default config file under "config.d".
(0014450)
Marcello Stanisci   
2019-05-27 18:46   
For the problem reported by [2], we can't really fix it, as this means that the user didn't pass neither a '-c' option nor had a valid default ~/.config/taler.conf installed.

Please reopen if you notice additional problems in the installation!
(0014525)
LUG   
2019-06-10 14:13   
Thanks for your additions.
Could it be that the Python packages "uwsgi" and "requests" are still missing from the setup instructions or at least the configure checks?
I had to "pip3 install uwsgi requests" to make the taler-merchant-donations run.
(0014528)
Marcello Stanisci   
2019-06-10 20:25   
This is all in all possible. I've added those missing dependencies into the setup: dd83568..f09cb42.
(0014529)
Marcello Stanisci   
2019-06-10 21:00   
Closing. Please reopen if need be.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5738 [Taler] deployment and operations minor have not tried 2019-05-29 14:54 2019-09-16 09:20
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: twister should be integrated in test (and later demo)
Description: This is mainly for the chaos_probability option. Maybe we'll also use it for other kind of integration tests on a "live system".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014533)
Marcello Stanisci   
2019-06-11 17:34   
(Last edited: 2019-06-11 17:35)
This commit (3cbd72f @ deployment.git) ends the Twister's deployment into 'test'.

Note that now we have 3 config files: the main one (taler.conf), that contains the twisted entries to proxy a merchant backend; then twister-{bank,exchange}.conf to proxy requests to bank and exchange.

(0014534)
Marcello Stanisci   
2019-06-11 17:37   
I am closing for now, as a Twisted 'demo' shall wait non obvious time.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5757 [Taler] mechant backend minor have not tried 2019-06-08 14:39 2019-09-16 09:20
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: permissions on wire details JSON.
Description: The merchant creates on the fly the JSON file accounted in:

[account-x]
wire_response = /path/to/file.json

We need another config option to set permissions on this file, in order to make blue/green deployments easier.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014532)
Marcello Stanisci   
2019-06-11 16:59   
In the same way, also the ".priv"(s) regarding the various merchant instances must get tunable permissions. Rigth now, they set 600 therefore when the other color tries to read them it gets "permission denied".
(0014535)
Marcello Stanisci   
2019-06-11 22:10   
(Last edited: 2019-06-11 22:11)
Permissions on keys are now set by taler-deployment-keyup, which is also responsible for copying them over (9d527fb6ba39669aebc3).

Permissions for the wire format file are instead (optionally) taken from the configuration (45e9d2bc921325cd2d9089).



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5765 [Taler] deployment and operations minor have not tried 2019-06-15 11:38 2019-09-16 09:20
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Double slash when Twister is accessed via "X-Taler-Deployment-Color: <color>".
Description: When the Twister is accessed via "X-Taler-Deployment-Color: <color>", it adds a second slash to the original, causing the proxied service to reply with a "not found" response.
Tags:
Steps To Reproduce: curl -H "Authorization: ApiKey sandbox" -H "X-Taler-Deployment-Color: <color>" https://twister-backend.wild.gv.taler.net/

<color>: blue / green.
Additional Information: The addressed merchant backend will have logs looking like the following:

Jun 15 11:27:30-680708 taler-merchant-httpd-9848(V4JW5D9J5D0QW9MSWBB12EN21C) INFO Handling request (GET) for URL '//'
Jun 15 11:36:22-253211 taler-merchant-httpd-9848(JJGTZKKG4W0VFPVSCPQCY3BW98) INFO Handling request (GET) for URL '//'
Attached Files:
Notes
(0014552)
Marcello Stanisci   
2019-06-15 11:39   
This is also behind such failure:

https://buildbot.taler.net/#/builders/1/builds/306/steps/6/logs/stdio
(0014558)
Marcello Stanisci   
2019-06-15 19:45   
Never append slash after "[twister]/destination_base_url" !!

Fixed here 2545ddd (deployment.git)
(0014559)
Marcello Stanisci   
2019-06-15 21:13   
Tested with a few blue/green rounds from BB.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4563 [Taler] deployment and operations minor have not tried 2016-06-07 11:29 2019-09-16 09:19
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: deployment does not fix versions for GNUnet, MHD; potential to break demo
Description: While we're always using the master branch in test and the stable branch in demo for taler components, GNUnet and MHD is always compiled from master, even in demo@taler.net.

This means that demo breaks once we re-enable automatic builds and GNUnet makes a backwards incompatible crypto change.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010878)
Christian Grothoff   
2016-06-08 22:09   
Best method I can think of addressing this is to really just make a GNUnet release "soon" and then always require that Taler releases (& demo) only depends on released GNUnet versions, possibly forcing us to make more frequent GNUnet releases, which might not be a bad thing anyway.
(0014570)
Marcello Stanisci   
2019-06-24 10:36   
(Last edited: 2019-06-24 10:36)
Demo shall never break because (1) it is always installed from the latest release that depends on GNUnet/MHD masters, and (2) once installed it stays untouched (including GNUnet/MHD!) forever.

Will close this.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5204 [Taler] other feature have not tried 2017-12-09 02:58 2019-09-16 09:19
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: experiment with opening wallet page in new tab to avoid white pages and flickering
Description: The merchant can then simply show a page with

"Waiting for payment to be processed with GNU Taler. If no wallet page page appeared yet, click HERE."

The "click HERE" link should never be necessary, but is useful for users who accidentally close the wallet page, end up back on the merchant page and don't know how to refresh pages.

We also need to track if the user closed the original page, so we can navigate there if necessary after the payment is done.

This has some significant advantages:
1) no flickering or reloading that is noticeable by the user
2) if using JavaScript payments in a stateful app (such as a game), we can pay without destroying the application state
3) it's forward-compatible with the W3C payment request API, where the wallet would be displayed in a browser-secured overlay that the merchant page can't tamper with.

Also from my experience it seems like other payment methods are already doing this, so it's not new or unexpected for users.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012639)
Christian Grothoff   
2017-12-09 10:30   
I don't really like the idea. If we want to minimize the flickering, maybe we can simply change the 402 body that is being returned instead? From setting it to invisible initially (would the Wallet CSS magic for that?) to simply artificially delaying the transmission of the body by 100ms, I see quite a few options.

Tabs are IMO bad as they ought to imply a context switch. Some users have hundreds of tabs open, and they may no longer be able to associate the payment tab with the original page. It also destroys the ability to navigate 'back'.

Finally, if (3) actually happens and works nicely, then the whole tab business is just a distraction, as in that case I suspect we might just implement (3) directly without the tab-method as an intermediate option, and we get (2) solved that way as well. But: it might be OK to have the tab as an option to address (2) today, i.e. if the merchant explicitly specifies "use tab" to avoid the state destruction issue. Still, don't see this as a priority today.
(0012644)
Florian Dold   
2017-12-09 13:50   
The wallet is already using CSS magic to make the page blank. I've come to the conclusion that this is sometimes the worse experience though: If /pay takes a long time, the user just has to stare at a blank page. When opening the payment dialog in a new tab, we can make wait-states more friendly to the user.

We could have a less jarring 402 page though, other than blanking it out via the wallet or showing an ugly fallback credit card form for a second.

Regarding context switching: I'm one of these users with many tabs open ;-) I had this concern too at first, but then when the payment succeeds the wallet *knows* which tab triggered it, and can simply focus on that after payment, if still open.

Regarding the back button: Easily fixed using the standard history API, the wallet page creates an dummy navigation, and when the back button (or other means of back-navigation) is used then (1) the wallet page closes and (2) the merchant page is navigated back.

I don't think the merchant should decide between "new tab" and "same page". By making the merchant assume the payment happens in a new tab (or Payment Request API overlay), we can always provide the user with the best experience depending on their device or browser (on a mobile device, accepting the payment might even happen in another app and not in the browser).

(Some background: With Stripe payments, the merchant embeds some iframe from Stripe. But on mobile, Stripe always opens their dialog in a new tab and refuses to show the iframe, since many merchants have really bad mobile sites. So it can make sense to take choice away from the merchant for better UX.)

So in conclusion, I would not make it a priority to play around with this now, but we should
1) improve the 402 page
2) make sure the merchant frontends can also deal with the payment happening in a new tab (without doing anything weird, like timeouts that indicate a missing extension)
3) eventually think about payments without changing the state (via JS) when necessary, but now now
(0012647)
Florian Dold   
2017-12-09 16:31   
I've made the 402 page less jarring, and disabled the page blanking in the wallet. It actually looks pretty okay now, but we need to come back to this to support asynchronous payments (that don't destroy web app state).

https://git.taler.net/blog.git/tree/talerblog/blog/templates/fallback.html
(0014572)
Marcello Stanisci   
2019-06-24 11:18   
LONG time fixed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5667 [Taler] other minor have not tried 2019-03-26 16:39 2019-09-16 09:19
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Remove configure checks of Python dependencies.
Description: Some Python frontends use the configure script to check if a dependency is available. Often times, they end installing those dependencies anyway under their installation prefix. So in order to not duplicate work and use one consistent policy, all the checks for dependencies should be removed from configure scripts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014587)
Marcello Stanisci   
2019-06-25 10:31   
f7a34c4..a579bd9 (survey.git) fixed
(0014588)
Marcello Stanisci   
2019-06-25 10:45   
c431800..cf09095 (bank.git) fixed
(0014589)
Marcello Stanisci   
2019-06-25 10:49   
f09cb42..f80d6a2 (donations.git) fixed
(0014590)
Marcello Stanisci   
2019-06-25 10:58   
Blog doesn't have this problem.
(0014591)
Marcello Stanisci   
2019-06-25 10:58   
All Py-frontends addressed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5786 [Taler] Web site(s) minor have not tried 2019-06-27 13:49 2019-09-16 09:19
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Move docs landing page content within the main www.taler.net site.
Description: The menu of all the documents that is now offered by docs.taler.net (currently kept at docs-landing.git) should be served by www.taler.net.

After the move, docs.taler.net will be a redirection to the new documentation URI offered by www.taler.net.

This way, the documentation menu can reuse the footer (and possibly other constructs) from www.taler.net.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014610)
Marcello Stanisci   
2019-06-27 23:03   
3ee16db9e27134d39d39b implements this.
(0014611)
Marcello Stanisci   
2019-06-27 23:05   
To be noted: docs.taler.net is not a redirection (in the sense that a 301 returned), but it simply points within the www.git codebase where also the main site is versioned.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5678 [Taler] other minor have not tried 2019-04-03 15:53 2019-09-16 09:19
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: not fixable  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: mailhook fails for large commits
Description: The mailhook fails for large commits, with two problems:
* the generated mail is too large
* some python module can't be imported

This shouldn't happen. Even tough huge commits are rare, they are necessary sometimes (e.g. to check in larger dependencies).
Tags:
Steps To Reproduce:
Additional Information: remote: Resolving deltas: 100% (7857/7857), done.
remote: refs/heads/master 0000000000000000000000000000000000000000 4e707c841bb479f81289b17f3ca932fa7ed5ffe0
remote: Commit 4e707c841bb479f81289b17f3ca932fa7ed5ffe0 was signed by a GPG key: gpg: Signature made Wed 03 Apr 2019 03:46:03 PM CEST
remote: Commit 71e285b94c7edaa43aa8115965cf5a36b8e0f80a was signed by a GPG key: gpg: Signature made Wed 03 Apr 2019 03:45:59 PM CEST
remote: Commit 7dadf9356b4f3f4137ce982ea5bb960283116e9a was signed by a GPG key: gpg: Signature made Wed 03 Apr 2019 03:45:54 PM CEST
remote: Sending notification emails to: gnunet-svn@gnu.org


remote: postdrop: warning: uid=1002: File too large
remote: sendmail: fatal: gnunet@gnunet.org(1002): message file too big
remote: Exception 'CommandError' raised. Please report this as a bug to
remote: https://github.com/git-multimail/git-multimail/issues
remote: with the information below:
remote:
remote: git-multimail version 1.4.0
remote: Python version 3.5.3 (default, Sep 27 2018, 17:25:39)
remote: [GCC 6.3.0 20170516]
remote: Traceback (most recent call last):
remote: File "hooks/post-receive.h00-post-receive.multimail", line 4214, in main
remote: run_as_post_receive_hook(environment, mailer)
remote: File "hooks/post-receive.h00-post-receive.multimail", line 3669, in run_as_post_receive_hook
remote: push.send_emails(mailer, body_filter=environment.filter_body)
remote: File "hooks/post-receive.h00-post-receive.multimail", line 3626, in send_emails
remote: rev.recipients,
remote: File "hooks/post-receive.h00-post-receive.multimail", line 2024, in send
remote: raise CommandError(self.command, retcode)
remote: CommandError: Command "/usr/sbin/sendmail -oi -t -f gnunet@gnunet.org" failed with retcode 75
remote:
remote:
remote: Traceback (most recent call last):
remote: File "hooks/post-receive.h01-post-receive.buildbot", line 28, in <module>
remote: from future.utils import iteritems
remote: ImportError: No module named 'future'
Attached Files:
Notes
(0014595)
Marcello Stanisci   
2019-06-25 23:10   
Tried locally, the following two shell commands should fix it.

# postconf -e message_size_limit=200000000
# service postfix restart

The question is, are 200MB a good value *in general* ?

Also, I couldn't reproduce the ImportError, since 'future' is actually not imported (anymore).
(0014597)
Marcello Stanisci   
2019-06-26 15:26   
(Last edited: 2019-06-26 15:27)
The 200000000 limit was obtained by trying to notifying the whole wallet-webex.git history via e-mail.

However, even by setting this value on one controlled server, it is not expectable that *other* e-mail servers will pass that big amount of data through.

CG suggests to set this value to 16MB, which is a threshold that other email servers will allow too (or at least, it is the one for gnunet.org).

(0014612)
Marcello Stanisci   
2019-06-27 23:20   
4fa6e73 (gv-maintenance.git) message_size_limit is set to 16MB.
(0014613)
Marcello Stanisci   
2019-06-27 23:22   
For changes bigger than 16MB the mail-hook will just fail!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5759 [Taler] deployment and operations minor have not tried 2019-06-10 00:22 2019-09-16 09:18
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Make the Buildbot execute code from ONE place.
Description: The BB currently (especially the "BUILD_FACTORY") performs first a checkout of deployment.git, and execute a few scripts (build.sh, sign.sh, keys.sh, ..) from the buildbot/ directory thereof, that in turn will execute other scripts from *another* deployment.git checkout (the one under $HOME).

This is not an error by itself, but It would be more neat for the BB to execute *all* the code from *one* deployment.git checkout, namely the one under $HOME (saves also bandwith this way).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014523)
Marcello Stanisci   
2019-06-10 00:24   
Actually, all the builders have this fashion, and should be changed!
(0014524)
Marcello Stanisci   
2019-06-10 01:08   
b0df7c9..5661335 addresses this completely. Putting as 'feedback' to see how the various builders react.
(0014614)
Marcello Stanisci   
2019-06-28 13:15   
No significant issues observed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5784 [Taler] mechant backend minor have not tried 2019-06-27 10:29 2019-09-16 09:18
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Wire response file creation fails when intermediate folder does not exist
Description: The merchant fails to deploy a JSON file under "[account-*]/wire_response = path", if one directory of the path is not found.

Instead, it should create those missing directories before trying to deploy the data (just as the exchange does!).
Tags:
Steps To Reproduce: Make sure the following config block exists:

[account-merchant]
wire_response = /some/path/merchant.json
url = payto:///url
plugin = taler_bank
taler_bank_auth_method = basic
username = x
passowrd = x
wire_file_mode = 770

*and*

make sure the "path" subfolder does not exist.

Then, launch the merchant:

$ taler-merchant-httpd

Additional Information:
Attached Files:
Notes
(0014615)
Marcello Stanisci   
2019-06-28 18:41   
Fixed: b201c2d..781414d.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5824 [Taler] other minor have not tried 2019-08-01 22:22 2019-09-16 09:18
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: git hook gives warning/exception, likely due to python upgrade
Description: See summary and additional information.
Tags:
Steps To Reproduce:
Additional Information: remote: Sending notification emails to: gnunet-svn@gnu.org
remote: hooks/post-receive.h00-post-receive.multimail:3178: DeprecationWarning: 'U' mode is deprecated
remote: f = open(GL_CONF, 'rU')
remote: hooks/post-receive.h00-post-receive.multimail:3178: DeprecationWarning: 'U' mode is deprecated
remote: f = open(GL_CONF, 'rU')
remote: Traceback (most recent call last):
remote: File "hooks/post-receive.h01-post-receive.buildbot", line 28, in <module>
remote: from future.utils import iteritems
remote: ModuleNotFoundError: No module named 'future'
Attached Files:
Notes
(0014824)
Florian Dold   
2019-08-29 22:56   
Fixed by installing the right python packages.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5270 [Taler] other minor have not tried 2018-02-01 07:22 2019-09-16 09:18
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: wallet detection misleading on non-WebExtension platforms
Description: On platforms where Taler is loosely integrated, the presence detection code would always indicate "not installed", even if Taler payments are supported.

We should probably check for the user agent and only display "not installed" warnings on browsers where tight integration via a browser plugin is possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014816)
Florian Dold   
2019-08-27 17:41   
This has been fixed on most demo sites now, as we support QR code payments.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5320 [Taler] other minor have not tried 2018-04-09 13:35 2019-09-16 09:12
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: consider using pipenv for easier "GNU-Style" installation of packages and deterministic builds
Description: pipenv (https://docs.pipenv.org/) is now officially recommended by the Python project, and allows easier management of virtualenvs and dependencies.

The idea with it would be to install each package into it's own virtualenv under $PREFIX, avoiding previous problems with the mess that is python's install paths.

This seems to be the "standard" solution to work around these problems.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014815)
Florian Dold   
2019-08-27 17:40   
We now use a more lightweight build system for the python packages that also supports GNU-style installation.

Pipenv is really mostly for setting up a development environment, and not really necessary for our use case.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5443 [Taler] merchant frontend (blog) minor have not tried 2018-09-26 20:16 2019-09-16 09:11
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: sub-resources should work without cookies
Description: Sub-resources should include the order ID (and if needed the session ID) in their URL, so that the merchant can check if the user is authorized to view them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014822)
Florian Dold   
2019-08-29 22:39   
This is not really something we want to do with the current merchant demo, as it's primarily session (=cookie) based. There is also nothing fundamental in the merchant APIs or the wallet that would prevent payments and sub-resources that are not bound to a session cookie.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5207 [Taler] other feature have not tried 2017-12-09 22:14 2019-09-16 09:10
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: offer high-level merchant integration in addition to the current low-level integration
Description: Currently offering payments with Taler is not as easy as it could be (and not as easy as with some other payment providers). We need to set headers, implement quite a lot of endpoints and know too many details of how the protocol works.

This is fine for our demos, but we could make it even easier, by offering a merchant-as-a-service component that takes over some duties that currently the frontend has to do.

It would offer mostly just two end-points:
1) create an order: returns an order_id and a URL that's served by the merchant-as-a-service component which will trigger the payment and take care of all the details (headers, contract generation, etc.)
2) check if an offer_id has been paid for, returns the contract terms and either "yes" or the URL to redirect the user to that will make the payment happen

Additionally we can allow payments even on *static* websites, by POSTing a form to the merchant-as-a-service component. This is useful either for donations or for products that will be physically/individually be delivered. If the seller runs out of stock, they can give a refund in the web interface.

The difference to the "low-level integration" that we currently have is that the merchant-as-a-service serves pages to the browser and the wallet directly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012648)
Florian Dold   
2017-12-09 22:21   
Oh and of course this would not be a new backend, but just a new "frontend with an API" that talks to the current backend with the low-level API.

Maybe a nice project for somebody who wants to work on Taler, who's pretty new and wants to do rather high-level things.
(0014830)
Florian Dold   
2019-09-01 18:39   
All this is covered by the codeless merchant.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5854 [Taler] other minor have not tried 2019-08-27 13:51 2019-09-16 09:10
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: use yapf to format python code
Description: The formatting in our Python code is a mess. We should use yapf to format it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014831)
Florian Dold   
2019-09-01 18:40   
This has been added to most repositories now. Use "make pretty" to run the formatter.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5596 [Taler] Web site(s) minor have not tried 2019-02-21 16:40 2019-09-16 09:10
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Adjust repository layout
Description: As requested by Christian, taler.net/www should be adjusted to gnunet.org/www layout
which I introduced last night.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014835)
ng0   
2019-09-02 11:46   
will be done this month
(0014836)
ng0   
2019-09-02 13:04   
Essentially done in the last 3 commits, but since I've been away for too long someone needs to refresh me on where I need to do the changes server-side now. is the output in $home done by Buildbot now?
(0014837)
ng0   
2019-09-02 15:29   
Will look into this once I have the gettext + syntax cleanup work done
(0014840)
ng0   
2019-09-03 16:53   
Resolved in the last series of commits, live on stage.taler.net


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5287 [Taler] wallet (app) text have not tried 2018-02-22 14:22 2019-09-16 09:10
Reporter: Christian Grothoff Platform: i7  
Assigned To: ng0 OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: strings not tagged for translation / tagged oddly
Description: Some po strings have odd spacing in them in relation to the format strings. Also, it seems not all strings (especially in tipping dialog) have been marked for i18n. Finally, we probably should go together over all of the English text again to polish it a bit before giving it out for translation at scale.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014682)
ng0   
2019-07-15 19:13   
Ack, will get to this after GSoC.
One question: this is 'wallet-webex.git', right?
(0014686)
Christian Grothoff   
2019-07-15 19:34   
yes
(0014687)
ng0   
2019-07-15 19:41   
Tack.
(0014838)
ng0   
2019-09-02 18:08   
I've cleaned up the .po files from strings which no longer exist, added more translatable sections but there's still some pages I need to go through.
(0014839)
ng0   
2019-09-03 16:03   
I believe except for the /news folder I have everything covered now.

This however reveals "odd strings" as you put it, even after multiple cleanups of the .po files. See stage.taler.net/de/team.html for an example.

I'm now looking into where this might originate from.
(0014842)
ng0   
2019-09-03 17:22   
For the wrong strings - this seems to be a matter of a translators job.

For the warnings when building on the server, I still have to investigate some more.
(0014843)
ng0   
2019-09-03 17:28   
https://buildbot.taler.net/#/builders/1/builds/23/steps/1/logs/stdio shows that this part is done:
- Some po strings have odd spacing in them in relation to the format strings.
- Also, it seems not all strings (especially in tipping dialog) have been marked for i18n.


Not done:
- Finally, we probably should go together over all of the English text again to polish it a bit before giving it out for translation at scale.

I'm closing this one and open a new ticket for "polishing the text", as this is another subject
(0014844)
ng0   
2019-09-03 17:30   
resolved in https://buildbot.taler.net/#/builders/1/builds/23/steps/1/logs/stdio


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5804 [Taler] Web site(s) minor have not tried 2019-07-15 16:13 2019-09-16 09:10
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Mark more strings to translate in new taler.net
Description: The new website version has many strings which are not marked as translatable in the j2 code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014676)
ng0   
2019-07-15 16:14   
I will get to this after GSoC.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5701 [Taler] Web site(s) block always 2019-04-23 14:51 2019-09-16 09:10
Reporter: Torsten Grothoff Platform: Opera  
Assigned To: Marcello Stanisci OS: Linux  
Priority: urgent OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Error code 2502 while buying article links on https://shop.demo.taler.net
Description: I've tested all article-links on https://shop.demo.taler.net, they all return:

    An Error Occurred
    Backend returned error status

    The backend returned status code 500.

    Backend Response:

    {'hint': 'db error: could not check for existing order', 'code': 2502}

on an error page




attatched are pngs of: https://shop.demo.taler.net/essay/Foreword https://shop.demo.taler.net/
Tags:
Steps To Reproduce: 1. Visit https://shop.demo.taler.net/ in browser
2. Click on any article
3. See error
Additional Information:
Attached Files: shop.demo.taler.netSLASHessaySLASHforeword.png (74,375 bytes) 2019-04-23 14:51
https://bugs.gnunet.org/file_download.php?file_id=832&type=bug
Shop.demo.taler.net.png (163,384 bytes) 2019-04-23 14:51
https://bugs.gnunet.org/file_download.php?file_id=833&type=bug
Notes
(0014463)
Marcello Stanisci   
2019-05-30 14:39   
not showing anymore up. Putting as feedback.
(0014855)
Florian Dold   
2019-09-04 15:40   
Marking this one as resolved. With the recent changes in the blog and backend, this error is unlikely to be reproducible and likely to be fixed by now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5803 [Taler] Web site(s) minor have not tried 2019-07-15 15:32 2019-09-16 09:09
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: website navbar is not responsive
Description: At a certain size the navbar simply disappears, with its items not reappearing/rendering elsewhere.

I'll get to this after GSoC ends.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014845)
ng0   
2019-09-03 17:47   
I consider this done (tested in Firefox 68.0), but since you reintroduced the language selection box which does not fit into the theme, I will only close this after I have a solution for this.
(0014857)
ng0   
2019-09-04 19:31   
resolved. as a short usertest showed we need to think about the website colors and layout as well.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5430 [Taler] wallet (WebExtensions) feature have not tried 2018-08-26 00:12 2019-09-16 09:09
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: urgent OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: wallet popup sometimes empty with current firefox
Description: The reason for this is likely that DOMContentLoaded gets fired too early. Although the script is included in the header, webpack bundling might cause the code to be executed slightly too late.

To fix this, we simple need to check the document readyState
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014863)
Florian Dold   
2019-09-05 16:31   
The wallet now properly displays exception if they occur during rendering, and also waits for DOMContentLoaded.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5618 [Taler] wallet (browser-based) block always 2019-02-28 21:28 2019-09-16 09:09
Reporter: Torsten Grothoff Platform: Chromium  
Assigned To: Florian Dold OS: Linux  
Priority: immediate OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Fails to withdraw on test.taler.net
Description: URLs:
https://bank.test.taler.net/profile
chrome-extension://millncjiddlpgdmkklmhfadpacifaonc/src/webex/pages/confirm-create-reserve.html?amount=%7B%22currency%22%3A+%22TESTKUDOS%22%2C+%22fraction%22%3A+0%2C+%22value%22%3A+5%7D&bank_url=https%3A%2F%2Fbank.test.taler.net%2Fwithdraw&callback_url=https%3A%2F%2Fbank.test.taler.net%2Fpin%2Fquestion&sender_wire=%7B%22account_number%22%3A+15%2C+%22bank_url%22%3A+%22https%3A%2F%2Fbank.test.taler.net%2F%22%2C+%22type%22%3A+%22test%22%7D&suggested_exchange_url=https%3A%2F%2Fexchange.test.taler.net%2F&wt_types=%5B%22test%22%5D
Errors:
"Error: Property type missing on (root) of _"
Tags:
Steps To Reproduce: Visit https://bank.test.taler.net/profile
Select ANY Amount to withdraw
Click Select Exchange Provider
See Error
Additional Information:
Attached Files: Gnu-Taler-ERROR-WITHDRAW.png (82,244 bytes) 2019-02-28 21:28
https://bugs.gnunet.org/file_download.php?file_id=820&type=bug
Notes
(0014864)
Florian Dold   
2019-09-05 16:32   
This was a problem with the format of wire details returned by the exchange, and it has been fixed for quite a while.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5504 [Taler] wallet (WebExtensions) block always 2018-12-24 22:33 2019-09-16 09:09
Reporter: Torsten Grothoff Platform: Tor Browser  
Assigned To: Florian Dold OS: Windows  
Priority: immediate OS Version: 7  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: Fatal Error While trying to select exchange provider
Description: URL: moz-extension://64e4328c-d2d7-4635-84f3-11732b4632c0/src/webex/pages/confirm-create-reserve.html?amount=%7B%22currency%22%3A+%22KUDOS%22%2C+%22fraction%22%3A+0%2C+%22value%22%3A+5%7D&bank_url=https%3A//bank.demo.taler.net/withdraw&callback_url=https%3A//bank.demo.taler.net/pin/question&sender_wire=%7B%22bank_url%22%3A+%22https%3A//bank.demo.taler.net/%22%2C+%22account_number%22%3A+231%2C+%22type%22%3A+%22test%22%7D&suggested_exchange_url=https%3A//exchange.demo.taler.net/&wt_types=%5B%22test%22%5D

Page Content[while showing error]:
Fatal error: "".


Console:
got error
Error

columnNumber: 9

detail: Object { error: "exception", message: undefined, stack: undefined }

fileName: "moz-extension://64e4328c-d2d7-4635-84f3-11732b4632c0/dist/page-common-bundle.js"

lineNumber: 4721

stack: "WalletApiError@moz-extension://64e4328c-d2d7-4635-84f3-11732b4632c0/dist/page-common-bundle.js:4721:9\ncallBackend/</</<@moz-extension://64e4328c-d2d7-4635-84f3-11732b4632c0/dist/page-common-bundle.js:4731:31\n"

__proto__: Object { stack: "", … }
confirm-create-reserve.tsx:512:4
main/<
confirm-create-reserve.tsx:512:4
rejected
moz-extension://64e4328c-d2d7-4635-84f3-11732b4632c0/dist/confirm-create-reserve-bundle.js:26:47
Tags:
Steps To Reproduce: Go to https://bank.demo.taler.net/profile
Click select exchange provider
See error
Additional Information:
Attached Files:
Notes
(0013439)
Florian Dold   
2018-12-27 20:51   
Hi Torsten!

Could you try if it works when you create a new user profile in Firefox?

We have this bug that we are not able to reproduce, sometimes Firefox profiles get corrupted when upgrading the wallet version.

If it works in a new profile, it would be great if you keep the old, non-working profile so that we can figure out what exactly is going wrong.
(0013444)
Christian Grothoff   
2019-01-02 12:12   
Torsten, you can create a new profile in Firefox by starting Firefox using:

$ firefox --ProfileManager
(0014865)
Florian Dold   
2019-09-05 16:34   
We've figured out the firefox profile problem (indexeddb sometimes gets disabled by some other extension), and there's a warning included now in the current (git) wallet.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5441 [Taler] wallet (WebExtensions) minor have not tried 2018-09-24 19:59 2019-09-16 09:08
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: wallet should have "welcome page" that is opened on nagivation
Description: This also allows us to check whether the installation went okay, and in some cases to detect whether the user has a broken profile (mostly on Firefox!)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014867)
Florian Dold   
2019-09-05 16:40   
Implemented in 8144b0f55.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5373 [Taler] wallet (WebExtensions) major have not tried 2018-06-29 17:24 2019-09-16 09:08
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: wallet does not properly implement same origin restrictions for resource based payments
Description: This allows other websites to, in some cases, find out whether a customer has paid for a certain resource URL.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014869)
Florian Dold   
2019-09-06 11:10   
Fixed in f6c0108511.

We do not actually base this off the origin (as one merchant deployment could have multiple origins for content and backend), but based on the merchant public key.

Existing payment redirection only kicks in when we see another contract from the *same* merchant.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5745 [Taler] wallet (WebExtensions) minor have not tried 2019-06-03 10:34 2019-09-16 09:08
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: wallet should include a "client version cache breaker" in requests to /wire and /keys
Description: When the wallet is upgraded, it might have stale /keys or /wire information. Similarly, sometimes a deployment might have sent wrong expiration headers, and thus /keys and /wire would live in the cache for too long.

To fix this, the wallet should include a "client version cache breaker" parameter. This allows us to force a re-download of the exchange's information. To preserve privacy, this version number should change as rarely as possible and stay consistent across implementations (browser vs phone etc.).

The request looks like this (cv = client version):

exchange.demo.taler.net/keys?cv=3
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014871)
Florian Dold   
2019-09-06 12:36   
Implemented in 4b8b967e58


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5892 [Taler] deployment and operations minor have not tried 2019-09-13 18:45 2019-09-16 09:07
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: reserve topper worker got forgotten
Description: The Buildbot worker that takes care of topping the tip reserve up is currently NOT run by any user from Gv.Taler.Net.

We might also never run it automatically, and only once in a while put a million KUDOS into the tip reserve, and "enjoy" the error generation+handling once the reserve runs out of money.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014897)
Marcello Stanisci   
2019-09-13 22:24   
the worker is run automatically by test-topper and demo-topper. Needs testing!
(0014898)
Marcello Stanisci   
2019-09-13 23:29   
tested


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5658 [libextractor] build system minor have not tried 2019-03-20 10:35 2019-09-14 14:22
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: --with-jpeg is not recognized
Description: There is more than 1 jpeg library implementation.
Ideally we get to choose which one to use. For now we should precisely describe
which one is supported.

Overriding the path to jpeg prefix would be good, too.

If there are no objections, I would add the prefix part. I'm not sure about the supported jpeg libraries.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014759)
Christian Grothoff   
2019-07-29 18:04   
Both libjpeg-turbo and the IJG JPEG library should both work (they're API compatible). And sure, feel free to extend configure[.ac].
(0014901)
ng0   
2019-09-14 12:23   
Can you assign this to me? I can't assign tickets to myself in the libextractor group.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5876 [gnURL] General minor have not tried 2019-09-05 11:09 2019-09-14 12:19
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: update website
Description: It would be good to have a short instruction how to build gnurl or a link to it on the subpage for
gnurl.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014899)
ng0   
2019-09-14 12:19   
done in 7.66.0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4581 [GNUnet] exit daemon feature always 2016-06-17 20:13 2019-09-13 01:23
Reporter: lynX Platform:  
Assigned To: ng0 OS: FreeBSD  
Priority: low OS Version: 9.3-RELEASE-p1  
Status: assigned Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: iptables not available on FreeBSD
Description: https://gnunet.org/book/export/html/1605 mentions exit/VPN possibly working on BSD, but unfortunately /usr/include/net/if_tun.h provides a lot less features than linux/if_tun.h. I added some ifdefs to correct the include and avoid some ioctls that do not exist on BSD, but the fact that gnunet-helper-exit tries to call "iptables" makes this feature currently not very portable to BSD.

I suppose it is pointless to commit my patches that allow gnunet-helper-exit to compile if it can't possibly work.
Tags:
Steps To Reproduce:
Additional Information: Fatal: executable iptables not found in approved directories: No such file or directory
Fatal: executable iptables not found in approved directories: No such file or directory
Fatal: executable iptables not found in approved directories: No such file or directory
Attached Files:
Notes
(0011000)
Christian Grothoff   
2016-08-03 11:50   
Is it so hard to figure out how to translate the iptables invocations to corresponding FreeBSD incantations?
(0014230)
ng0   
2019-03-21 14:24   
It seems to me as if this bug would be solved once the rewrite of -dns-helper I was told about
is done?
(0014259)
Christian Grothoff   
2019-04-05 23:13   
Yes, but this would require a _major_ rewrite of gnunet-service-dns to basically turn it into a DNS server instead of a DNS query interceptor.
(0014879)
ng0   
2019-09-10 10:38   
(Last edited: 2019-09-10 10:40)
meanwhile could I add pf and/or npf support? I can at least come up with this faster than rewriting gnunet-service-dns into a dns server.

Part of the original issue has been worked around iirc (not compiling on FreeBSD) but someone would have to test it (me, as soon as replacement parts for my server arrive).

The issue of this not working on *BSD remains.

(0014880)
Christian Grothoff   
2019-09-10 13:34   
Sure, pf/npf support would be great. (Note: no relationship to Taler here, though).
(0014883)
ng0   
2019-09-11 14:04   
This file will also fail with system which do not provide the binary "ip", which also includes the majority of the BSD Operating Systems.
(0014895)
ng0   
2019-09-13 01:23   
As a sidenote for myself and reference - there seems to be a (slow) move to replace iptables with BPF: https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5883 [libeufin] General minor have not tried 2019-09-09 13:42 2019-09-12 13:33
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: figure out if AqBanking can actually do EBICS
Description: EBICS seems to be there in the sources, but I'm not sure if it can be actually used (and how!).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014876)
Florian Dold   
2019-09-09 13:43   
The goal with this is to point AqBanking to our own EBICS sandbox.
(0014877)
Florian Dold   
2019-09-09 15:18   
Well, it doesn't support it! Or if it does, it's completely broken. It would be a waste of time to investigate this further.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5882 [libeufin] General minor have not tried 2019-09-09 13:41 2019-09-12 13: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:  
Summary: implement sandbox for EBICS + ISO20022 subset
Description: Ideally we also validate this sandbox by using an existing (proprietary) banking software and point it to our 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:
5885 [libeufin] General minor have not tried 2019-09-09 14:08 2019-09-12 13: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:  
Summary: implement API to add new bank accounts managed by libeufin
Description: For many types of accounts (such as FinTS) there is a multi-step procedure necessary to "initialize" the setup of access to a bank account. Thus it's not enough to just have some config file with the credentials, we need to keep more 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:
5890 [GNUnet] build process minor have not tried 2019-09-11 14:06 2019-09-11 16:08
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: some conftest tests do not include stdlib
Description: malloc on NetBSD is defined in stdlib.h, conftest currently leads to:

configure:18990: checking whether unaligned 64-bit access works
configure:19015: clang -o conftest -fno-strict-aliasing -Wall -g -O0 -Wno-address-of-packed-member -L/usr/pkg/lib -Wl,--unresolved-symbols=report-all conftest.c >&5
conftest.c:32:24: warning: implicitly declaring library function 'malloc' with type 'void *(unsigned long)' [-Wimplicit-function-declaration]
                                 void *bp = malloc (50);
                                            ^
conftest.c:32:24: note: include the header <stdlib.h> or explicitly provide a declaration for 'malloc'
1 warning generated.
configure:19015: $? = 0
configure:19015: ./conftest
configure:19015: $? = 0
configure:19026: result: yes
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:
5886 [GNUnet] cadet service minor N/A 2019-09-09 18:10 2019-09-09 18:17
Reporter: buttfly 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: Use more secure algorithms in CADET
Description: Upon reading https://docs.gnunet.org/handbook/gnunet.html#CADET-Subsystem I found:

- CADET provides confidentiality with so-called perfect forward secrecy; we use ECDHE powered by Curve25519 for the key exchange and then use symmetric encryption, encrypting with both AES-256 and Twofish
- authentication is achieved by signing the ephemeral keys using Ed25519, a deterministic variant of ECDSA
- integrity protection (using SHA-512 to do encrypt-then-MAC, although only 256 bits are sent to reduce overhead)
[...]

My questions are:

1) Would it not be more ideal to use Salsa20 or XSalsa20 instead of AES-256 and Twofish?
2) Should not we use BLAKE2? Its digest sizes are 224, 256, 384, and 512 bits. There would be no need to truncate, AND it is much faster than SHA-512. See https://blake2.net/ for benchmarks and more information.
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:
5879 [GNUnet] TCP transport minor have not tried 2019-09-09 12:33 2019-09-09 12:33
Reporter: ng0 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: gnunet-communicator-tcp build: uninitialized warning
Description:   CC gnunet-communicator-tcp.o
gnunet-communicator-tcp.c:1008:39: warning: variable 'left' is uninitialized when used here [-Wuninitialized]
        GNUNET_SCHEDULER_add_read_net(left, queue->sock, &queue_read, queue);
                                                                     ^~~~
gnunet-communicator-tcp.c:991:3: note: variable 'left' is declared here
  struct GNUNET_TIME_Relative left;
  ^
1 warning generated.
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:
5878 [GNUnet] build process minor have not tried 2019-09-06 15:36 2019-09-06 15:36
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: underquoted definition warning
Description: while running bootstrap, I get an underquoted definition warning which probably originated from within our autotools code.

checking for libtoolize / libtool...
/usr/pkg/share/aclocal/libstroke.m4:29: warning: underquoted definition of smr_ARG_WITHLIB
/usr/pkg/share/aclocal/libstroke.m4:29: run info Automake 'Extending aclocal'
/usr/pkg/share/aclocal/libstroke.m4:29: or see https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
/usr/pkg/share/aclocal/libstroke.m4:29: warning: underquoted definition of smr_ARG_WITHLIB
/usr/pkg/share/aclocal/libstroke.m4:29: run info Automake 'Extending aclocal'
/usr/pkg/share/aclocal/libstroke.m4:29: or see https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
configure.ac:45: installing 'build-aux/compile'
configure.ac:39: installing 'build-aux/missing'
contrib/Makefile.am: installing 'build-aux/depcomp'
/usr/pkg/share/automake-1.16/am/texinfos.am: warning: AM_MAKEINFOHTMLFLAGS was already defined in condition !ACTIVATE_TEXINFO4, which is included in condition TRUE ...
doc/handbook/Makefile.am:21: ... 'AM_MAKEINFOHTMLFLAGS' previously defined here
/usr/pkg/share/automake-1.16/am/texinfos.am: warning: AM_MAKEINFOHTMLFLAGS was already defined in condition !ACTIVATE_TEXINFO4, which is included in condition TRUE ...
doc/tutorial/Makefile.am:19: ... 'AM_MAKEINFOHTMLFLAGS' previously defined here
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:
5866 [Taler] wallet (browser-based) minor have not tried 2019-08-31 13:28 2019-09-06 12: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.6  
Summary: wallet should compute accurate fees for refunds, including refreshing and withdrawing
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:
5830 [Taler] merchant backend API (C) minor have not tried 2019-08-17 19:26 2019-09-06 11: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: 0.7  
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:
5875 [gnURL] General minor have not tried 2019-09-05 11:09 2019-09-05 11:09
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Update README
Description: in a conversation with bfix on irc I realized the README hasn't been updated to reflect recent
changes in the build instructions.
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:
5853 [Taler] merchant backend API (C) minor have not tried 2019-08-26 23:32 2019-09-04 15:35
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: sessions should be limited in number and duration per order_id
Description: Currently we keep session-based payments around in the database forever.

We should delete old sessions after a configurable duration.

Furthermore, we should limit the number of simultaneous sessions per order id.
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:
5873 [Taler] exchange minor have not tried 2019-09-04 11:41 2019-09-04 12:03
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: design document and implement "legacy" banking API for libeufin and implement wirewatch plugin
Description: Some banking APIs do *not* offer us nice, monotonically increasing transaction identifiers. Instead, we can only query a time range of transaction data.

Even worse, new transaction might appear in a time range that we've already queried, so we need to re-query older time ranges, preferably with a lower frequency than querying the newer ones.

With libeufin, we will have a unified interface to query these "legacy" bank interfaces. However, this still doesn't give us a "nice" transaction history like the Taler demo bank gives us.

To allow integration with legacy APIs, we need to
1. Define a HTTP/JSON API between the wirewatch plugin and libeufin for "legacy bank interfaces"
2. Implement a wirewatch plugin for this
3. Implement a "legacy bank interface" for our own demo bank, so we can test the wirewatch plugin.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014853)
Marcello Stanisci   
2019-09-04 11:55   
Point number 3 was implemented a while ago (but of course never tested due to the lack of a wire-plugin)!

https://docs.taler.net/core/api-bank.html#get--history-range


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5746 [Taler] wire plugins tweak have not tried 2019-06-03 11:04 2019-09-04 12:03
Reporter: Marcello Stanisci 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:  
Summary: history query with ranges needs testing
Description: The "taler bank" plugin got extended with a method to ask bank's histories based on dates ranges ("taler_bank_get_history_range()"). However, this method was never called by the auditor, or any other testing artifact.

Therefore, testing is needed for 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:
5670 [Taler] Merchant frontends (Python3) minor have not tried 2019-03-28 15:44 2019-09-03 18:16
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Need a custom 404 page.
Description: Right now, no frontend has a custom, and pretty page for non-found pages. They either display some Python3 stack trace, or the Nginx' default 404 page.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014681)
ng0   
2019-07-15 19:04   
Ack, will get to it after GSoC.
(0014846)
ng0   
2019-09-03 18:16   
is my understanding correct that this about merchant-frontend-examples.git?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5839 [Taler] wallet (WebExtensions) feature have not tried 2019-08-18 15:23 2019-09-02 10:00
Reporter: Florian Dold Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.7  
Summary: implement complete CLI bindings for the wallet
Description: Currently the wallet has an extremely simplified command line interface with mostly hardcoded values, implemented here:
https://git.taler.net/wallet-webex.git/tree/src/headless/taler-wallet-cli.ts

What should be added is:
* specifying the exchange, bank and amount to use when withdrawing
* paying for contract URLs
* refunds
* receiving tips
* (... and basically everything else the wallet already does)
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:
5774 [Taler] wallet (WebExtensions) minor have not tried 2019-06-25 14:49 2019-09-01 18:44
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.7  
Summary: add support for creating a reserve from within the wallet and topping it up via payto QR code
Description: It would be good if the wallet could generate payto://-URIs in the form of a QR code (and text) for the bank wire transfer (for the non-cooperative consumer bank scenario where we trigger the wire transfer via QR code to a payto://-enabled bank App).
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:
5870 [Taler] other minor have not tried 2019-09-01 18:37 2019-09-01 18: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:  
Summary: update codeless payments to new API, deploy on gv
Description: The codeless payments project hasn't been touched in quite a while, and we don't have a running deployment.
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:
5869 [Taler] wallet (WebExtensions) minor have not tried 2019-09-01 01:30 2019-09-01 01:30
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.7  
Summary: idb-bridge should have more test cases
Description: Ideally we'd port the web platform tests to it (https://github.com/web-platform-tests/wpt/tree/master/IndexedDB).
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:
5867 [Taler] wallet (WebExtensions) minor have not tried 2019-08-31 14:23 2019-08-31 14: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:  
Summary: interaction between refunds and payment re-play unclear
Description: When an article is refunded and the merchant offers to pay for a new instance of it (with a new order ID), the wallet will still try to replay the payment for the refunded payment. This will just lead to the "can't view article, it has been refunded" page of the merchant.

The wallet should probably provide some escape hatch and offer the user to make a payment for the new contract in case there is a refund for the matching old payment.

All these cases should be written down somewhere, also to make it easier for merchants.
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:
5863 [Taler] merchant backend API (C) crash have not tried 2019-08-30 17:55 2019-08-31 14:10
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: trying to pay again for a refunded contract crashes the merchant
Description: It looks like the wallet is doing something wrong with payment re-playing in this case, but that should not crash the merchant!

#0 0x00007f34151907bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f341517b535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f34153e4a29 in GNUNET_abort_ () at common_logging.c:292
#3 0x0000560af9ff4e24 in check_payment_sufficient (pc=0x560afaf10480) at taler-merchant-httpd_pay.c:728
#4 0x0000560af9ff938b in begin_transaction (pc=0x560afaf10480) at taler-merchant-httpd_pay.c:1997
#5 0x0000560af9ff9749 in handler_pay_json (connection=0x560afaf143f0, root=0x560afad7d1c0, pc=0x560afaf10480)
    at taler-merchant-httpd_pay.c:2113
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014827)
Florian Dold   
2019-08-31 13:51   
The problem is actually that the refund gets computed incorrectly and ends up being higher than even the total contract amount.
(0014828)
Florian Dold   
2019-08-31 14:10   
Fixed in
4b47e468889379e97da465bbc13f9a7314d8c6f2
8d841f8c99751590333c7f34ce96f51dcd9e27b6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5865 [Taler] merchant frontend (blog) minor have not tried 2019-08-31 11:13 2019-08-31 11:13
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:  
Summary: refund should only be offered when it is actually possible to refund
Description: Currently the frontend doesn't check if refund is actually still possible, or if the refund deadline for the article expired.

In /check-payment, the backend should probably tell the frontend with an easy flag if refund is still possible.
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:
5861 [Taler] mechant backend minor have not tried 2019-08-30 15:25 2019-08-30 15:25
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: merchant backend does not handle tip expiration properly
Description: Currently we just specify a fixed deadline for tips, but never check 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:
5038 [Taler] wallet (WebExtensions) tweak have not tried 2017-05-29 02:29 2019-08-29 23:04
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: use smaller URL parsing library, since its included on every page
Description: We currently use urijs, which is pretty huge (64KB unminified). This is more than double the size of our own code in the content script.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014826)
Florian Dold   
2019-08-29 23:04   
The content script now doesn't do any URI parsing. Everything is handled by the wallet backend, which offers a more simplified API as of recently.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5223 [Taler] other feature have not tried 2017-12-16 17:17 2019-08-29 23:01
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: make wallet/website integration possible for platforms without browser extensions
Description: This might require some protocol changes.

How integration would work on mobile platforms is via a URL schema handler (distinct from payto://).

The fallback page for 402 would navigate to this URL, and it would contain the same information as the headers:

taler://pay?contract_url=<...>&offer_url=<...>
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012700)
Florian Dold   
2017-12-19 19:22   
Here's how it would work for Chrome on Android: https://developer.chrome.com/multidevice/android/intents
(0012727)
Florian Dold   
2018-01-04 18:03   
While the merchant API is being adjusted to accommodate for this, the bank still relies on HTTP headers, which won't work with lose integration.
(0014825)
Florian Dold   
2019-08-29 23:01   
Both merchant and bank now trigger the wallet through taler:// URIs, delivered through a header, a QR code and a normal link.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5858 [Taler] other minor have not tried 2019-08-28 15:58 2019-08-28 15:58
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.6  
Summary: implement cancelling a withdraw operation in dialogs and backend
Description: Currently there is only an "accept" button, but there should also be a cancel button that does the appropriate thing.
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:
5833 [secushare] tracking-issues minor have not tried 2019-08-18 13:37 2019-08-28 08:06
Reporter: lurchi 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.1  
Summary: CADET tracking issue
Description: These CADET issues need to be resolved for a secushare release: see "related issues"
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:
5837 [secushare] groupchat minor have not tried 2019-08-18 15:03 2019-08-27 22:37
Reporter: lurchi Platform:  
Assigned To: xrs OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.1  
Summary: [RFC] Ring-based groupchat (serverless)
Description: For the first release we should design and implement a protocols for establishing a ring topology. This is one of the simplest topologies that can be decentralized and self-organized. It would allow us to eliminate the server peer and conduct experiments with message relaying in real-world network conditions.

Requirements:
- Purely p2p, no "super nodes"
- high availability of groups (99,95% downtime as a rough estimate)

Architecture:
- the pure p2p structure is achieved by sending group messages over cadet connections organized as a ring topology
- high availability is achieved by to measures:
  - the topology is enriched by more links skipping direct neighbours to improve the reliability of message delivery
  - it's recommended that at least one group member runs a peer always on
- group members use a distributed state

State Information:
- group ID
- group name
- list of members
- list of group owners (just a flag in the member list)

Process: Create group
- group owner creates group ID and stores given group name
- group owner adds given peer IDs as new group members
- group members are sent an invitation message per cadet with the state information
- group members send ack over group topology (or: back over cadet)

Process: Send a message
- create a message, create a message ID (random number), optionally a pointer to a previous message if desired
- send a message to the next available group member following in the ordered list
- receiving group member sends an ack back
- the message is forwarded to the whole group and back to the sender who thereby gets a pseudo group confirmation

Process: Add new group member
- group owner sends invitation message per cadet containing the state information
- new group member acknowledges membership by sending ack over group links (or back over cadet)
- group owner sends new message with status information to group members

Process: Disjoin (go offline)
- group member just goes offline (FIXME: would be nice to have status information, thus notify)

Process: Rejoin (go online)
- group member requests state information from next group members in the ordered list
- group member updates its state and can then send messages

Process: join group
- new peer sends join request at known group member
- join request is forwarded to group owner
- group owner decides on request; if positive, group owner sends an invitation message to the new peer

Process: leave group
- group member sends leave message
- group owner sends new message with status information to group members

Issues:
- Scalability
- Reliability
- Latency
- Multicast tree topology is more efficient than ring topology
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014819)
xrs   
2019-08-27 22:37   
Let's try a pattern of self-organization which is proposal making.

1. round: Present proposal/RFC (hereby done).
2. round: ask questions and get clarifications. Repeat if there are more questions.
3. round: make suggestions for improvement. The initiators will try to integrate those suggestions (or objections).
4. step: Obtain consent for a first sprint and celebrate :-)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5856 [Taler] wallet (WebExtensions) minor have not tried 2019-08-27 22:15 2019-08-27 22:15
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:  
Summary: wallet should support re-trying pending operations immediately instead of waiting
Description: This must both be implemented by the wallet backend, as well as shown as by the GUI.
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:
5070 [Taler] wallet (WebExtensions) feature have not tried 2017-06-06 16:05 2019-08-27 17:43
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version: SVN HEAD  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: compiler taler-wallet-lib to webassembly
Description: This only makes sense once current browser versions support it. It should reduce the size of the extension a lot, and possibly make it faster.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014818)
Florian Dold   
2019-08-27 17:43   
We've already been compiling to webassembly for a while, this is also done using emscripten.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5026 [Taler] wallet (browser-based) feature have not tried 2017-05-24 02:46 2019-08-27 17:42
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: the TypeScript/emscripten wallet should have a nodejs standalone mode and command line interface
Description: Right now we only support doing things from the browser, but both for testing the browser as well as other components, it might be nice to be able to run the complete wallet without a browser.

The code is already structured to facilitate this, just the command line interface and some database glue code (to make IndexedDB available from Node.js).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014817)
Florian Dold   
2019-08-27 17:42   
The taler-wallet-cli now exists!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5848 [Taler] merchant backend API (HTTP specification) minor have not tried 2019-08-23 13:14 2019-08-27 17:38
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: deprecate / rename payment_redirect_url
Description: Since we don't want merchants to use it, it shouldn't be named like something that should be redirected to.

Instead, it should be called something like "fallback_payment_request_url", which makes clear that it shouldn't be used in the normal case.

Merchants should render their own 402 page with alternate payment mechanisms, including Taler QR code payments.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014814)
Florian Dold   
2019-08-27 17:38   
The paymen_redirect_url is now gone. Instead we have the taler_pay_uri, which can be used to test the merchant as a developer with the CLI wallet, without having some frontend running.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5852 [Taler] other minor have not tried 2019-08-26 03:57 2019-08-26 03:57
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:  
Summary: integration test for session-based payments
Description: The session-based payments (including re-purchase detection) should have an integration test, using the headless 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:
5850 [Taler] bank (demonstrator) minor have not tried 2019-08-23 16:12 2019-08-23 16:12
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: revise test cases that check for error messages
Description: Some test cases currently check that some error will occur. It does this by running the test suite with a modified config, and then checks if the test runner returns a non-zero result.

This results in really confusing logs. We should have separate unit tests to check if wrong or missing config values are handled incorrectly. However, these shouldn't result into output where the test runner (!!) says that there was an error, but then the test case succeeds.

I've disabled these tests for now.
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:
5798 [GNUnet] webpage text have not tried 2019-07-10 11:35 2019-08-23 09:42
Reporter: ng0 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: handbook links are 404
Description: Please move more carefully when you change how the website works. We need to fix this before the release, this is a blocker.

reported by carl hansen at https://lists.gnu.org/archive/html/bug-gnunet/2019-07/msg00001.html:

https://docs.gnunet.org/handbook/
403 Forbidden
________________________________
nginx/1.10.3

_______________________________________________
Bug-GNUnet mailing list
Bug-GNUnet@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnunet
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: gnunet_org_links.png (80,187 bytes) 2019-07-10 15:34
https://bugs.gnunet.org/file_download.php?file_id=843&type=bug
Notes
(0014663)
ng0   
2019-07-10 11:45   
Adding to this: there is the probability we made some more links 404.

Do set server-side redirects for the old ones. This is important, because broken links are bad for the public image.
(0014665)
ng0   
2019-07-10 15:34   
A couple more links which can be grepped for.
(0014713)
ng0   
2019-07-20 21:28   
original issue fixed, a couple other links remain.

please leave the ticket open until they've been addressed.
(0014741)
Christian Grothoff   
2019-07-23 20:02   
Leaving open as requested, but removing from 0.11.6.
(0014795)
sva   
2019-08-18 23:37   
List was today 33 entries long, and is now 5 entries long:
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.11.6.tar.gz.sig on https://gnunet.org/en/
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.11.6.tar.gz.sig on https://gnunet.org/en/index.html
=> christian knows already

ircs://chat.freenode.net:6697/#gnunet
=> not a broken link, just the link-checker cant read it

https://old.gnunet.org/bot/log/gnunet
=> is there any other place to find that? Other "old.gnunet.org" mentiones I referred to archive.org

http://sreeharsha.totakura.in
=> might come back again at some time.
(0014802)
Christian Grothoff   
2019-08-23 09:42   
I think the link to sreeharsha should be removed, the site has been down for a while.
old.gnunet.org: also dead, won't come back => please remove the link.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5846 [libextractor] extract minor always 2019-08-21 09:31 2019-08-23 09:39
Reporter: jianglin Platform: linux  
Assigned To: Christian Grothoff OS: ubuntu  
Priority: high OS Version: 16.4  
Status: resolved Product Version: 1.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.10  
    Target Version: 1.10  
Summary: A heap-buffer-overflow vulneribility in function EXTRACTOR_dvi_extract_method in dvi_extractor.c
Description: In EXTRACTOR_dvi_extract_method function, it read klen from file, so a crafted file can set klen to an invalid value. When exceeding the valid size, it will cause an overflow and trigger a crash in the code.
Tags: Error
Steps To Reproduce: extract -i ../crashes/EXTRACTOR_dvi_extract_method@dvi_extractor.c_264-5___heap-buffer-overflow
Additional Information:
Attached Files: EXTRACTOR_dvi_extract_method@dvi_extractor.c_264_heapbufferoverflow.md (3,815 bytes) 2019-08-21 09:31
https://bugs.gnunet.org/file_download.php?file_id=847&type=bug
EXTRACTOR_dvi_extract_method@dvi_extractor.c_264-5___heap-buffer-overflow (112 bytes) 2019-08-21 09:31
https://bugs.gnunet.org/file_download.php?file_id=848&type=bug
EXTRACTOR_dvi_extract_method@dvi_extractor.c_264_heapbufferoverflow(1).md (4,210 bytes) 2019-08-21 12:11
https://bugs.gnunet.org/file_download.php?file_id=849&type=bug
Notes
(0014800)
jianglin   
2019-08-21 12:10   
the data points to a chunk whose size is 129, but when tring to read 249 triggers a heap-over-flow.
pwndbg> malloc_chunk data-0x10
0x6072a0 FASTBIN {
  prev_size = 0,
  size = 129,
  fd = 0xf914f9f9fffe02f7,
  bk = 0xf9f9f9f9f9f9f9f9,
  fd_nextsize = 0xe8f9f9fffffffff8,
  bk_nextsize = 0xf9f9f9f9f9f9f903
}
pwndbg> p klen
$4 = 249
(0014801)
Christian Grothoff   
2019-08-23 09:38   
Fixed in 1ecee9a..756ba06, thanks for reporting!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5845 [Taler] wallet (WebExtensions) minor have not tried 2019-08-20 17:57 2019-08-20 17:57
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.7  
Summary: re-design, implement and properly test wallet DB garbage collection
Description: The current garbage collection code is broken, and has been removed. In particular, it was too over-eager, and deleted stuff that we still needed, such as proposals that were downloaded but not confirmed in the last session.

It is also not clear that the garbage collection should run on every start, as opposed to when the wallet database grows above a certain size.

Furthermore, we might want to prompt the user for a backup before we run GC.
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:
5800 [GNUnet] webpage minor have not tried 2019-07-11 15:27 2019-08-18 23:40
Reporter: ng0 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: spellcheck gnunet.org
Description: Hi,

in addition to the spelling errors already reported, I saw a couple more on /engage. It's not bad, but someone should make an effort and go through the pages of the website and fix the errors introduced.
Tags: low hanging fruit
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014666)
ng0   
2019-07-11 15:29   
(Last edited: 2019-07-11 16:31)
More appropriately would be to rewrite parts of the website to be more idiomatic, but a grammar fix might be easier depending on your knowledge and abilities.

(0014796)
sva   
2019-08-18 23:40   
Fixed 2 typos and made 2 words from a germanstyle to english-style. What else is there to fix?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5844 [Taler] wallet (WebExtensions) minor have not tried 2019-08-18 21:07 2019-08-18 21:07
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:  
Summary: use wrapper types instead of raw strings
Description: Instead of using e.g.

  contractHash: string

we should have wrapper types for everything. As TS doesn't support nominal typing (but only structural typing), we need to name the member of the wrapper structure according to its type. Thus the above becomes

  contractHash: HashCode

which is just an alias for

  contractHash: { sha512Hash: string }

To implement this without having to duplicate all structs, the JSON validator (checkable.ts) needs to support wrapping parsed JSON in these wrappers.
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:
5842 [secushare] groupchat minor have not tried 2019-08-18 16:13 2019-08-18 16:43
Reporter: xrs 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.1  
Summary: Create method for sending a message
Description: Messages are sent to the next group member in the ordered list. If the sending fails, the next member will be tried.
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:
5843 [secushare] groupchat minor have not tried 2019-08-18 16:42 2019-08-18 16:42
Reporter: xrs 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.1  
Summary: Create distributed state protocol
Description: - group owner has exclusive right to change the state
- state changes are distributed as messages
- every message has an ID and a pointer to the previous message
- state updates are sent by the group owner to the available group members
- messages can be replayed for syncing the state by a member after a reconnect

state cointains
- group ID
- list of group members
- list of group owners
- group name (optional)
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:
5841 [secushare] groupchat minor have not tried 2019-08-18 15:52 2019-08-18 15:54
Reporter: xrs 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.1  
Summary: Add method for creating a group
Description: Group owner starts the process:
- create group ID
- add peer IDs as new group members
- group owner's peer sends an invitation message to new group members

Group members:
- receive inivitation message
- extract peer iD list and create group with group ID
- send ack over group (ring topology)

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:
5836 [secushare] groupchat minor always 2019-08-18 14:39 2019-08-18 14:39
Reporter: xrs 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.1  
Summary: Add alarm if nick was mentioned
Description: For now this works only for
- simpleterminal/fish
- simpleterminal/bash

This needs to work on different systems, with different terminals and shells.

You can add a new alarming method groupchat.nim:processServerMessages().
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: