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-19 17:42
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: 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.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5901 [libeufin] sandbox minor have not tried 2019-09-19 16:15 2019-09-19 16:15
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: 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-09-19 16:10
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: urgent OS Version:  
Status: assigned 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.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5884 [libeufin] General minor have not tried 2019-09-09 13:47 2019-09-19 16:09
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
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:
5900 [libeufin] sandbox minor have not tried 2019-09-19 01:59 2019-09-19 01:59
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: 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:
There are no notes attached to this issue.


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-09-18 15:43
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: 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!


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:
5864 [Taler] other feature have not tried 2019-08-30 22:35 2019-09-17 21:03
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:  
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:
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:
5692 [Taler] mechant backend minor have not tried 2019-04-18 17:57 2019-09-17 20:50
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:  
    Target Version:  
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:
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:
5896 [GNUnet] transport service minor have not tried 2019-09-16 12:31 2019-09-16 12:31
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:
There are no notes attached to this issue.


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:
5787 [Taler] bank (demonstrator) minor have not tried 2019-06-30 23:07 2019-09-16 09:50
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci 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: 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:
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-09-16 09:50
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci 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: 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 ;-).


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-09-16 09:47
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: 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.


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-09-16 09:42
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: /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?


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:
5862 [Taler] other tweak have not tried 2019-08-30 16:08 2019-09-16 09:17
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.6  
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:
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:
5895 [Taler] deployment and operations minor have not tried 2019-09-14 20:17 2019-09-14 20: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: 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:
There are no notes attached to this issue.


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:
5894 [GNUnet] build process minor have not tried 2019-09-13 19:38 2019-09-13 19:38
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: 0.11.7  
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'
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:
5893 [GNUnet] build process minor have not tried 2019-09-13 19:35 2019-09-13 19:35
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: 0.12.0  
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-09-13 02:18
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.11.7  
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:
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:
5881 [libeufin] General minor have not tried 2019-09-09 13:37 2019-09-12 13:32
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: 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.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5880 [libeufin] General minor have not tried 2019-09-09 13:36 2019-09-12 13:32
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: look at ebics-java-client
Description: https://github.com/uwemaurer/ebics-java-client
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:
5891 [GNUnet] build process minor have not tried 2019-09-11 16:00 2019-09-11 17:06
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: 0.11.7  
    Target Version: 0.11.7  
Summary: what is terminos.h?
Description: We don't include terminos.h or termios.h in any part of the source.
But we check for terminos.h (typo?) in configure.ac.

Is this a typo (termios.h) or did we use this at some point?

This results in:

configure:27844: checking terminos.h usability
configure:27844: clang -c -fno-strict-aliasing -Wall -g -O0 -Wno-address-of-pack
ed-member -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include conftest.c >
&5
conftest.c:41:9: warning: 'INCLUDE_MANPAGES' macro redefined [-Wmacro-redefined]
#define INCLUDE_MANPAGES 0
        ^
conftest.c:40:9: note: previous definition is here
#define INCLUDE_MANPAGES 1
        ^
conftest.c:100:9: warning: 'HAVE_LIBCURL' macro redefined [-Wmacro-redefined]
#define HAVE_LIBCURL 0
        ^
conftest.c:66:9: note: previous definition is here
#define HAVE_LIBCURL 1
        ^
conftest.c:192:10: fatal error: 'terminos.h' file not found
#include <terminos.h>
         ^~~~~~~~~~~~
2 warnings and 1 error generated.
configure:27844: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "gnunet"
| #define PACKAGE_TARNAME "gnunet"
| #define PACKAGE_VERSION "0.11.6"
| #define PACKAGE_STRING "gnunet 0.11.6"
| #define PACKAGE_BUGREPORT "bug-gnunet@gnu.org"
| #define PACKAGE_URL ""
| #define PACKAGE "gnunet"
| #define VERSION "0.11.6"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1


etc
Tags:
Steps To Reproduce: read config.log
Additional Information:
Attached Files:
Notes
(0014889)
ng0   
2019-09-11 17:06   
probably resolved, nothing is using this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5468 [GNUnet] util library minor always 2018-11-04 13:01 2019-09-11 16:18
Reporter: ch3 Platform:  
Assigned To: schanzen 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.11.7  
Summary: Util testcase fails when run in parallel to gnunet instance
Description: test_os_start_process fails when having a gnunet instance with default config running at the same time.
Tags:
Steps To Reproduce: Run util tests.
Additional Information: Log of test:

Nov 02 16:11:12-813064 util-service-10772 WARNING `bind' failed for `/tmp//gnunet-system-runtime//gnunet-service-resolver.sock': address already in use
Nov 02 16:11:12-813175 resolver-10772 ERROR `bind' failed at service.c:1288 with error: Address already in use
Nov 02 16:11:12-813198 resolver-10772 ERROR Could not bind to any of the ports I was supposed to, refusing to run!
FAIL test_os_start_process (exit status: 141)
Attached Files:
Notes
(0014774)
schanzen   
2019-08-08 19:21   
I do not think this can be considered as a bug as (apparently) your already running instance is also listening on the UNIX socket in /tmp.
Why is that? Are you sure you started it "normally"?
(0014887)
schanzen   
2019-09-11 16:18   
Fixing as this is expected behaviour.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5823 [GNUnet] cadet service feature N/A 2019-08-01 22:02 2019-09-11 16:17
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: 0.11.7  
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:
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:
5409 [Taler] codeless payments minor have not tried 2018-07-21 00:11 2019-09-11 15:16
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.6  
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:
5877 [GNUnet] other minor have not tried 2019-09-06 09:15 2019-09-11 14:53
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: 0.11.7  
    Target Version: 0.11.7  
Summary: remove plibc, drop severely unmaintained win32 support
Description: remove 'plibc.h', all #includes of plibc.h, and then fix the
compiler errors that arise, usually replacing things like "STRERROR"
with "strerror".

See https://lists.gnu.org/archive/html/gnunet-developers/2019-09/msg00002.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014884)
ng0   
2019-09-11 14:53   
Done in commits from 6e599264ad13e8fc105493d74d7c11d46f8739ed leading up to c4ae64d7988d03a10fd43cf8d0fa81399382fcb3


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:
5782 [GNUnet] GNS minor always 2019-06-27 00:48 2019-09-06 23:19
Reporter: rockxo Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: feedback Product Version: 0.11.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.11.7  
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:
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:
5807 [GNUnet] reclaim feature have not tried 2019-07-19 11:21 2019-09-05 16:04
Reporter: schanzen Platform:  
Assigned To: pagkopoulou OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.11.7  
    Target Version: 0.11.7  
Summary: Implement OpenID PKCE in reclaim
Description: See here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.1.1
And here: https://www.oauth.com/oauth2-servers/pkce/
And here: https://tools.ietf.org/html/rfc7636

While not security-relevant for reclaim, the protocol must support it to stay compliant.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014862)
schanzen   
2019-09-05 16:04   
Fixed.


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:
5868 [libmicrohttpd] other text N/A 2019-08-31 16:25 2019-09-04 13:34
Reporter: pombredanne Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: current SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.67  
    Target Version: 0.9.67  
Summary: The GPL "with ecos" extension is a modified GPL
Description: FWIW, the GPL text included in this GNU project at https://www.gnu.org/software/libmicrohttpd/manual/html_node/GNU-GPL-with-eCos-Extension.html is a modified GPL which is rather uncommon (unless of course approved by the FSF).
The text of the GPL itself cannot be modified in general. The ecos exception should be added outside of the GPL text proper and the GPL text left as-is to comply with the GPL itself.

FYI, libmicrohttpd is the only GNU project that I ever saw modify the GPL text.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014850)
Christian Grothoff   
2019-09-04 07:02   
So what? libmicrohttpd is dual-licensed, also under LGPLv3+. This may be unusual, but not a bug.
(0014851)
Christian Grothoff   
2019-09-04 07:03   
Oh, and in case you're worried about GPL-compatibility: because MHD is under LGPLv3+, it is automatically also compatible with GPLv3+.
(0014852)
pombredanne   
2019-09-04 08:12   
I reported it as a bug because as the GPL states at the very start of its license text:

__ "Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed." __

So my point that it is fine to add the eCos exception text OUTSIDE of the unmodified and pristine GPL text.
But this is NOT OK to modify the GPL text to add INSIDE an extra section 14 with the eCos exception.

eCos does not do this, and there not a single other GNU project that does this: libmicrohttpd is completely unique and IMHO not complying with the GPL.
And the reason nobody does this is is that the GPL license prohibits to change the license text itself.

If you think of it, it kind of make sense, otherwise there would be many copies of the GPL with different terms floating around and that would be rather difficult to handle.
(0014854)
Christian Grothoff   
2019-09-04 13:33   
Ah, now I understand your point. Fixed in b91e6f71..d44a1870


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:
5098 [Taler] Web site(s) tweak have not tried 2017-06-29 11:29 2019-09-03 16:56
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci 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?


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:
5840 [Taler] deployment and operations minor have not tried 2019-08-18 15:24 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:  
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:
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:
5860 [Taler] wallet (WebExtensions) minor have not tried 2019-08-29 10:07 2019-08-29 10: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: 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:
There are no notes attached to this issue.


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:
5826 [libmicrohttpd] build system minor always 2019-08-13 09:29 2019-08-28 09:12
Reporter: TuxHandwerker Platform: X86_64  
Assigned To: Christian Grothoff OS: CentOS  
Priority: normal OS Version: 7.6  
Status: assigned Product Version: 0.9.66  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Software tests fails using gcc 8.3.1
Description: make check will fail's with:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -fvisibility=hidden -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c -o test_md5.o test_md5.c
test_md5.c: In function 'test1_str':
test_md5.c:226:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units1_num; i++)
   ^
test_md5.c:226:3: note: use option -std=c99 or -std=gnu99 to compile your code
test_md5.c: In function 'test1_bin':
test_md5.c:243:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units2_num; i++)
   ^
test_md5.c: In function 'test2_str':
test_md5.c:261:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units1_num; i++)
   ^
test_md5.c: In function 'test2_bin':
test_md5.c:280:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units2_num; i++)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: config.log (221,228 bytes) 2019-08-13 09:29
https://bugs.gnunet.org/file_download.php?file_id=846&type=bug
Notes
(0014781)
TuxHandwerker   
2019-08-13 09:41   
set -std=c99 will allow to pass the test_md5 tests, but result later in an coredump:
PASS: test_str_compare
PASS: test_str_to_value
PASS: test_str_token
PASS: test_http_reasons
PASS: test_md5
PASS: test_sha256
PASS: test_start_stop
PASS: test_daemon
PASS: test_options
PASS: test_upgrade
../../build-aux/test-driver: line 107: 13539 Aborted (core dumped) "$@" > $log_file 2>&1
FAIL: test_upgrade_large
PASS: test_upgrade_tls
../../build-aux/test-driver: line 107: 13652 Aborted (core dumped) "$@" > $log_file 2>&1
FAIL: test_upgrade_large_tls
PASS: test_postprocessor
PASS: test_postprocessor_large
PASS: test_postprocessor_amp
PASS: test_shutdown_select
PASS: test_shutdown_poll
(0014782)
TuxHandwerker   
2019-08-13 09:43   
Hint: I added this patch, to build it.
https://git.gnunet.org/libmicrohttpd.git/commit/?id=b84ee1fa41c53c43aa7ed1583c36af5cb7c77a0f
(0014807)
Christian Grothoff   
2019-08-24 00:06   
55618b10..8eae5667 fixes the c99 issues reported in test_md5.c.
(0014808)
Christian Grothoff   
2019-08-24 00:08   
As for the crashes, Git master fixes some issues with respect to the upgrade_large tests -- could you please try if the latest version fixes those crashes? If not, a valgrind report or stack trace from gdb would be helpful...
(0014809)
TuxHandwerker   
2019-08-26 09:44   
test_sha256.c need also patching for gcc 8.1 without explicit set -std=c99 call:
test_sha256.c: In function 'test1_str':
test_sha256.c:251:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units1_num; i++)
   ^
test_sha256.c:251:3: note: use option -std=c99 or -std=gnu99 to compile your code
test_sha256.c: In function 'test1_bin':
test_sha256.c:268:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units2_num; i++)
   ^
test_sha256.c: In function 'test2_str':
test_sha256.c:286:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units1_num; i++)
   ^
test_sha256.c: In function 'test2_bin':
test_sha256.c:305:3: error: 'for' loop initial declarations are only allowed in C99 mode
   for (unsigned int i = 0; i < units2_num; i++)
   ^
(0014810)
TuxHandwerker   
2019-08-26 10:00   
The git master version of test_upgrade_large don't compile:
test_upgrade_large.c: In function 'run_usock':
test_upgrade_large.c:708:23: error: 'MHD_UPGRADE_ACTION_CORK_OFF' undeclared (first use in this function)
                       MHD_UPGRADE_ACTION_CORK_OFF);
                       ^
test_upgrade_large.c:708:23: note: each undeclared identifier is reported only once for each function it appears in
test_upgrade_large.c: In function 'kick_select':
test_upgrade_large.c:583:11: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
     write (kicker[1], "K", 1);
           ^
test_upgrade_large.c: In function 'run_mhd_select_loop':
test_upgrade_large.c:940:9: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
         (void) read (kicker[0], drain, sizeof (drain));
         ^
test_upgrade_large.c: In function 'run_mhd_epoll_loop':
test_upgrade_large.c:1012:9: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result]
         (void) read (kicker[0], drain, sizeof (drain));
         ^
make[3]: Leaving directory `/builddir/build/BUILD/gvm-helper-0.0.1/libmicrohttpd-0.9.66/src/microhttpd'
make[2]: Leaving directory `/builddir/build/BUILD/gvm-helper-0.0.1/libmicrohttpd-0.9.66/src/microhttpd'
make[3]: *** [test_upgrade_large-test_upgrade_large.o] Error 1
make[2]: *** [check-am] Error 2
make[1]: make[1]: Leaving directory `/builddir/build/BUILD/gvm-helper-0.0.1/libmicrohttpd-0.9.66/src'
(0014811)
Christian Grothoff   
2019-08-26 11:17   
That's strange, can you try building using 'make install' instead of just 'make'?
(0014812)
TuxHandwerker   
2019-08-26 11:31   
It will only happens at the test stage called via "make check".
The normal build an install stage will work, but the test stage will fails.
(0014813)
Christian Grothoff   
2019-08-27 15:20   
I can only imagine that somehow you have an 'old' version of microhttpd.h installed somewhere on your system, and somehow gcc finds that one before the one from src/include/. Please check your system for outdated 'microhttpd.h' files.
(0014820)
TuxHandwerker   
2019-08-28 09:09   
Today I tried the last git master version.
Because of note https://bugs.gnunet.org/view.php?id=5826#c14809, it must use "-std=c99" to build it.
But the tests are still fails with core dump.
For test_upgrade_large with:
(gdb) where
#0 0x00007f670e0f42c7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007f670e0f59b8 in __GI_abort () at abort.c:90
#2 0x00005604c7f7ce45 in recv_hdr (sock=0x5604c9a61760) at test_upgrade_large.c:641
#3 run_usock_client (cls=0x5604c9a61760) at test_upgrade_large.c:736
#4 0x00007f670e492dd5 in start_thread (arg=0x7f670cc73700) at pthread_create.c:307
#5 0x00007f670e1bc02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(0014821)
TuxHandwerker   
2019-08-28 09:12   
(gdb) bt full:
#0 0x00007f670e0f42c7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
        resultvar = 0
        pid = 14965
        selftid = 14984
#1 0x00007f670e0f59b8 in __GI_abort () at abort.c:90
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x7f670cc72e40, sa_sigaction = 0x7f670cc72e40}, sa_mask = {__val = {0, 0, 140080598064141, 0, 94578534766392, 39, 70368744177669, 16, 140080572739280,
              140080572739216, 94578534763353, 0, 140080598063773, 1, 140080572739303, 1}}, sa_flags = 5, sa_restorer = 0x801000}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00005604c7f7ce45 in recv_hdr (sock=0x5604c9a61760) at test_upgrade_large.c:641
        i = 0
        next = 13 '\r'
        c = 0 '\000'
        ret = -1
#3 run_usock_client (cls=0x5604c9a61760) at test_upgrade_large.c:736
        sock = 0x5604c9a61760
#4 0x00007f670e492dd5 in start_thread (arg=0x7f670cc73700) at pthread_create.c:307
        __res = <optimized out>
        pd = 0x7f670cc73700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140080572741376, -3442794773719681955, 0, 8392704, 0, 140080572741376, 3384074596664603741, 3384069150701253725}, mask_was_saved = 0}}, priv = {pad = {0x0,
              0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
#5 0x00007f670e1bc02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111


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:
5822 [GNUnet] cadet service major always 2019-08-01 21:43 2019-08-28 08: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: 0.11.7  
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:
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:
5829 [GNUnet] other minor always 2019-08-17 15:46 2019-08-23 09:52
Reporter: rexxnor 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.11.7  
    Target Version: 0.11.7  
Summary: Adding a PHONE record using gnunet-namestore-gtk is not possible
Description: Adding PHONE records to an existing zone using gnunet-namestore-gtk does not work. Normally when selecting the record type in the dropdown menu after creating a label an input mask pops up where the values can be set. This does not happen when selecting "PHONE" from the dropdown menu.
Tags: gnunet-gtk
Steps To Reproduce: Add a zone "test" in gnunet-namestore-gtk or using gnunet-identity.
Within gnunet-namestore-gtk add a label with the name "foo" and select "PHONE" from the dropdown menu.
No entry mask opens.
Additional Information:
Attached Files:
Notes
(0014803)
Christian Grothoff   
2019-08-23 09:51   
Fixed in 78149c8a1..839005f05


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:
5808 [GNUnet] rest service minor have not tried 2019-07-19 11:25 2019-08-20 13:05
Reporter: schanzen Platform:  
Assigned To: pagkopoulou OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.11.7  
    Target Version: 0.11.7  
Summary: Allow to set config options in plugin
Description: Currently, the config is read only. It should be possible to set config values.
(Often a restart is required after that but first things first)

Relevant files: src/rest/plugin_rest_config.c

We need to add a POST/PUT callback which allows to set config options.
The file src/util/gnunet-config.c contains the logic on how to modify config parameters using the config API for reference.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014797)
schanzen   
2019-08-20 13:05   
Fixed in 7c484d98416b489072cb728f614e17186a12c81c
(0014798)
schanzen   
2019-08-20 13:05   
Version
(0014799)
schanzen   
2019-08-20 13:05   
Fixed


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:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5834 [secushare] groupchat minor have not tried 2019-08-18 13:46 2019-08-18 13:46
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: Message state indicator
Description: My messages should appear immediately in the conversation with a message state indicator. The indicator should represent the following states:

- sending
- acknowledged
- failed
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5832 [GNUnet] identity service crash always 2019-08-17 23:39 2019-08-18 13:44
Reporter: rexxnor 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.11.7  
    Target Version: 0.11.7  
Summary: gnunet-fs-gtk crashes on startup
Description: $ gnunet-fs-gtk
Aug 17 18:38:53-917793 gnunet-fs-gtk-13510 ERROR Assertion failed at identity_api.c:599. Aborting.
Aborted (core dumped)

This is with gnunet commit d83a189f7 and gnunet-gtk version bd150825

I tried reproducing this in a docker container but obviously failed because there is no X server in a docker container.
Tags: gnunet-gtk
Steps To Reproduce: Install GNUnet with prefix /usr
Install gnunet-gtk with prefix /usr and --with-gnunet above
Start gnunet-fs-gtk
Additional Information:
Attached Files:
Notes
(0014794)
Christian Grothoff   
2019-08-18 13:44   
Should have already been fixed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5831 [Taler] other minor have not tried 2019-08-17 19:33 2019-08-17 19:33
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 thread support in akono
Description: Currently akono (the android-kotlin-nodejs binding API) does not support threads.

This requires some major changes, as right now we implement the bindings in a rather hacky way by setting our akono-specific functions for module-loading and IPC on the global context. However, newly created worker context won't have these binding functions available.

The right way to implement this is to register these glue functions as a module via node_module_register and apply it to the global object in the third party bootstrapping code, which we have to add to node when compiling it.

Supporting threads would increase the perceived performance, as crypto operations wouldn't block stuff like balance queries.
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:
5512 [Taler] wallet (WebExtensions) major always 2019-01-25 18:32 2019-08-17 18:51
Reporter: davidak Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: feedback Product Version: 0.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: Wallet adds only 2000000 KUDOS and get stuck
Description: I have withdrawn a huge ammount of KUDOS from the bank into my wallet, multiple times.

It don't appear directly in the wallet, but it seems that every coin is added by itself, so it takes a very long time until all this KUDOS are actually added.

It appears that the wallet get stuck after adding 2000000 coins to the wallet. It starts again when i disable the browser extension and enable it again.

(Since Taler should work like cash, nobody would have such amounts in ones wallet)
Tags:
Steps To Reproduce: 1. withdraw 10000000 KUDOS from the bank
2. see if they all get added to your wallet balance
Additional Information: Chromium 71.0.3578.98
Extension 0.5.1
Attached Files: Screenshot from 2019-01-25 16-18-58.png (186,802 bytes) 2019-01-25 18:32
https://bugs.gnunet.org/file_download.php?file_id=796&type=bug
Screenshot from 2019-01-25 17-31-48.png (107,474 bytes) 2019-01-25 18:32
https://bugs.gnunet.org/file_download.php?file_id=797&type=bug
Screenshot from 2019-04-16 21-48-32.png (366,773 bytes) 2019-04-16 21:52
https://bugs.gnunet.org/file_download.php?file_id=827&type=bug
Notes
(0013540)
Christian Grothoff   
2019-01-31 19:16   
Do you get any interesting log messages in your debug logs?

Oh, and as for this being slow, that's simply because the denominations that were setup are just for much smaller amounts. But of course if the wallet does get stuck, this is still a bug that needs fixing.
(0014297)
davidak   
2019-04-16 21:52   
>Do you get any interesting log messages in your debug logs?

like this? (see screenshot)
(0014793)
Florian Dold   
2019-08-17 18:51   
In the screenshot, the errors are related to the deposit operation, and not withdraw.

If the bug is in the wallet, it should be easier to show one 0004738 and 0004108 are resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5418 [Taler] wallet (WebExtensions) block always 2018-08-02 12:40 2019-08-17 18:48
Reporter: Torsten Grothoff Platform: Firefox, Chromium/Chrome  
Assigned To: Florian Dold OS:  
Priority: immediate OS Version:  
Status: resolved Product Version: 0.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.6  
Summary: test.taler.net withdraw _ test kudos errors
Description: Error: Property type missing on (root) of WireDetailJson
Tags: ASIGNED: Florian Dold, bug, Error, Taler, taler.net, test, test.taler.net, Withdraw
Steps To Reproduce: Go to bank.test.taler.net/profile
Click on "Select Exchange Provider"
See the bug
Additional Information:
Attached Files:
Notes
(0014792)
Florian Dold   
2019-08-17 18:48   
This was caused by a change in the /wire format, and has been fixed in the wallet a while ago.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5541 [GNUnet] other block N/A 2019-02-04 20:22 2019-08-17 18:13
Reporter: dvn Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Add KVM and libvirt to firefly.gnunet.org
Description: For the purpose of using arbitrary job runners - for CI and other purposes - it is preferred to have some form of environment isolation, and the ability to run various kernels. KVM and libvirt are what I would recommend and prefer, due to availability of packages, documentation, and community support.

The server `firefly.gnunet.org`, is running GuixSD. We need to require some new services in its server config.

I will attach a full example config of a similar setup I've used in the past.

I believe the relevant lines are just these:

 9 (use-service-modules networking mcron desktop virtualization)
...
 52 (supplementary-groups '("wheel" "netdev"
 53 "audio" "video" "kvm" "libvirt"))
...
 71 (service libvirt-service-type
 72 (libvirt-configuration
 73 (unix-sock-group "libvirt")))
 74 (service virtlog-service-type
 75 (virtlog-configuration
 76 (max-clients 1000)))
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: firefly-kvm-config-example.scm (2,726 bytes) 2019-02-04 20:22
https://bugs.gnunet.org/file_download.php?file_id=804&type=bug
Notes
(0014059)
ng0   
2019-02-26 13:33   
Thanks, should be done today.

I'm only stuck with firefly building almost everything from source because the commit is too old (0.16.0 release now).
(0014061)
ng0   
2019-02-26 14:50   
Done. Can you confirm functionality?
(0014068)
ng0   
2019-02-26 16:12   
Note, ch3 is running tests on firefly right now, so if it's still occupied, wait with anything resource intensive (or wait in general).
(0014778)
schanzen   
2019-08-08 19:46   
Is this still an issue?
(0014784)
ng0   
2019-08-17 11:30   
Somehow I got an 'requested feedback' Email about this.
Please ask ch3 yourself, I haven't been active on the servers in the last months.
(0014785)
ng0   
2019-08-17 11:30   
Though we no longer use GuixSD, so maybe this is resolved? (others will know more)
(0014791)
dvn   
2019-08-17 18:11   
This issue is resolved. KVM and libvirt are installed on firefly.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5828 [Taler] merchant backend API (HTTP specification) minor have not tried 2019-08-17 14:59 2019-08-17 14:59
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: merchant backend should have an API to query metadata such as currency
Description: This is required for integration with PoS terminals that use the backed.
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:
4853 [Taler] taler-wallet-lib tweak have not tried 2017-01-12 13:44 2019-08-17 14:56
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: improve developer experience for error messages
Description: Right now we show an alert and the developer console has the full error message.

Experience has shown that this confuses developers, instead we should show the error on the page and maybe link to some help page on api.taler.net
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011863)
Christian Grothoff   
2017-02-26 03:07   
(Last edited: 2017-02-26 03:09)
Definitively no help pages on taler.net; we should include the help pages with the wallet. That is, if it is at all user-visible. If this is purely about helping a web shop developer, api.taler.net *might* be OK.

(0014790)
Florian Dold   
2019-08-17 14:56   
We are currently not using or maintaining the taler-wallet-lib, as everything is handled either via HTTP status codes or by URI schemes.

Creating a better supported and properly packaged version of the old taler-wallet-lib is tracked in 0005783


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5783 [Taler] other minor have not tried 2019-06-27 01:12 2019-08-17 14:55
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: provide a properly packaged JS library for interacting with browser-integrated wallets
Description: Currently on our own sites we only use CSS-based detection. We had the old taler-wallet-lib, but it was a single ts-file lying around somewhere in web-common.

Instead, we should provide a properly packaged taler-wallet-lib, which is also packaged on NPM and the usual CDNs.
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:
5362 [Taler] taler-wallet-lib minor have not tried 2018-06-23 19:51 2019-08-17 14:54
Reporter: shivamkohli 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: Detection of wallet not working
Description: While performing payments, the presence of wallet in the browser is not detected.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013395)
Marcello Stanisci   
2018-12-07 18:58   
I have been testing the wallet quite a lot in the last days, and I couldn't notice this reported behaviour. May this issue be closed?
(0014789)
Florian Dold   
2019-08-17 14:54   
Neither shivam or I was able to reproduce this issue. Seems to be fixed in the current wallet.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5036 [Taler] wallet (WebExtensions) feature have not tried 2017-05-28 22:45 2019-08-17 14:49
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: create an implementation for IndexedDB to be used outside of the browser
Description: Existing node implementations are terrible. We should have at least a simple in-memory implementation for test cases, implementing the subset of IndexedDB that our query abstraction uses.

Later we can implement it for sqlite3.

The IndexedDB API is pretty reasonable, this shouldn't be too much work (famous last words ...).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012175)
Christian Grothoff   
2017-05-28 22:51   
Is this for testing, for apps or for both?
(0012176)
Florian Dold   
2017-05-28 22:55   
For both. As of today, we can run tests that use WebWorkers (and thus test the crypto thread) in NodeJs. This uses a small module to translate WebWorkers to NodeJS subprocesses. I also want to be able to run tests that use the database outside the browser, for performance reasons.

Note that the database will still be very small, so this implementation doesn't need to be optimized initially.

Another nice use case might be end-to-end tests without using the browser, where we do a withdraw and spend using a command line version of the TypeScript wallet. This allows us to cheaply run test cases, right now the selenium test cases basically kill taler.net because they hog so much memory (due to Chrome/Selenium).
(0012177)
Christian Grothoff   
2017-05-28 22:58   
Ok, then let's schedule this for 0.6 (obviously could be done earlier, but 0.6 is where we want to have really good testing).
(0014788)
Florian Dold   
2019-08-17 14:49   
IndexedDB with file-backed and memory-backed storage is now implemented in the idb-bridge package inside the wallet repo.


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-08-17 12:04
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: 0.12.0  
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:
5751 [GNUnet] webpage feature N/A 2019-06-05 11:22 2019-08-17 02:07
Reporter: Christian Grothoff Platform: i7  
Assigned To: xrs 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:  
    Target Version: 0.11.6  
Summary: videos not findable/accessible
Description: We need a /videos page .
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014633)
ng0   
2019-07-01 13:00   
Either people search on youtube, or our videos are really inaccessible.

One example is that recently someone was searching for more information (without context) and found a talk on youtube.

The videos page, which currently has lots of broken links to archive.org (Question I posed: why archive.org? This is not why we decided to have all of our material in our own infrastructure.), is not satisfactory.

Displaying the videos like images would be good (html5 videos tag).

I'm not sure if at times it could bring more load to the server running the website, but that's yet to be determined.
(0014636)
ng0   
2019-07-03 11:36   
(Last edited: 2019-07-03 11:38)
This has been partially addressed by linking to the git.

However:

- some links are not recognized/ link to video.html
- we have an extra step, and it is not very clear to the uninitiated that the link leads to the video. Inclusion would probably trigger our cross origin policy. Checking them out directly as part of the build process is not ideal, so if we do this it has to be done serverside (to not drive people like myself away from contributing to the website, my up/down speed is very bad at the moment).
- What about an ">> Watch Video" sort of link?

(0014638)
xrs   
2019-07-04 16:04   
video.html was improved. See: https://gnunet.org/en/video.html

Is it acceptable now?
(0014639)
ng0   
2019-07-04 16:08   
The remarks I've made in my previous comment still apply to the version I see on stage.gnunet.org right now.
(0014640)
ng0   
2019-07-04 16:20   
- some links are not recognized/ link to video.html:
   - for example:
     Martin Schanzenbach, "A Censorship-Resistant and Fully Decentralized Naming System",Technische Universität München
(0014641)
ng0   
2019-07-04 16:21   
(Last edited: 2019-07-04 16:21)
which happens because of:
        < li >Martin Schanzenbach, <a href="">"A Censorship-Resistant and Fully Decentralized Naming System",</a>Technische Universität München< /li >

(0014642)
ng0   
2019-07-04 16:24   
For the comment about the ogv files, we might eventually consider converting them into a webm container if ogv is not as well supported as webm. I'm a bit biased because I have the formats all supported here, so I'd have to try some devices of friends.
(0014643)
xrs   
2019-07-04 20:18   
It seems that those video links I found on archive.org are not as source available since the server crashed.

Apart from searching at youtube.com or media.ccc.de I have no idea how to recover them.
(0014644)
ng0   
2019-07-04 20:46   
Richard Stallman, "Copyright vs. Community", Technische Universität München -> (almost?) all talks rms gives are standard. since it had nothing to do with gnunet (why is this here anyway?) we can just remove it in my opinion.

Martin Schanzenbach, "A Censorship-Resistant and Fully Decentralized Naming System",Technische Universität München -> https://media.net.in.tum.de/v/Oberseminar-SS12--Design_and_Implementation_of_a_C

We might probably find the rms talk there too, and the rest of the missing TUM talks.
(0014645)
ng0   
2019-07-04 20:48   
30c3 is easy as well.

Do you want to take on this, or should we split it in half? I do TUM, you do the rest? I haven't looked at how much both of them have missing, but TUM looked like it's close to half of the missing videos.
(0014646)
ng0   
2019-07-04 20:51   
(Last edited: 2019-07-04 20:54)
And the guix talk was totally unrelated, except for it happening at the same conference I see no reason to keep it. It could be that they still mentioned gnunet in 2015, in which case it would still be related.
newer talks are self-hosted by guix iirc (could be that they have this one as well) and no longer related to gnunet (they seem pretty much settled on ipfs now).

(0014647)
Christian Grothoff   
2019-07-04 20:57   
I agree, the Guix and Copyright vs. Community talks could be removed from the list.
(0014648)
xrs   
2019-07-04 21:49   
Ok, made an update on it. Please check again.
(0014649)
ng0   
2019-07-05 00:26   
Looks good!

Minor confusions, as it was too long ago since I've created those repos based on information back then:

Jeff Burdges, Xolotl - A compact mixnet format with stronger forwared secrecy and hybrid anonymity, GNU Hacker Meeting

this is in 2016.
but I filed it in 2015. Was this just a mistake, or was it 2016 all along?


Rest looks good enough, even though I still think we should have a move action oriented statement ("watch video here") or something like that. It's still clear though.
We could have it like this:

< TITLE > (link to slides slides) - watch video here

since we have a good amount of the slides available.

Jeff Burdges, Xolotl - A compact mixnet format with stronger forwared secrecy and hybrid anonymity, GNU Hacker Meeting (foo) - foo

Like this?
(0014650)
ng0   
2019-07-05 00:27   
except that mantis strips out the html... gr
(0014651)
ng0   
2019-07-05 00:28   
Jeff Burdges, Xolotl - A compact mixnet format with stronger forwared secrecy and hybrid anonymity, GNU Hacker Meeting (< link here which then reads just "slides" >) - < link here to the "watch video here" link >
(0014652)
xrs   
2019-07-05 19:40   
Concerning Jeff Burdges presentation.. if you look the video, it states the year at the beginning. If this is correct then you filed it wrong :-)

I think having the title "Videos" and the colored links is quiet obvious. If you don't mind so much, let's close this issue! :-)
(0014659)
xrs   
2019-07-07 21:29   
Concerning Jeff Burdges presentation.. if you look the video, it states the year at the beginning. If this is correct then you filed it wrong :-)

I think having the title "Videos" and the colored links is quiet obvious. If you don't mind so much, let's close this issue! :-)
(0014660)
Christian Grothoff   
2019-07-07 21:31   
(Last edited: 2019-07-07 21:32)
<video width="320" height="240" controls>
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.ogg" type="video/ogg">
Your browser does not support the video tag.
</video>

(0014662)
ng0   
2019-07-08 10:53   
Additionally adding the src URL below the video as part of some information box, can be done later: Year, Description, Language, Link to Slides, Link to original video, license if any, location, event, speaker.
(0014688)
xrs   
2019-07-15 21:46   
Added video tag and a javascript snipped. What do you think?

mkv is not supported by HTML5, thus only downloadable.
(0014689)
xrs   
2019-07-15 21:49   
Oh dear, the content security policy on firefox is enforced. I have to look for another solution. Mhh.
(0014692)
ng0   
2019-07-16 00:04   
I think we (that is, Christian) could change the policy in this case.
(0014693)
ng0   
2019-07-16 00:07   
Huh. Okay, js is one way to do it, but maybe my idea would've been too ad-hoc? I was thinking about displaying each video already ready to play (gets loaded later). More copy-pasta.. so maybe your way is better.
(0014694)
xrs   
2019-07-16 07:26   
Change the CSP is an idea. I need to have a look, how this works and will try some solutions today or tomorrow.

https://content-security-policy.com/
(0014699)
xrs   
2019-07-18 17:11   
Hey ng0,

to make the javascript work I guess we need the following Header-Info in the Apache config:

Header set Content-Security-Policy "script-src 'self';"

It is almost stated like this in https://content-security-policy.com/ at the bottom.

I'll commit a change in half an hour to have "play" and "download" after the items.
(0014700)
Christian Grothoff   
2019-07-18 17:55   
GNUnet.org already has that CSP, are we talking about git.gnunet.org or some other server? Please check the headers you get in the browser!
(0014701)
xrs   
2019-07-18 18:20   
You are right. Maybe what CSP demands is to add the other source domains where the videos are located so that javascript can load those into the video-tag. These are:
- git.gnunet.org
- cdn.media.ccc.de
- audio-video.gnu.org

What about modifying the headers like this?
Header set Content-Security-Policy "script-src 'self'; script-src 'git.gnunet.org'; script-src 'cdn.media.ccc.de'; script-src 'audio-video.gnu.org'"
(0014702)
Christian Grothoff   
2019-07-18 19:03   
Why are we linking to external resources? Generally, we should never do that as ccc.de has no business seeing visitors to gnunet.org, ditto for gnu.org (even if these are known good-actors, I think the policy of never linking in third-party resources is a good one). So please just move those videos into our own Git.

I'll modify the policy to include git.gnunet.org.
(0014703)
Christian Grothoff   
2019-07-18 19:06   
Also, looking at this, you seem to have used JavaScript for the video. 0005751:0014660 explains how to do this _without_ JavaScript, which is really what we should do.
(0014704)
xrs   
2019-07-19 09:11   
Just for clarification: What is mentionioned in 0005751:0014660 was the basis for this change. But displaying a video for every entry is not the proper UX and implies more loading time. That's why I added JS to use one player and change the source. Another KISS-suggestion?

Plus, we offer a download link, see https://stage.gnunet.org.

Linking to external ressources: Yes, Iwould like to have local ressources, too, but migrating videos is another task.
(0014705)
Christian Grothoff   
2019-07-19 10:26   
I disagree, having multiple <video> tags doesn't mean the browser will download them all, so it shouldn't really impact loading time beyond the previews, which are comparatively small. If it really gets too big, we should just have a pager, say every 10-50 videos a sub-page ("1 2 3 next"). And sure, a download link should be there, but you can do that with <video> over the controls anyway. No need for a JS player.

As for linking to external resources: migrating the videos clearly _is_ part of this task, as otherwise we'd have to lower our security by setting the CSP to allow third-party.
(0014706)
xrs   
2019-07-19 16:50   
Okay, thanks for the hints. I think I have a solution in mind for a proper UX design without JS.
(0014740)
Christian Grothoff   
2019-07-23 20:02   
xrs: will this happen shortly, or should we remove this one from RC for 0.11.6?
(0014742)
xrs   
2019-07-23 22:37   
I'll probable commit a change until tomorrow evening.
(0014745)
xrs   
2019-07-24 18:48   
There is a new version. Please help solving the CSP issue.

Concerning video migration: I have no clue how to add a video without cloning the git repo.
(0014746)
Christian Grothoff   
2019-07-24 19:36   
I've hacked on the CSP now, still odd issues remain. As for video migration, what's wrong with cloning the git repos?
(0014747)
xrs   
2019-07-24 19:50   
Thanks!

Cloning the git repos is time and space consuming?
(0014748)
Christian Grothoff   
2019-07-24 20:46   
You could do it locally: ssh xrs@gnunet.org -- then it should be fast. And once you've added the file(s), you can rm the local copy...
(0014783)
xrs   
2019-08-17 02:07   
All mkv videos have been converted to webm. One new video "Big Data, little data, no data" has been added.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5827 [gnURL] General minor random 2019-08-15 14:18 2019-08-15 14:18
Reporter: ng0 Platform: amd64  
Assigned To: OS: NetBSD  
Priority: normal OS Version: 9.99.4  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: test1061 randomly hangs
Description: Example: 2 runs in a row (of make check) are successful. 3rd run:

test 1061...[HTTP proxy CONNECT auth Digest, large headers and chunked data]
^C
 1061: protocol FAILED:
--- log/check-expected 2019-08-15 12:14:19.870023039 +0000
+++ log/check-generated 2019-08-15 12:14:19.869841366 +0000
@@ -2,11 +2,6 @@
 Host: test.remote.haxx.se.1061:8990[CR][LF]
 Proxy-Connection: Keep-Alive[CR][LF]
 [CR][LF]
-CONNECT test.remote.haxx.se.1061:8990 HTTP/1.1[CR][LF]
-Host: test.remote.haxx.se.1061:8990[CR][LF]
-Proxy-Authorization: Digest username="silly", realm="weirdorealm", nonce="12345", uri="test.remote.haxx.se.1061:8990", response="4e23449fa93224834299e7282a70472c"[CR][LF]
-Proxy-Connection: Keep-Alive[CR][LF]
-[CR][LF]
 GET /path/10610002 HTTP/1.1[CR][LF]
 Host: test.remote.haxx.se.1061:8990[CR][LF]
 Accept: */*[CR][LF]

 - abort tests
^Cruntests.pl received SIGINT, exiting
Warning: httptls server unexpectedly alive
^C^CSomebody sent me a SIGINT at ./runtests.pl line 351.
*** Error code 2

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:
5806 [libmicrohttpd] build system major always 2019-07-18 10:04 2019-08-13 10:12
Reporter: TuxHandwerker Platform: x86_64  
Assigned To: Christian Grothoff OS: CentOS  
Priority: normal OS Version: 7.6  
Status: resolved Product Version: 0.9.65  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.67  
    Target Version: 0.9.67  
Summary: 0.9.65 build fails with gnutls
Description: The build fails with:
Making install in microhttpd
make[2]: Entering directory `/builddir/build/BUILD/gvm-helper-0.0.1/libmicrohttpd-0.9.65/src/microhttpd'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c -o libmicrohttpd_la-connection.lo `test -f 'connection.c' || echo './'`connection.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c connection.c -fPIC -DPIC -o .libs/libmicrohttpd_la-connection.o
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c -o libmicrohttpd_la-reason_phrase.lo `test -f 'reason_phrase.c' || echo './'`reason_phrase.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c reason_phrase.c -fPIC -DPIC -o .libs/libmicrohttpd_la-reason_phrase.o
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c -o libmicrohttpd_la-daemon.lo `test -f 'daemon.c' || echo './'`daemon.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -I/builddir/build/BUILD/gvm-helper-0.0.1/libassuan-2.5.3/src -I/builddir/build/BUILD/gvm-helper-0.0.1/libgpg-error-1.36/src -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fno-strict-aliasing -c daemon.c -fPIC -DPIC -o .libs/libmicrohttpd_la-daemon.o
daemon.c: In function 'internal_add_connection':
daemon.c:2527:7: error: unknown type name 'gnutls_init_flags_t'
       gnutls_init_flags_t flags;
       ^
Tags:
Steps To Reproduce:
Additional Information: 0.9.63 will build fine.
CentOS comes with gnutls version 3.3.29-9
Attached Files:
Notes
(0014755)
Christian Grothoff   
2019-07-29 17:53   
Very strange, the C code seems fine (and unchanged!), so likely something related to the build system. Providing config.log may help, as could git bisecting this. I don't have a CentOS at hand myself.
(0014767)
AndreasStieger   
2019-08-02 13:43   
Not strange at all. gnutls_init_flags_t was introduced in GnuTLS 3.5.0:
https://github.com/gnutls/gnutls/commit/f07542836648a3149880505a45b099aef74a8b02
https://github.com/gnutls/gnutls/compare/gnutls_3_4_11...gnutls_3_5_0#diff-cd71deb19a583f81358de42c2768a1e4L318-R375
A change in libmicrohttpd >= 0.9.64 introduced this dependency:
https://git.gnunet.org/libmicrohttpd.git/commit/?id=1917b866996413f09fa88ae0a6169cb9bd7079e8
(0014768)
Christian Grothoff   
2019-08-02 15:46   
I see. I've pushed a likely fix to Git master, could you confirm that this fixes it?
(0014769)
AndreasStieger   
2019-08-02 16:02   
[[https://git.gnunet.org/libmicrohttpd.git/commit/?id=b84ee1fa41c53c43aa7ed1583c36af5cb7c77a0f|b84ee1f]] fixes this issue with 3.3.27 and others.
(0014780)
TuxHandwerker   
2019-08-13 09:16   
Yes,
https://git.gnunet.org/libmicrohttpd.git/patch/?id=b84ee1fa41c53c43aa7ed1583c36af5cb7c77a0f
will fix it.

Thanks


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5825 [GNUnet] transport service minor have not tried 2019-08-10 21:41 2019-08-10 21:41
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: setsockopt SO_NOSIGPIPE can fail after socket accept
Description: I had to modify the network.c code a bit to find that setting the sockopt NOSIGPIPE after accept() often fails in trasport.
This happens only in macos.
After investigating it seems like this happens when the remote peer closes the socket before we set the option.

The behaviour is thus correct but spams the logs with the below warnings (more general).
The questions is if we can ignore the error at least for transport? At least accept it and log it as DEBUG?
Usually, the handling of this event (error in sockopt after accept) is to try and reconnect.

Tags:
Steps To Reproduce:
Additional Information: Aug 10 21:24:30-522872 transport-34891 ERROR Assertion failed at network.c:452.
Aug 10 21:24:30-526849 transport-34891 WARNING `accept' failed at service.c:832 with error: Invalid argument
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5353 [GNUnet] other major always 2018-06-15 19:55 2019-08-08 19:44
Reporter: ng0 Platform:  
Assigned To: OS: Guix and Nix  
Priority: normal OS Version:  
Status: feedback Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: libcurl/libgnurl certificate location needs to be handled in GNUnet code
Description: We need to add the ability to use well-known environment variables to define and/or override system provide certificate stores.

Ee need this to make it to work on Operating Systems and package managers which expose certain flaws.

In my case, I need this fixed in GNUnet for proper Guix and GuixSD integration. gnURL does not seem like the right place to do this. I've tried this a couple of times in the past in Guix and the result was always bad. There's a certain variable we need to be able to accept, at least that is one way to do it.
You could fetch the guix source code (https://git.savannah.gnu.org/cgit/guix.git) and grep for 'curl' and 'CURL_'. There's a couple of places (if I remember correctly) where not only the search-path is adjusted but also the source code of the application gets patched.
Tags:
Steps To Reproduce:
Additional Information: In my case it looks like this, build against most recent gnurl etc (ignore all the other errors, it's not properly integrated yet):

abyayala$ sudo -E gnunet-arm -s
Password:
abyayala$ Jun 15 09:35:28-961830 util-os-installation-6653 WARNING `access' failed on file `/gnu/store/7axjz524qbi4fx95zackdm36b13a0wi3-gnunet-git1/lib//gnunet/libexec/gnunet-auto-share' at os_installation.c:888 with error: No such file or directory
Jun 15 09:35:28-961889 arm-6652 ERROR Failed to start service `gnunet-auto-share'
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
Jun 15 09:35:29-049837 transport-tcp-6670 WARNING `bind' failed for port 2086 (IPv6): address already in use
Jun 15 09:35:29-049975 transport-tcp-6670 WARNING `bind' failed for port 2086 (IPv4): address already in use
Jun 15 09:35:29-050004 util-connection-6670 ERROR `bind' failed at tcp_server_legacy.c:605 with error: Address already in use
Jun 15 09:35:29-444090 hostlist-6658 WARNING Download of hostlist from `http://v10.gnunet.org/hostlist' failed: `Peer certificate cannot be authenticated with given CA certificates'
Fatal: executable iptables not found in approved directories: No such file or directory
Attached Files:
Notes
(0013224)
ng0   
2018-09-05 08:35   
lurchi: As I sometimes forget how things were solved in Nix.. is this reproducible on NixOS? Or do they handle curl differently?
(0013276)
ng0   
2018-10-21 12:12   
I forgot to add this a while back:

https://curl.haxx.se/libcurl/c/CURLOPT_CAPATH.html

https://curl.haxx.se/mail/lib-2016-08/0118.html


This affects both curl and gnurl.

From experience I know that our curl code should pick up the environment variable mentioned there. In Guix they use:

env | grep CURL
CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
(0013290)
ng0   
2018-10-26 13:12   
dvn and lurchi asked me to expand on the information I have on this apparently Guix and Guix-on-GuixSD specific issue.

> why do we experience this CA error on guix and nix but not on eg. Debian?

Aside: Debian and Guix(SD) follow different hierarchies. No one ever bothered to document the hierarchies, but it's not that hard.
The build chroots (of Debian, Nix, and Guix) are also different.
Notable Guix has just the bare minimum, less than Nix even. So Nix != Guix, when you
read the code relating to how the environments are constructed.

Anyway, the situation. I will quote and reference where possible, because a) I've been annoyed enough as a packager by this problem back on Guix and discussions around it, and b) because you will get more than one perspective.


In early 2015 Guix started migrating away from having a built-in ca-path location:
https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00615.html

After the first code for this was implemented, the differences between curl linked against OpenSSL and curl linked against GnuTLS are explained here: https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00127.html

--quote--
> However there’s the complication that all the files of ‘nss-certs’ would
> still be there in addition to the bundle. Hmm.

That's a feature, not a bug. It is more efficient to look up the
individual files by their hash-named symlinks than to read the entire
certificate bundle as one file. The only problem is that some
combinations of software don't yet support this mode.

For example, libcurl (used by git) only supports the single-file when it
is linked with GnuTLS. When linked with OpenSSL it supports both modes.
(This is a limitation of libcurl's backend for GnuTLS, not an inherent
problem with GnuTLS.)
--end quote--

https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00429.html

It has been discussed that p11kit should be used instead of the *deprecated* single file or directory location for systemwide certificates: https://lists.gnupg.org/pipermail/gnutls-devel/2015-February/007442.html
http://gnutls.org/manual/html_node/Verification-using-PKCS11.html


In essence it can be broken down to the reply Ludovic gave here (in this bug report from december 2016, still open):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25240

How do we deal with this as gnunet?
Do we have to deal with this?
If you want to discuss with guix, go ahead. I'm too annoyed by the problem and outcome of past discussions.
(0013360)
Christian Grothoff   
2018-11-22 10:36   
Well, ultimately we indeed have to deal with it, but if Guix doesn't ship with a cert store that curl+gnutls expects/supports, that's just bad. For now, I guess we should hope that GnuTLS will start to support the new format, and then things should start to work again, right?
(0013478)
ng0   
2019-01-27 15:08   
(Last edited: 2019-01-27 15:12)
Here's the take we had in pkgsrc on this:

# Fallback to gnutls preferred CA certificates
CONFIGURE_ARGS+= --without-ca-bundle
CONFIGURE_ARGS+= --without-ca-path
CONFIGURE_ARGS+= --with-ca-fallback

and this makes gnurl pick up gnutls certificates, which are build in with the gnutls package. However, this won't work for guix and nix (I'm 99% sure by experience and exhausting discussions).
This works for pkgsrc building GnuTLS version 3.6.5


In my opinion someone in Nix or Guix should work on this if we don't fix it in gnunet, I'm done with the issue for now. The status quo works for everyone else. I'm considering to look at p11kit again, but that's it.

I hope you can understand that after several packages, many bugs, and countless discussions (and non-functional packages because of this) sometimes over months that I'm done with supporting the idea of how Guix wants to solve their curl problem.

(0013484)
dvn   
2019-01-28 04:13   
With ng0's last comment in consideration, I think we should move this out of the 0.11.0 roadmap.
(0013485)
dvn   
2019-01-28 04:16   
This issue is currently difficult to fix from our perspective - It affects some Nix derived Linux distributions, and we seek feedback on solutions, and/or collaboration downstream maintainers.
(0014777)
schanzen   
2019-08-08 19:44   
Not a blocker. Not urgent. Probably a downstream issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5650 [GNUnet] statistics service minor always 2019-03-16 17:55 2019-08-08 19:41
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.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5776 [GNUnet] other minor always 2019-06-26 00:35 2019-08-08 19:31
Reporter: marado Platform:  
Assigned To: t3sserakt 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: groupchat fails to build
Description: git clone git://gnunet.org/groupchat.git followed by make fails to build, due to some coding style errors.
Tags:
Steps To Reproduce: git clone git://gnunet.org/groupchat.git && cd groupchat && make

fails with

        ... groupchat.nim(81, 21) Error: invalid indentation

I am providing a patch fixing this.
Additional Information: There's no easy information available on how to contribute to groupchat, I am hopeful this is the right way to do it.
Attached Files: 0001-Fixed-coding-style-errors.patch (1,267 bytes) 2019-06-26 00:35
https://bugs.gnunet.org/file_download.php?file_id=837&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5641 [GNUnet] namestore service minor have not tried 2019-03-12 10:17 2019-08-08 19:16
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.11.7  
Summary: REST tests are not executed
Description: Testsscripts exists though.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5638 [GNUnet] rest service minor have not tried 2019-03-12 10:13 2019-08-08 19:16
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.11.7  
Summary: Review REST plugins and APIs (Meta Issue)
Description: We should take a look at the REST plugin APIs and possible change them accordingly.
Further, we should put the API docs into the website.

Child issues of this report will be created on the go.
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:
5640 [GNUnet] GNS minor have not tried 2019-03-12 10:16 2019-08-08 19:15
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.11.7  
Summary: REST tests are not executed
Description: The tests are not defined as test scripts.
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-08-08 19:09
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: 0.11.7  
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.


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-08-04 18:41
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: 0.11.7  
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:
5820 [libextractor] plugins minor always 2019-07-29 12:13 2019-08-02 01:41
Reporter: jetomit Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.10  
    Target Version: 1.10  
Summary: Build fails with exiv2 0.27
Description: The exiv2 plugin fails to build with exiv2≥0.27:

    ../../../src/plugins/exiv2_extractor.cc:183:40: error: missing binary operator before token "("
      183 | #if EXIV2_VERSION >= EXIV2_MAKE_VERSION(0,26,0)
          | ^
    ../../../src/plugins/exiv2_extractor.cc:452:40: error: missing binary operator before token "("
      452 | #if EXIV2_VERSION >= EXIV2_MAKE_VERSION(0,26,0)
          | ^
    ../../../src/plugins/exiv2_extractor.cc:700:23: error: missing binary operator before token "("
      700 | #if EXIV2_MAKE_VERSION(0,23,0) <= EXIV2_VERSION
          | ^
    ../../../src/plugins/exiv2_extractor.cc:186:20: error: conflicting return type specified for ‘virtual long int ExtractorIO::size() const’
      186 | virtual long int size (void) const;
          | ^~~~
    ../../../src/plugins/exiv2_extractor.cc: In member function ‘virtual int ExtractorIO::getb()’:
    ../../../src/plugins/exiv2_extractor.cc:319:55: error: no matching function for call to ‘Exiv2::BasicError<char>::BasicError(int)’
      319 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^
    ../../../src/plugins/exiv2_extractor.cc:319:36: error: invalid conversion from ‘int’ to ‘Exiv2::ErrorCode’ [-fpermissive]
      319 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^~
          | |
          | int
    ../../../src/plugins/exiv2_extractor.cc: In member function ‘virtual void ExtractorIO::transfer(Exiv2::BasicIo&)’:
    ../../../src/plugins/exiv2_extractor.cc:374:53: error: no matching function for call to ‘Exiv2::BasicError<char>::BasicError(int)’
      374 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^
    ../../../src/plugins/exiv2_extractor.cc:374:34: error: invalid conversion from ‘int’ to ‘Exiv2::ErrorCode’ [-fpermissive]
      374 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^~
          | |
          | int
    ../../../src/plugins/exiv2_extractor.cc: In member function ‘virtual Exiv2::byte* ExtractorIO::mmap(bool)’:
    ../../../src/plugins/exiv2_extractor.cc:419:53: error: no matching function for call to ‘Exiv2::BasicError<char>::BasicError(int)’
      419 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^
    ../../../src/plugins/exiv2_extractor.cc:419:34: error: invalid conversion from ‘int’ to ‘Exiv2::ErrorCode’ [-fpermissive]
      419 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^~
          | |
          | int
    ../../../src/plugins/exiv2_extractor.cc: In member function ‘virtual std::string ExtractorIO::path() const’:
    ../../../src/plugins/exiv2_extractor.cc:507:53: error: no matching function for call to ‘Exiv2::BasicError<char>::BasicError(int)’
      507 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^
    ../../../src/plugins/exiv2_extractor.cc:507:34: error: invalid conversion from ‘int’ to ‘Exiv2::ErrorCode’ [-fpermissive]
      507 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^~
          | |
          | int
    ../../../src/plugins/exiv2_extractor.cc: In member function ‘virtual Exiv2::BasicIo::AutoPtr ExtractorIO::temporary() const’:
    ../../../src/plugins/exiv2_extractor.cc:534:53: error: no matching function for call to ‘Exiv2::BasicError<char>::BasicError(int)’
      534 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^
    ../../../src/plugins/exiv2_extractor.cc:534:34: error: invalid conversion from ‘int’ to ‘Exiv2::ErrorCode’ [-fpermissive]
      534 | throw Exiv2::BasicError<char> (42 /* error code */);
          | ^~
          | |
          | int
Tags:
Steps To Reproduce: The Gentoo libextractor package has a patch to fix the issues: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/libextractor/files/libextractor-1.8-exiv2-0.27.patch
Additional Information:
Attached Files:
Notes
(0014758)
Christian Grothoff   
2019-07-29 18:00   
Thanks for reporting, fixed in Git 2fb6d01..1ecee9a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4918 [libmicrohttpd] HTTPS (SSL) feature have not tried 2017-02-22 21:35 2019-08-02 01:39
Reporter: silvioprog 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: mbed TLS support
Description: Hello,

It would be nice to implement the mbed TLS support, because this one is a very TLS project recommended to embedded applications.

Thank you!

P.S.: it seems mongoose library offer mbed support: https://github.com/cesanta/mongoose/tree/master/examples/mbed
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:
4917 [libmicrohttpd] HTTPS (SSL) feature have not tried 2017-02-22 21:29 2019-08-02 01:39
Reporter: silvioprog Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: current SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: OpenSSL support
Description: Hello,

It would be nice to implement OpenSSL support in MHD.

Thank you!
Tags: feature
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012475)
ghaderer   
2017-10-13 14:36   
Hello,

I made changes to support OpenSSL and other TLS engines. You will find my working branch here: https://github.com/ghaderer/libmicrohttpd/tree/wip-openssl-master. Could you review it and tell me if this is something you could integrate? If you don't, what should be done to improve it and have it checked in?

I tested on Linux/amd64. All existing tests pass. Not tested on Windows at all.

Cheers,


Gauthier
(0012847)
silvioprog   
2018-02-01 00:07   
Hello.

Thanks a lot for implementing and sharing it, I'm going to test your changes as soon as possible.

OpenSSL support is an awesome feature, it requires a detailed test ...
(0012848)
silvioprog   
2018-02-01 01:07   
Hello again @ghaderer .

I took a look at your changes, really impressive. However, I've tried to compile it on my Xubuntu and got the following error:

./configure --with-gnutls=no --with-openssl=yes
make

[snip]
gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/include -DDATA_DIR=\"../../src/datadir/\" -DCPU_COUNT=8    -g -O2 -fno-strict-aliasing -MT benchmark-benchmark.o -MD -MP -MF .deps/benchmark-benchmark.Tpo -c -o benchmark-benchmark.o `test -f 'benchmark.c' || echo './'`benchmark.c
mv -f .deps/benchmark-benchmark.Tpo .deps/benchmark-benchmark.Po
/bin/bash ../../libtool  --tag=CC   --mode=link gcc   -g -O2 -fno-strict-aliasing   -o benchmark benchmark-benchmark.o ../../src/microhttpd/libmicrohttpd.la 
libtool: link: gcc -g -O2 -fno-strict-aliasing -o .libs/benchmark benchmark-benchmark.o  ../../src/microhttpd/.libs/libmicrohttpd.so -pthread
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_del_session'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_del_context'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_create_context'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_client_certificate_mode'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_certificate_cb'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_wants_write'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_set_https_callbacks'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_global_deinit'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_tls_connection_shutdown'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_read'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_get_session_protocol_version'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_get_specific_session'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_close'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_read_pending'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_run_tls_handshake_'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_trust_certificate'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_get_session_cipher_algorithm'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_wants_read'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_cipher_priorities'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_lookup_engine'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_create_session'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_engine_has_feature'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_dh_params'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_global_init'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_set_context_certificate'
../../src/microhttpd/.libs/libmicrohttpd.so: undefined reference to `MHD_TLS_session_write'
collect2: error: ld returned 1 exit status
Makefile:734: recipe for target 'benchmark' failed
make[4]: *** [benchmark] Error 1
make[4]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2/src/examples'
Makefile:938: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2/src/examples'
Makefile:418: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2/src'
Makefile:549: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2'
Makefile:454: recipe for target 'all' failed
make: *** [all] Error 2


It should link openssl by itself. Another test:

./configure --with-openssl=no
make
[snip]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/microhttpd -I/usr/include/p11-kit-1 -DBUILDING_MHD_LIB=1 -fvisibility=hidden -pthread -I/usr/include/p11-kit-1 -g -O2 -fno-strict-aliasing -MT libmicrohttpd_la-connection.lo -MD -MP -MF .deps/libmicrohttpd_la-connection.Tpo -c connection.c  -fPIC -DPIC -o .libs/libmicrohttpd_la-connection.o
In file included from internal.h:32:0,
                 from connection.c:28:
tls.h:493:31: error: field ‘gnutls’ has incomplete type
     struct MHD_GnuTLS_Context gnutls;
                               ^
tls.h:529:31: error: field ‘gnutls’ has incomplete type
     struct MHD_GnuTLS_Session gnutls;
                               ^
connection.c: In function ‘MHD_get_connection_info’:
connection.c:3764:28: warning: implicit declaration of function ‘gnutls_cipher_get’ [-Wimplicit-function-declaration]
       connection->cipher = gnutls_cipher_get (connection->tls_session->d.gnutls
                            ^
connection.c:3775:30: warning: implicit declaration of function ‘gnutls_protocol_get_version’ [-Wimplicit-function-declaration]
       connection->protocol = gnutls_protocol_get_version (connection->tls_sessi
                              ^
Makefile:1182: recipe for target 'libmicrohttpd_la-connection.lo' failed
make[3]: *** [libmicrohttpd_la-connection.lo] Error 1
make[3]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2/src/microhttpd'
Makefile:418: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2/src'
Makefile:549: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/silvioprog/dev/git/libmicrohttpd2'
Makefile:454: recipe for target 'all' failed
make: *** [all] Error 2
(0012851)
ghaderer   
2018-02-01 09:38   
Hello silvioprog,

Thank you for taking time to test and review my changes.

Regarding the missing symbols issue, I broke the HTTPS support auto-detection.

For the second issue, it was due to a typo which caused the build to break when GnuTLS was enabled but not OpenSSL.

I fixed both of them and pushed on the same branch. I hope I did not make other mistakes! :-/

Let me know if you have other issues or questions regarding all of this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5777 [Taler] wallet (WebExtensions) minor have not tried 2019-06-26 16:11 2019-08-01 12:47
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold 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.7  
Summary: allow recovering refreshed and partially spent coins
Description: We distinguish three cases:

1. The coins is freshly withdrawn from a reserve. For that, we use the existing /payback API.

2. The coin has been partially spent. In this case, when the coin is revoked, the wallet refreshes it into a non-revoked denomination. However, the exchange currently does not allow this!

3. The coin is fresh, but was obtained via refreshing. For this case, we need a new /refresh/payback API. This API "reverses" a refresh, and credits the old coin. To prove that the revoked coin came from a refresh, the customer reveals the gamma-th transfer secret, which allows the exchange to verify the the new coin was derived from the old coin.
Tags:
Steps To Reproduce:
Additional Information: Steps to do:
1) Track number of coins redeemed and number of coins issued, not total value redeemed/total value issued.

2) Enable refresh on revoked denominations IF the coin was seen before the revocation. Refresh should also be enabled for "zombie" coins that regained value from (3) even if the denomination is past deposit-expiration (but not if the denomination is legal-expired).

3) Specify /refresh/payback API, including additional entry type in (old) coin history! Here, the transfer private key would be disclosed, giving value back to the old coin (similar to refund) and setting the "zombie" flag re-enabling refresh (2) even if the denomination itself is post deposit-expiration.

4) Implement /refresh/payback API

5) Test /refresh/payback API
Attached Files:
Notes
(0014598)
Florian Dold   
2019-06-26 17:01   
In step (3) we can't actually reveal the transfer private key, as this breaks unlinkability for the other outputs of the refresh operation.

Instead, we reveal the blinding factor r and new coin's public key C_p. The exchange then checks if the blinded signature stored in the exchange database matches r and C_p.
(0014600)
Christian Grothoff   
2019-06-26 19:25   
(1) is actually already implemented (somewhat inefficiently...) by the auditor (see report_emergency_by_count()).

I've added some #ifdef OPTIMIZE_5777_AUDITOR_BY_COUNT_REALTIME_DETECTION to show where we might want to modify data structures in the exchange to enable more (and efficient) "real-time" detection, but that's a performance optimization which is not crucial to 0005777 itself (and there are plenty of other auditor-related optimizations to do first before this one becomes even relevant). So we can skip (1) for now.
(0014603)
Christian Grothoff   
2019-06-27 00:05   
9a69fd81..19e0b66f implements first parts of step (2), but doesn't yet do the zombie check (but adds a FIXME for that).
(0014690)
Christian Grothoff   
2019-07-15 21:59   
(3) is a bad idea, as disclosing the transfer private key implicitly discloses the coin private key, allowing the exchange to fake deposits of that coin and thus enabling the exchange to claim that the coin was already spent.
(0014691)
Christian Grothoff   
2019-07-15 22:02   
(Last edited: 2019-07-19 11:19)
a497ccff..4785bcb4 adds a few notes on where to continue once we figured out what to do about 0005777:0014690.

=> Florian reminded me that the first bugnote already addresses this. Reading would help.

(0014716)
Christian Grothoff   
2019-07-21 20:20   
(Last edited: 2019-07-28 00:12)
c94309ee..990e7ef3 expands the DB plugin with new functions to store payback information related to refreshed coins.
Next steps:
(a) specify coin history API: add the two new events related to refresh payback (as old coin and as new coin) [DONE]
(b) implement new coin history in exchange, including totaling up the amounts internally correctly, and generating the JSON [DONE]
(c) specify new refresh-payback API for refreshed coins (DONE)
(d) implement new refresh-payback API in exchange (DONE)
(e) Improve TALER_TESTING_cmd_refresh_melt() (DONE)
(f) implement (2) with the zombie check (DONE)
(g) update auditor to handle new coin history possibilities (DONE).

(0014749)
Christian Grothoff   
2019-07-28 00:13   
Assigning to Florian: now a wallet issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5815 [GNUnet] build process minor always 2019-07-21 21:06 2019-08-01 10:24
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.11.7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.11.7  
    Target Version: 0.11.7  
Summary: macOS warning
Description: common_logging.c:111:19: warning: unknown attribute 'nonstring' ignored
      [-Wunknown-attributes]
  __attribute__ ((nonstring));
Tags:
Steps To Reproduce: Compile on macOS
Additional Information:
Attached Files:
Notes
(0014757)
Christian Grothoff   
2019-07-29 17:57   
Could safely be #ifdef'ed to eliminate that attribute if the compiler doesn't support it.
(0014761)
schanzen   
2019-07-31 13:50   
Fixed in 68064fbe8..37a32e37e like https://patchwork.kernel.org/patch/10608277/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5816 [GNUnet] DHT service minor have not tried 2019-07-21 21:07 2019-08-01 10:24
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.11.7  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.11.7  
    Target Version: 0.11.7  
Summary: macOS build warning
Description: dht_api.c:545:20: warning: taking address of packed member 'key' of class or
      structure 'GNUNET_DHT_MonitorGetMessage' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                  &msg->key);
                   ^~~~~~~~
dht_api.c:611:25: warning: taking address of packed member 'key' of class or
      structure 'GNUNET_DHT_MonitorGetRespMessage' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                       &msg->key,
                        ^~~~~~~~
dht_api.c:679:20: warning: taking address of packed member 'key' of class or
      structure 'GNUNET_DHT_MonitorPutMessage' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                  &msg->key,
                   ^~~~~~~~
dht_api.c:814:48: warning: taking address of packed member 'key' of class or
      structure 'GNUNET_DHT_ClientResultMessage' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                                              &msg->key,
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014719)
schanzen   
2019-07-21 21:07   
More:

./gnunet-service-dht_clients.c:488:34: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
               GNUNET_h2s_full (&dht_msg->key));
                                 ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:41:68: note: expanded from macro 'LOG_TRAFFIC'
#define LOG_TRAFFIC(kind,...) GNUNET_log_from (kind, "dht-traffic",__VA_ARGS__)
                                                                   ^~~~~~~~~~~
../../src/include/gnunet_common.h:528:50: note: expanded from macro 'GNUNET_log_from'
          GNUNET_log_from_nocheck ((kind), comp, __VA_ARGS__); \
                                                 ^~~~~~~~~~~
In file included from gnunet-service-dht.c:58:
./gnunet-service-dht_clients.c:493:21: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
       GNUNET_h2s (&dht_msg->key));
                    ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:43:60: note: expanded from macro 'LOG'
#define LOG(kind,...) GNUNET_log_from (kind, "dht-clients",__VA_ARGS__)
                                                           ^~~~~~~~~~~
../../src/include/gnunet_common.h:528:50: note: expanded from macro 'GNUNET_log_from'
          GNUNET_log_from_nocheck ((kind), comp, __VA_ARGS__); \
                                                 ^~~~~~~~~~~
In file included from gnunet-service-dht.c:58:
./gnunet-service-dht_clients.c:495:30: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
                            &dht_msg->key,
                             ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:505:30: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
                            &dht_msg->key,
                             ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:522:31: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
                             &dht_msg->key,
                              ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:534:29: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientPutMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
                           &dht_msg->key,
                            ^~~~~~~~~~~~
./gnunet-service-dht_clients.c:620:21: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientGetMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
       GNUNET_h2s (&get->key),
                    ^~~~~~~~
./gnunet-service-dht_clients.c:43:60: note: expanded from macro 'LOG'
#define LOG(kind,...) GNUNET_log_from (kind, "dht-clients",__VA_ARGS__)
                                                           ^~~~~~~~~~~
../../src/include/gnunet_common.h:528:50: note: expanded from macro 'GNUNET_log_from'
          GNUNET_log_from_nocheck ((kind), comp, __VA_ARGS__); \
                                                 ^~~~~~~~~~~
In file included from gnunet-service-dht.c:58:
./gnunet-service-dht_clients.c:626:34: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientGetMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
               GNUNET_h2s_full (&get->key));
                                 ^~~~~~~~
./gnunet-service-dht_clients.c:41:68: note: expanded from macro 'LOG_TRAFFIC'
#define LOG_TRAFFIC(kind,...) GNUNET_log_from (kind, "dht-traffic",__VA_ARGS__)
                                                                   ^~~~~~~~~~~
../../src/include/gnunet_common.h:528:50: note: expanded from macro 'GNUNET_log_from'
          GNUNET_log_from_nocheck ((kind), comp, __VA_ARGS__); \
                                                 ^~~~~~~~~~~
In file included from gnunet-service-dht.c:58:
./gnunet-service-dht_clients.c:654:29: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientGetMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
                           &get->key);
                            ^~~~~~~~
./gnunet-service-dht_clients.c:661:30: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientGetMessage' may result in an unaligned
      pointer value [-Waddress-of-packed-member]
  GDS_DATACACHE_handle_get (&get->key,
                             ^~~~~~~~
./gnunet-service-dht_clients.c:760:13: warning: taking address of packed member 'key'
      of class or structure 'GNUNET_DHT_ClientGetResultSeenMessage' may result in an
      unaligned pointer value [-Waddress-of-packed-member]
                                              &seen->key,
(0014720)
schanzen   
2019-07-23 12:59   
Fixed in b92650ab1..dbf604ad9
(0014721)
schanzen   
2019-07-23 13:00   
Wrong bug closed
(0014722)
schanzen   
2019-07-23 13:00   
Reopened
(0014756)
Christian Grothoff   
2019-07-29 17:56   
Manual inspection of some of these suggests the compiler is simply out-of-line / way too often wrong about this one.
(0014762)
schanzen   
2019-07-31 13:57   
How to proceed? -Wno-address-of-packed-member or change the code or do nothing?
(0014763)
Christian Grothoff   
2019-07-31 19:49   
Passing -W options should always be fine, they just toggle warnings and don't change the generated binaries. So sure, disabling that warning makes sense to me.
(0014765)
schanzen   
2019-08-01 10:24   
Fixed in 37a32e37e..b97b12fab


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5736 [GNUnet] build process minor have not tried 2019-05-26 20:18 2019-07-30 19:52
Reporter: ng0 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: linker/compiler AM_ flags during header checks aren't working really well
Description: This is a long standing feature bug.

Essentially what should happen is that when the correct LDFLAGS and CFLAGS are passed, the AM_ counterpart
respects those flags.
But even when you set the AM_ flags to temporarily include the current CFLAGS the detection fails.
This produces results such as:

configure:22261: checking for libzbar
configure:22380: result: --with-zbar not specified
configure:22384: checking zbar.h usability
configure:22384: clang -c -fno-strict-aliasing -Wall -g -O0 -I/usr/pkg/include -I/usr/pkg/include conftest.c >&5
configure:22384: $? = 0
configure:22384: result: yes
configure:22384: checking zbar.h presence
configure:22384: clang -E conftest.c
conftest.c:46:10: fatal error: 'zbar.h' file not found
#include <zbar.h>
         ^~~~~~~~
1 error generated.
configure:22384: $? = 1

...
configure: WARNING: zbar not found, gnunet-qr will not be built.


The problem here is that we need to pass the /usr/pkg/include (on my platform) to the temporary assembled test applications.
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:
5722 [GNUnet] build process minor have not tried 2019-05-13 16:11 2019-07-30 19:52
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: --with-libgcrypt-prefix does not work properly
Description: When configuring GNUnet with --with-libgcrypt-prefix=$HOME/local, the configure step fails, even though libgcrypt is installed into that prefix properly. The supposed problem is a mismatch between the header version and library version of libgcrypt.

It turns out that this is because the conftest program is *not* executed with the correct LD_LIBRARY_PATH. When executing, ldd picks up the distributions libgcrypt.

Thus when compiling with --with-libgcrypt-prefix=$PREFIX, you also have to manually put $PREFIX into LD_LIBRARY_PATH, or otherwise ./configure fails with an obscure error message.

Instead, the configure script should execute the conftest in the right environment, respecting the prefix.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014386)
ng0   
2019-05-13 18:27   
Is --with-libgcrypt the only affected switch here?
I have no system wide ldd config, but I can assume that this is not exclusive to gcrypt and we might want to double check the other lines where we use it.
(0014760)
ng0   
2019-07-30 19:52   
unassigning, pick up if you have a proposed fix.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5657 [libmicrohttpd] documentation text have not tried 2019-03-20 05:52 2019-07-29 17:55
Reporter: silvioprog Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: current SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: current SVN  
Summary: Example showing how to use suspend/resume feature combined by threads and external select
Description: Hello.

Since some members already asked about that, it would be nice to provide an example showing how to combine these features.
Tags:
Steps To Reproduce:
Additional Information: More info: http://lists.gnu.org/archive/html/libmicrohttpd/2019-03/msg00004.html
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5766 [Taler] exchange API (C) tweak N/A 2019-06-18 11:32 2019-07-29 17:44
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: no change required  
Projection: none      
ETA: none Fixed in Version: 0.6  
    Target Version: 0.6  
Summary: untested libtalerexchange functions
Description: These functions are never used (not even in tests):
[exchange_api_handle.c:2101]: (style) The function 'TALER_EXCHANGE_get_denomination_key_by_hash' is never used.
[exchange_api_handle.c:2136]: (style) The function 'TALER_EXCHANGE_get_keys_raw' is never used.
[exchange_api_reserve.c:1160]: (style) The function 'TALER_EXCHANGE_reserve_withdraw2' is never used.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014753)
Christian Grothoff   
2019-07-29 17:43   
withdraw2 is actually used in the merchant's tipping test.
(0014754)
Christian Grothoff   
2019-07-29 17:44   
Actually, all 3 are used (and thus tested) in various mechant tests (key_by_hash in tip-pickup, get_keys_raw in pay).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5819 [GNUnet] webpage minor have not tried 2019-07-24 18:50 2019-07-29 09:51
Reporter: ng0 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: news generator
Description: probably a duplicate of 2 other issues,

will add the details soon how to approach this after the mumble with Christian a couple moments ago.
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:
5575 [GNUnet] webpage feature N/A 2019-02-16 00:51 2019-07-28 16:27
Reporter: dvn 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: Proposal: Add a section for "News" on the front page of new site
Description: The website is looking good, but the front page is setup to always show the same content. This is good - we _should_ show some information that will always be there: an easy to access download button, the summary of the project, a link to documentation.

That said, adding some dynamic content in the form of a "news area" would be a great way to keep visitors informed about the activity within the project.

I'm including a _very simple_ mock-up of how I imagine it could look, on a desktop screen. For mobile, I think we could just make the news area go underneath the top summary.

For populating this news area, it would be nice if it was auto generated as part of the website build process, any time new pages are added to a designated /news directory.
Tags:
Steps To Reproduce:
Additional Information: Don't assign this to roadmaps. Thanks.
Attached Files: news-section-mockup.png (157,141 bytes) 2019-02-16 00:51
https://bugs.gnunet.org/file_download.php?file_id=809&type=bug
Notes
(0013808)
ng0   
2019-02-16 00:55   
slightly related: 0005522 .. more in detail comment follows tomorrow. Good idea.
(0013818)
Christian Grothoff   
2019-02-16 14:47   
In principle that looks fine, as long as the result is responsive and doesn't require wide screens ;-)
(0013914)
ng0   
2019-02-20 19:28   
I can think of a couple of ways to solve this, I will look into them while working on the rss.
We probably don't want to turn the website into a flask+jinja2 application? (so that I can exclude one solution if this is not desired)
(0013916)
Christian Grothoff   
2019-02-20 23:49   
Right, we want a completely statically generated page, including the RSS.
(0013917)
ng0   
2019-02-20 23:54   
unrelated, have you read my email about the required Apache changes? Not that people start filing bugs on gnunet.org being broken..
(0013918)
ng0   
2019-02-20 23:55   
the output is now in /rendered/
(0014144)
ng0   
2019-03-04 11:49   
(Last edited: 2019-03-04 11:50)
Is it okay when I operate under the defacto assumption that news will never be translated and therefore need no gettext interaction? This will make things *much* easier.

(0014145)
Christian Grothoff   
2019-03-05 13:59   
Yes, that's a good assumption. If we really ever translate a news item, I would just post that one translation under a different language.
(0014583)
ng0   
2019-06-24 19:53   
I have dropped this assignment. I know I'm capable to solve this, but I haven't worked on this in a while (code exist but needs a merge with default branch and is nowhere close to being done). If someone wants to pick this up, go ahead.
The only challenge is that we are a bit different than most jinja2 websites.

If no one has picked it up by the time I get free time for this, I'll continue.
(0014631)
ng0   
2019-07-01 12:34   
update: because I'm really annoyed by the current news presentation, I'm working on it, but not so fast. It's in the dev/ng0/newssystem branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3914 [GNUnet] documentation text N/A 2015-07-25 15:45 2019-07-28 16:24
Reporter: Christian Grothoff Platform: i7  
Assigned To: 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:  
Summary: improving the installation guide/handbook
Description: Demos wrote on gnunet-developers (and we should check & fix):

What i think what could spare users and package builders time and make
installation a fluent process is to improve the installation guide.
Maybe you agree in some points:

1. Mention that there are built-instructions of the different operating
systems at the beginning!
2. Combine https://gnunet.org/generic-installation-instructions and
https://gnunet.org/dependencies to remove unnecessary redundancy (easier
to maintain in case of (changing) dependencies)->
easier overview for those who want to package.
3. The README text from the installtion package could be the same as the
Installation handbook as long as the installer is not OS-specific.->
easier to maintain,
make sure when somebody changes the README that he changes the
Installation handbook online too and vise versa.
4. Add the following packages to (every) list of dependencies. For
consistency: If no composition of the instructions is made then the
dependencies must be on EVERY list the same having the same order.(not
complete sorry) :
* tar and xz for opening the source balls
* autoconf >= 2.59, automake >= 1.11.1
* gmp (as it is called a dependency in README in the newest
gnunet-package, dependency for nettle)
* libgpgerror (as it stands in
https://gnunet.org/generic-installation-instructions)
* nettle 2.7
5. Make sure the order of dependencies is as it should be installed.
6. Order the dependencies into two sections must have and optional
7. Add links to the sources:
(not complete)
https://github.com/freddix/libgpg-error (zip)
ftp://ftp.gnupg.org/gcrypt/libgpg-error/

CERTOOL for GNS: depends on nss which depends on nspr
(gns->certool->nss->nspr)
https://developer.mozilla.org/en-US/docs/NSPR
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_9_2_RTM/Linux2.4_x86_glibc_PTH_OPT.OBJ/
(having both packages combined)


8. NETTLE: I had some odd built errors when first configuring and then
making nettle. I did several things and i don't know what helped at the
end, but since nettle is essential for gnutls
(./configure throws an error when nettle is missing) try to build it
yourself: it was not available for Debian 8.1. nettle-2.7 is libnettle4
in debian
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0013010)
Christian Grothoff   
2018-06-07 01:20   
Assigning to ng0 as he may take inspiration from this (or feel free to close if useless).
(0013012)
ng0   
2018-06-07 06:12   
THanks.

Parts of it will be closed by my next commit on probably friday or saturday.

I even ordered the dependencies in 4 sections.

I don' t think we need to keep track of (build)notes for dependencies of applications more than 1 level below us (like nettle), but I have a verbose stagging file for this and a plan.
(0013013)
ng0   
2018-06-07 06:15   
Grothoff: in the next release notes you can mention my full name as it appears in the developer list. I started using it for easier association.
(0013014)
Christian Grothoff   
2018-06-07 08:18   
Well, I generated the acks from Git logs (hence sorted by # commits, which seems reasonable, too). Not sure if/how you can change the _historic_ commits, but obviously feel free to use real-name for future commits then.
(0013904)
Christian Grothoff   
2019-02-20 13:07   
ng0: Is this finished?
(0013935)
catonano   
2019-02-22 07:20   
is this meant for 0.11 ?
(0014387)
ng0   
2019-05-13 18:31   
> ng0: Is this finished?

I have to check this. I'll get back to this once I'm done at some point this year (there are many points to check in a large body of text and you know the white rabbit from Alice in Wonderland ;) ).. I'll get to it.
(0014397)
ic.rbow   
2019-05-15 10:40   
BTW, I've begun compiling a set of tutorial/demo/handout pages in markdown.

Starting with aggregation and reviewing of all the installation tutorials at https://dpwiz.gitlab.io/gnunet-tutorial/install/
(0014398)
Christian Grothoff   
2019-05-15 11:15   
lc.rbow: Fragmenting documentation like this is a bad idea. We do have the texinfo handbook. We should work on improving this primary documentation. Having lots of additional documents spread in various formats all over the world is not helpful. It would be much better if you could focus on contributing to the existing installation chapter in the handbook. Learning TeXinfo is not really hard, it comes with excellent documentation. You can submit patches to the handbook and possibly even get direct Git access to edit it. But having more documentation that has unclear licenses, is hard to find, possibly outdated, and can only be edited by you or people who you give access to is not really that useful. Please try to work with us on this, not duplicate the effort.
(0014399)
ng0   
2019-05-15 12:38   
I have to agree with Christian, however:

1) having handout pages can be first done in markdown. There is a ticket about this I created recently and transpilling from one language to another one if necessary won't be that hard.

2) depending on your scope this is okay. As with every big documentation which isn't rewritten from scratch it is not easy to find a point to start. Knowing what can be changed and what has to be ripped out requires a really long exposure to the project at times and/or asking people who have been around when the old pages have been written.
What the Texinfo - a format I pushed for and am not happy with myself but it works - version represents is the attempt to create a canonical documentation.
API documentation will be transpiled doxygen to mdoc once I'm done with the code, automatic procedure.
What we had in Drupal books was already "all over the place". Don't be discouraged by Christian's words. It's okay, but ideally we can work this into improving the current documentation.

Canonical documentations would improve developers and users interaction with it, as well as aid people who would write books such as "an introduction to modern p2p network programming (with GNUnet)".
(0014400)
ng0   
2019-05-15 12:46   
What I see lacking is a bit of a public plan where I/we want to go to with the documentation.
A while back Christian and myself had a consensus on future content (images for formats which support images, displaying the processes with daily life "stuff" such as sending packages via mail).
My move on stripping out the system specific installations was regarded as a mistake.
So maybe I should take the time and write down what I'd like to improve and where this should move to so that other people can do more than typo hunting and searching dead links etc.
I'm more than aware that I can't do this on my own, even though it helps to form a higher level understanding of gnunet.
(0014401)
ng0   
2019-05-15 12:52   
By the way, if you just want markdown from the Texinfo documentation, you can install mdoc (or if your base system already includes it) and build gnunet with the ability to output the section 7 documentation (which is the production of texinfo2mdoc) and convert the production to markdown with the output type set to markdown.

I'll take a look at what you have later this week.
(0014402)
ic.rbow   
2019-05-15 13:58   
There's not much original stuff in there right now as I wanted a single *informal* page per topic to refer people to. Current docs site with a single-page handbook is overwhelming for some and a granularity is a bit off IMO.

As for markdown, it's merely a "less plain" text to gather and store notes temporarily.
(0014403)
ng0   
2019-05-15 16:34   
True, we could generate per-section pages output. It's a bit too much and can take long to load if we start adding pictures (to the html output). Furthermore, since this was ad-hoc for a start and the presentation goal should be more like docs.taler.net, a choice for pdf, ps, html, single-page html, plain text, etc should be given later on, I totally agree with you.
(0014480)
ic.rbow   
2019-06-01 19:02   
I just had a look at handbook again and noticed that it may be reasonable to have current content structured as it is if it would be rendered as two-level deep pages.

For example (each '*' denotes a page, each '-' denotes a section on the same page):

* ToC
...
* 4 Installing GNUnet
  * 4.1 Installing dependencies
  * 4.2 Getting the Source Code
...
  * 4.7 The graphical configuration interface
    - 4.7.1 Configuring your peer
    - 4.7.2 Configuring the Friend-to-Friend (F2F) mode
...
    - 4.7.31 Peer configuration for distributors (e.g. Operating Systems)
...
* 5 Using GNUnet
  * 5.6 The GNU Name System
    - 5.6.6 Resource Records in GNS
    - 5.6.6.21 RECLAIM OIDC REDIRECT
...

If possible, this would retain observability of a whole topic while focusing the attention to the topic at hand.
As you can see, there can be a lots of level 3 subsections per parent, but level 2 division is pretty adequate.
(0014481)
ic.rbow   
2019-06-01 19:04   
WIth that in place, further improvements to the structure can take place more easily.
(0014482)
Christian Grothoff   
2019-06-01 19:06   
The excerpt of the ToC you propose makes sense. Maybe you could coordinate with ng0 and/or work on a patch?
(0014483)
ng0   
2019-06-01 19:08   
Can you go more into detail what you mean?

So far I can only guess. Do you mean the way the html output looks like in list style?
Know that the current structure is done semi-automatically for some outputs, all I do
is tell texinfo about the nodes.

If possible a view in .patch or diff view would be good!
(0014484)
ng0   
2019-06-01 19:12   
Adding: As far as I know Texinfo has no concept of "pages".
When you take the one-page-per-node view of html, you get what you ask for or part of it.
See https://www.gnu.org/software/guix/manual/en/html_node/ and
https://www.gnu.org/software/guix/manual/en/html_node/Application-Setup.html#Application-Setup
for an example.
(0014485)
ng0   
2019-06-01 19:20   
imho the best course of action would be to get interested people (we have at least 3 working on the docs every now and then), step back, and re-evaluate what we personally want to read.

Obviously what we have is far from perfect. Coordinated writing could make this huge task a bit more structured.

Old texts could be in the way. Because someone has once written it doesn't mean it is still true. And if it is, do we have to keep the exact (albeit corrected by myself) texts?
(0014486)
ng0   
2019-06-01 19:23   
Just looking at the size of it can be intimidating I imagine and make a rewrite or corrections seem more difficult than they are.

 wc gnunet.texi chapters/*
     248 838 7469 gnunet.texi
       5 23 159 chapters/configuration.texi
     117 582 4246 chapters/contributing.texi
    9009 54204 366481 chapters/developer.texi
    2325 12295 82825 chapters/installation.texi
     321 2340 15728 chapters/keyconcepts.texi
      81 507 3578 chapters/philosophy.texi
     206 1608 9952 chapters/preface.texi
    2335 14141 89091 chapters/user.texi
      72 203 1498 chapters/vocabulary.texi
   14719 86741 581027 total
(0014489)
ic.rbow   
2019-06-01 19:36   
The intended layout I would like is like this page: https://www.gnu.org/software/guix/manual/en/html_node/Python-Modules.html#Python-Modules
It is 3 levels deep (14.4.5 Python Modules) and containes one more level (14.4.5.1 Specifying Dependencies), which is inlined in the resulting HTML page. And it has that one "inner" node in the main ToC.

That looks almost as I would like that for the GNUnet handbook, with the distinction that nodes should be inlined starting from depth level 3 judging by the site contents. Otherwise users will be presented with 1 paragraph of text per page as they were on the previous 1-node-per-page layout.

The patch would have to do with textinfo configuration/build script tweaks of which I yet have to know more.
(0014491)
ic.rbow   
2019-06-01 19:39   
I looked at texinfo manual and haven't found any options concerning node depths. Maybe the solution would be to use page-per-node layout and strategically wrap groups of lesser sections to force inlining beyound level 3.
(0014492)
ng0   
2019-06-01 20:14   
Okay. If you want to give it a try, go ahead. I'd like to review the patch before if it involves a non-trivial amount of changes to the Texinfo book. Ideally doc/tutorial is also considered, but for now handbook is already enough text (tutorial would be less complex and a good testing ground).

I don't know how familiar you are with Texinfo and the other stuff involved, if you have any questions feel free to ask here.
(0014494)
ic.rbow   
2019-06-01 21:35   
I found relevant bit in `gendocs.sh`:

  --split HOW make split HTML by node, section, chapter; default node.

Perhaps GUIX manual does that section splitting thing?

Here it is in the manual: https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#HTML-Splitting

Now, if you tell me what exactly to run to get the docs built (there are just too many pieces for a first run unguided...) maybe I can figure it out where to apply the splitting (please say if you know that already) and proceed with poking the handbook.
(0014495)
ng0   
2019-06-01 22:52   
This is how the handbooks are build on the server (crontab):

* * * * * cd gnunet; sh contrib/gnunet_infrastructure/handbook_pull.sh; cd doc/handbook; make gnunet.html &> /dev/null
* * * * * cd gnunet/doc/tutorial; make gnunet-tutorial.html &> /dev/null

Where handbook_pull.sh is iirc just a thing I wrote for the server to continue working.
I did initially look at - among other projects - Guix texinfo generation, but they include more logic than we (currently) need minus(!) backwards compatibility things I applied.

The relevant pieces are in the first few lines of the doc/handbook/Makefile.am:

# NOTE: While GNU makeinfo 6.5 supports --css-ref=URL,
# makeinfo 4.8 (in NetBSD 8.0, macOS, and maybe other
# base) does only support --css-include=FILE.
# The only difference is a shorter html output and
# in 6.5 the ability to use refs instead of include.
# We prefer not to break builds in this case, so
# we use the include version which is backwards compatible
# and upwards compatible, while the ref variant is neither.

AM_MAKEINFOHTMLFLAGS = --no-split --css-include=style.css --css-include=manual.css


So what we want here is to have 2 rules for the html output and not one implicit generated rule. Rule 1: what we do now (1 page output). Rule 2: just remove the --no-split OR add --split
(0014496)
ic.rbow   
2019-06-02 11:41   
Oh... It is in the 5.x they added `--split=chapters|sections` in addition to `--split=nodes`. Perhaps website handbook could use most recent version while distribution can fall back to whatever version available.
(0014497)
ng0   
2019-06-02 12:12   
Okay. Just another Makefile.am rule combined with a configure flag then.

For example --enable-texinfo4 -> uses the default I have now.
Defaults to TRUE.
Server would then --disable-texinfo4 (so: FALSE), and get the newest texinfo feature.
Depending on the value, the Makefile.am would then use an appropriate AM_MAKEINFOHTMLFLAGS.
(0014498)
ng0   
2019-06-02 12:15   
So basically:
if ENABLE_TEXINFO4
AM_MAKEINFOHTMLFLAGS = --no-split --css-include=style.css --css-include=manual.css
else
AM_MAKEINFOHTMLFLAGS = --split=sections --css-ref=style.css --css-ref=manual.css
endif

or something along those lines, allowing us to support both old and new makeinfo while keeping the texinfo itself backwards compatible.
(0014625)
ng0   
2019-07-01 12:22   
Stop assigning version numbers to big documentation tasks which were worded in a way which can not be done in 1 or more minor versions.
(0014626)
ng0   
2019-07-01 12:23   
I know you want to do triage on bugs, but documentation is a topic which most of the time must be treated differently.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5655 [GNUnet] documentation feature have not tried 2019-03-19 16:48 2019-07-28 16:02
Reporter: ng0 Platform:  
Assigned To: ng0 OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: suspended  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: self-generated programming documentation
Description: Inspired by the GnuTLS documentation I've taken on this series of long task, not yet fully defined in words here:

- analyze GnuTLS documentation tooling
- rewrite perl parts in languages used in our our base (C, shell, awk)
  to not create a mandatory dependency on perl -> 50% of the gnutls documentation code is perl



right now we don't (or only in a manual fashion) document our functions, variables, etc.
To keep up with it you have to manually sync documentation while coding (in my opinion you ideally FIRST write documentation with the expected behavior and outcome and then write the code, but this rarely happens).
See lots of "this section has to be rewritten for (...)" in our documentation.

Read 7.34.1.1 "Looking up records", of libgnunetgns. As an example - This is not 100% accurate but whatever, this should be just a generic example. If we could have this small section generated from the code which is described in there and generate function names, prototypes, description of the parameters, etc out of the source files which define them(!) and insert the result into texinfo files which are then @included in the appropriate chapters, we'd spare ourselves a major amount of duplicate work.

Expect this to take rather long with my other responsibilities, but the outcome will be worth it.
No target version for obvious reasons.

This should:
- not affect the dependencies required for gnunet (self-contained scripts and applications),
- be portable for all systems we currently support, with initial focus on NetBSD (ie best attempts to keep the involved tools portable) with best effort support testing on Debian after I have finished the code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014345)
ng0   
2019-04-25 10:36   
In addition to our emails, I want to clarify this a little:

- We should get Texinfo, to include it as another @include chapter
- We also should get one mdoc file per function or logical group of functions with the right cross references if possible/necessary, but a one file mdoc is okay too.

For the record, we must adjust the code. Code found in branch '5655-function_documentation'
(0014356)
ng0   
2019-04-27 18:50   
As written on IRC, but duplicating it here in summary: I'm also evaluating a modification of
the sqlite2mdoc application, which might be less work if we can adjust it to our own infrastructure.
If not for all (LMHD, Taler, GNUnet), then for gnunet and everyone else can make patches on top of it or have their own branches.

We don't need no extra output with mdoc having the ability to output to html, texinfo, etc.
Also if we haven't put it down for public record: we don't want the output to be part of the repository but to be part of the distribution tarball.
(0014357)
ng0   
2019-04-27 19:08   
For full reference: https://github.com/kristapsdz/sqlite2mdoc/blob/master/main.c

I'm in favor of and will use whatever leads to self-documenting code, even if we have to adjust the code to our new clang-format somehow (by code I mean comments about the code).
(0014582)
ng0   
2019-06-24 19:49   
working on this, in case I haven't mentioned it, with varying time I can spend on this. Do it once and do it good.
(0014751)
ng0   
2019-07-28 16:02   
I'm closing this. I'm working on this, outside of GNUnet, so this will become available but not in a time which I see fit for tracking it within this bugtracker. Of course I will not stand in the way of anyone wanting to do this for and within gnunet, so you could re-open if anyone picks it up.


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-07-28 15:56
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: 0.12.0  
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:
5525 [GNUnet] webpage minor have not tried 2019-01-27 16:21 2019-07-28 15:50
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: new website: Firefox Reader Mode does not display all of our pages in full
Description: * Layout / CSS:
- Firefox Reader Mode does not display all of our pages in full.

Essentially fix that.
Tags: website
Steps To Reproduce:
Additional Information:
Attached Files: 2019-01-30-104803_1920x1080_scrot.png (421,199 bytes) 2019-01-30 11:49
https://bugs.gnunet.org/file_download.php?file_id=798&type=bug
Notes
(0013516)
catonano   
2019-01-30 02:49   
I understand that a button to activate the reader mode should appear in the url bar in Firefox, when such mode is available

But such button appears in no page in the site, so I can't activate the reader mode in no page in the site

I can't reproduce this ¯\_(ツ)_/¯
(0013517)
ng0   
2019-01-30 11:47   
Which version of Firefox is that?

I can reproduce this (this -> my report) in 52 and 65 (65 currently being unavailable for me).
(0013518)
ng0   
2019-01-30 11:49   
(Last edited: 2019-01-30 11:51)
This (appended, or at https://d.n0.is/pub/jpg/2019-01-30-104803_1920x1080_scrot.png) is https://stage.gnunet.org with firefox52-52.9.0nb12 from pkgsrc HEAD.

(0013530)
catonano   
2019-01-31 06:40   
strange

the button to activate the reader mode does show up in the on line version (stage.gnunet.org ) but it doesn't in the version that I built locally

I'll have to figure this out too

I use Firefox 64.x
(0013533)
ng0   
2019-01-31 16:45   
It does not work for local pages, 11668829 firefox bug is open for over 4 years and unassigned:
https://bugzilla.mozilla.org/show_bug.cgi?id=1166829
(0013534)
ng0   
2019-01-31 16:46   
It remains to be tested if a local python webserver would be considered "local" as well.
(0013535)
catonano   
2019-01-31 17:12   
Ah ok.

How do I run a local python server ?

Is a server embedded in this setup ?
(0013536)
ng0   
2019-01-31 17:50   
If you find out the way it works in Jinja2, document it. I can't look into it at the moment.
I know python(2,3) has a webserver out of the box: https://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/

assumption: jinja2 has something similar. So far this wasn't necessary. But reader mode, I'm not sure if this is this important. How many people use this? I usually don't.
(0013595)
dvn   
2019-02-04 20:10   
For what it's worth, I'll add that I use reader mode often. I believe the fact this is not rendering the page properly is also an indication that screen readers (eg. for the blind) would not be able to parse the full page either. Which is a more severe problem.
(0013611)
ng0   
2019-02-06 14:41   
Yes, if those are the implications.
(0013612)
ng0   
2019-02-06 14:44   
(Last edited: 2019-02-06 15:02)
I know why this happens, at least I think so:
we totally disregard the hierarchy of h1, h2 etc and some other elements.

edit: this was wrong, but what one of the Accessibility checkers spit out.
I'm going to think about the right fix.

(0013613)
ng0   
2019-02-06 14:47   
Try one of our pages with for example https://achecker.ca
(0013615)
ng0   
2019-02-06 16:01   
Here's a workaround for the stage not building, and local reader mode not being a thing for security reasons: https://d.n0.is/pub/doc/gnunet/www/en/
updates automatically.
(0013616)
ng0   
2019-02-06 16:15   
Since I was wondering how reader mode decides when to display what and I am not well enough on my feet again to read its code, here's some more insight into reader mode which might help us: https://stackoverflow.com/questions/30661650/how-does-firefox-reader-view-operate
(0013617)
ng0   
2019-02-06 19:06   
I understand enough of what triggers reader mode now, assigning to myself.
(0013975)
ng0   
2019-02-24 00:52   
The gist of it is contained in

https://stackoverflow.com/questions/30661650/how-does-firefox-reader-view-operate
https://support.mozilla.org/en-US/questions/1140969

and changes I already made to our website.
We should eventually standardize the layout. I'm no longer actively working on this, will eventually pick it back up. If you feel like working on it, go ahead.
(0014003)
Christian Grothoff   
2019-02-24 13:28   
I fixed accessibility problems, header issues (3x h1!), lack of article/section markings. All of these were suggested in the posts quoted by ng0, albeit still readability mode looks like shit for the front page ;-(
(0014010)
ng0   
2019-02-24 14:57   
Thanks!

With the alt tag you've done too much in places (or just one?).
I've read into this, there's a range of images which should not get alt tags. For example the branding logo.
(0014011)
ng0   
2019-02-24 14:58   
(Last edited: 2019-02-24 14:59)
quoting https://support.siteimprove.com/hc/en-gb/articles/115000013031-Accessibility-Image-Alt-text-best-practices

Alt text for decorative images

Decorative images are images that serve no specific purpose, meaning that they are not meant to convey any meaning or important information. In this case, it is best practice to use what is called the NULL alt text or empty alt text.

<img alt=""> (two quotation marks after the alt=)

Note that the alt attribute is still present, even though it is empty. When a screen reader comes across null alt text, it will completely skip over the image, without announcing its presence. If no alt attribute is present, the screen reader will read the file name for the image instead, which can be a major distraction to those using screen reading technology.

(0014015)
Christian Grothoff   
2019-02-24 15:21   
As it is a link back to the front page (and the only one!), I'm not sure it qualifies as purely decorative.
(0014018)
ng0   
2019-02-24 15:32   
Okay, agreed.
But also this is progress and learning, there's no definite end to when accessibility is 100%.

In my opinion the current navigation bar image is bad. really bad. It doesn't work out. A text version would be better (taking the gnu:net from the big logo).
(0014094)
ng0   
2019-02-27 17:58   
(Last edited: 2019-02-27 17:59)
For your information, a couple of days ago I made a commit where you can run the website in a python3 local webserver but it is necessary to navigate to the en/ (or any other folder) manually.
`make run` does this now.

This means you can debug readermode stuff without the site being on a webserver.

(0014245)
ng0   
2019-04-01 14:16   
Most pages are fixed, but our general layout (for example on the index page) is still an issue for reader mode.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5767 [Taler] auditor tweak N/A 2019-06-18 12:42 2019-07-28 15:42
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: TALER_TESTING_cmd_deposit_confirmation never used
Description: So right now we have the test operation, but as far as I can tell no test uses it. We should change that...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0014750)
Christian Grothoff   
2019-07-28 15:42   
Fixed in fbf94ee6..5b2efa2b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5679 [gnunet-gtk] other feature have not tried 2019-04-03 22:12 2019-07-28 00:27
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: Gtk 4 (not yet released)
Description: Once Gtk 4 is released, we need to add in support for it in due time.

over 50% of the 4.0 milestones are done and betas are available iirc.

https://gitlab.gnome.org/GNOME/gtk/milestones/1
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014266)
Christian Grothoff   
2019-04-06 16:39   
This report was done WAY too early.
(0014271)
ng0   
2019-04-07 12:42   
I know. But this way we know ahead of time that it needs to be worked on. I will update it as soon
as gtk4 becomes available as rc or final release.
(0014272)
ng0   
2019-04-07 12:43   
With a new major version I expect some notable differences and maybe difficulties to port.
(0014276)
ic.rbow   
2019-04-07 19:28   
It appears there is a some kind of preview version for those who want to taste the breaking changes:
https://blog.gtk.org/2018/07/12/a-report-from-the-guadec-gtk-bof/#Application%20porting

> If you are a bit adventurous, do a port to 3.94 on a branch. It should be possible to keep it working without too much work during the remainder of GTK+ 4 development.
(0014348)
ng0   
2019-04-26 01:57   
grothoff: can you give me the rights here so that I can assign this to myself?

I think we're mostly good to go, but I want to see how this "good" works out until gtk 4 release.
Also, I have to do at least 1 update in pkgsrc and/or locally to test my "good to go" theory reading
of gnunet-gtk source against the migration docs.
(0014351)
ng0   
2019-04-26 23:28   
Aside, do we have glade files for gnunet-gtk or is it just playing with low-level LEGOs (gtk + libglade without any design files)?
(0014352)
Christian Grothoff   
2019-04-26 23:31   
Are you looking for the .glade files in contrib/?
(0014353)
ng0   
2019-04-26 23:45   
aha. I missed those, thanks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5445 [Taler] exchange feature have not tried 2018-09-28 10:45 2019-07-28 00:13
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal 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: emergency payback protocol should support refreshed coins
Description: Instead of crediting the customer's reserve, the original coin should simply be credited.

We additionally allow refreshes on coins with revoked denominations, but *only* if this coin has been seen by the exchange before the revocation.
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-07-21 20:21
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: new 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:
5810 [Taler] deployment and operations minor have not tried 2019-07-20 12:19 2019-07-20 12:19
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: Survey reserve from 'demo' needs automation
Description: The tip reserve from demo suffers from the following two problems:

1) it is not automatically topped up.

2) it is not automatically "refreshed". In particular, even if the reserve did
  not expired and was replenished with money, the merchant backend still
  needs to receive a "/tip-query" call in order to update its database and flag
  the reserve as active. If we miss this step, we get that 2702 error.

I have manually patched the situation by:

1) log in as the active demo user (demo-blue now)
2) source activate && taler-deployment-top-reserve
3) visit survey.demo.taler.net, and *click* "survey stats"
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:
5805 [GNUnet] webpage minor have not tried 2019-07-16 23:41 2019-07-16 23:41
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: $lang/team.html should be a subpage of about
Description: however this would mean yet another small set of redirections.

The idea is:

about > people (or: team) (or: who is working on gnunet) (or: get to know the team...)
about > history
about > ev
about > ...


or something along those lines. What do you think?
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:
5202 [Taler] other text have not tried 2017-12-09 01:53 2019-07-15 19:31
Reporter: Florian Dold 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:  
Summary: clarify and document which amount format should be used where
Description: We have these three:

1) The JSON format { currency, value, fraction }
2) The human-readable standard decimal form TESTKUDOS:95.00
3) The pretty-printed form, where rendering and parsing and display
might even depend on the user locale or other settings

The bank currently uses format (2) instead of (3), which probably is not what we want.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014465)
Marcello Stanisci   
2019-05-30 14:56   
We spoke about splitting our glossary as user -vs- devs. So this must belong to devs'.
(0014670)
Christian Grothoff   
2019-07-14 11:55   
Meta-question: do we want to preserve the JSON format? The string format is more compact, and we could avoid the entire issue by just having always the CURRENCY:value.fraction format instead of having two.
(0014677)
Marcello Stanisci   
2019-07-15 18:34   
About the meta-question: I remeber someone suggested to *drop* the currency component from our amounts at some point. In that case, I would keep the JSON amount since it feels more "structured". If instead we keep the currency around, then I agree in dropping the JSON format and only have the stringified version.
(0014678)
Marcello Stanisci   
2019-07-15 18:39   
About the report: the bank communicates amounts to their customers with this format (just checked on a profile page and on public histories page on 'test'): 100.00 TESTKUDOS.

So no semicolon used and not very unfriendly.
(0014684)
Christian Grothoff   
2019-07-15 19:31   
Eh, I am thinking of dropping the currency in the database schema, but that's for a different reason. Other than _inside_ of the database, we'll keep the currency around.
(0014685)
Christian Grothoff   
2019-07-15 19:31   
Oh, and how we show things to users in the user interface should not be affected at all, that should ideally be controlled by the locale.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5487 [Taler] deployment and operations minor have not tried 2018-11-27 10:53 2019-07-15 18:55
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: set up system monitoring on gv
Description: On tripwire, we previously ran into the issue of a full /tmp directory.

With gv, we should have monitoring in place to inform us of abnormal states, such as full disks or excessive memory use.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014680)
ng0   
2019-07-15 18:55   
ack, will get to this after GSoC.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5642 [Taler] documentation text have not tried 2019-03-12 13:17 2019-07-15 18:51
Reporter: Marcello Stanisci 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 section about the exchange bank account setup.
Description: > For _me_ it was crystal-clear, but maybe we should switch to a more
> didactical style
> for this section where Nuria is stuck?

I think the first problem is that the example given does not work.
The payto://sepa/ is not implemented, we should instead give a
payto://x-taler-bank/ here (or no payto and leave it for later).

Also nothing says how you get the "right" bank account number. In
section 3.6.1, the bank account number is MISSING in the
payto://-example provided.

I think it would be good to add example commands ($ taler-config ...) to
run, to refer to the Taler bank (bank.git) documentation for 3.6.1, and
to give some way to _check_ that everything is correct that doesn't
involve starting the exchange. For example, running

$ taler-exchange-wire && echo everything OK

and ensuring that taler-exchange-wire does NOT return 0 if the
configuration has mistakes in it.


Tags:
Steps To Reproduce:
Additional Information: The description comes from a private discussion that was triggered by some users trying to install the exchange,
and it refers to the exchange manual.
Attached Files:
Notes
(0014679)
ng0   
2019-07-15 18:51   
ack, will get to it after GSoC.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5762 [Taler] auditor minor have not tried 2019-06-11 13:07 2019-07-15 15:40
Reporter: Marcello Stanisci 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: Website should obey to a prefix value.
Description: The auditor(.git) Website has no mean to take the installation prefix from the user. On the one hand, this is right/understandable, because all the HTML lives under the repository itself. The wrong thing is that all the dependencies (Babel, for now) get installed under "~/.local", and this makes less obvious ("rm -fr *" does not catch it!) to erase everything and try a Taler installation in a clean user environment.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014674)
ng0   
2019-07-15 15:40   
ack. Will get to this after GSoC.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5621 [Taler] documentation text have not tried 2019-03-01 22:36 2019-07-15 15:38
Reporter: Marcello Stanisci 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: Auditor manual required.
Description: We need a manual for installing/operating the auditor just like we have for all the other services.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014391)
ng0   
2019-05-13 18:47   
Unless this is meant to be worked on by more than one person, I will do this.

If you think this is out of scope or someone else should work on this, send me a message here or an email.
(0014673)
ng0   
2019-07-15 15:38   
I will get to this after GSoC ends. Should any questions occur, I will contact those most involved with auditor.


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-07-14 14:05
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.6  
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:
5595 [Taler] Web site(s) minor have not tried 2019-02-21 16:38 2019-07-14 11:52
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: Move to bootstrap 4
Description: As requested in 0005524 and by Christian per Email, moving the website to bootstrap 4.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014134)
ng0   
2019-03-03 17:00   
(Last edited: 2019-03-03 17:00)
Done in commits 5bd8913c to d13013d9
Added a hamburger to the menu for now, happened as a side effect of debugging the menu.
Feel free to remove. Colors are best effort improving on bs4 defaults.

Status: Feedback if okay.

(0014146)
Christian Grothoff   
2019-03-05 14:01   
Eh, did you push to master? stage.taler.net and taler.net still show bootstrap 3.x for me here.
(0014148)
ng0   
2019-03-05 14:12   
Yes I did.

That's a separate issue. stage.taler.net doesn't seem to build on the server at the moment..
locally no problem.
(0014149)
ng0   
2019-03-05 14:18   
If you look at view-source:https://stage.taler.net/en/wallet.html you will see that stable from around January is not even in stage.
(0014178)
Christian Grothoff   
2019-03-10 14:14   
Why is that? Stage should be == master. "somebody" should look into this.
(0014208)
ng0   
2019-03-15 15:36   
I can do this, but so far I suspect it's on a server I don't have administration rights to.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5683 [libmicrohttpd] build system minor have not tried 2019-04-07 13:48 2019-07-14 00:01
Reporter: ng0 Platform: amd64  
Assigned To: OS: NetBSD  
Priority: normal OS Version: 8.99.36  
Status: new Product Version: 0.9.63  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: perf_get_concurrent fails
Description: ===========================================================
   GNU Libmicrohttpd 0.9.63: src/testcurl/test-suite.log
===========================================================

# TOTAL: 37
# PASS: 36
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: perf_get_concurrent
=========================

Parallel GETs using internal thread with select(): 10471.204188 requests/s
Parallel GETs using internal thread with select() and thread per connection: 9090.909091 requests/s
Parallel GETs using internal thread pool with select(): 9569.377990 requests/s
Parallel GETs using external select: 9661.835749 requests/s
Parallel GETs using internal thread with 'auto': 9803.921569 requests/s
Parallel GETs using internal thread with 'auto' and thread per connection: 9009.009009 requests/s
Parallel GETs using internal thread pool with 'auto': 9302.325581 requests/s
Parallel GETs using internal thread with poll(): 10526.315789 requests/s
curl_easy_perform failed: `Couldn't connect to server'
Error performing internal thread with poll() and thread per connection test: curl error
Parallel GETs using internal thread pool with poll(): 9523.809524 requests/s
Error (code: 4)
FAIL perf_get_concurrent (exit status: 1)

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014273)
ng0   
2019-04-07 14:06   
More info: This affected the `make test` on my system pkgsrc-wip checkout (failed the test on 1st and 2nd run), but it did not affect the run of the test on an older NetBSD of someone else (in other words, succeeded there, same architecture).
(0014274)
ng0   
2019-04-07 14:13   
Correction: success on 2nd run here too. So it can't be reproduced easily.
(0014445)
Karlson2k   
2019-05-27 14:55   
Could you re-try with updated master?
You can try several runs to ensure that no test fail.
(0014452)
ng0   
2019-05-27 21:34   
Okay, will do so later this week.
(0014453)
ng0   
2019-05-27 21:35   
I can't assign bugs to myself here, if with my access level here it is possible for you, please assign it to me. otherwise tell me and I'll just make a note on paper to remind myself.
(0014454)
Karlson2k   
2019-05-28 09:47   
This bug should be already fixed.
No need to assign, just need confirmation that problem is fixed for you as well.
(0014500)
Karlson2k   
2019-06-03 10:20   
ng0, any report is appreciated.
My tests on NetBSD 7.2 and 8.0 were fine, except fact that TCP_PUSH do not work well on this platform so some *11 tests are taking too long to complete (5 requests per second is too slow).
(0014669)
ng0   
2019-07-14 00:01   
NetBSD 8.99.48 GENERIC amd64: passes, but hangs as observed before.
No idea which 8.99.* someone was on who reported to me that the testsuite does not work (or what it was), or which architecture.
But if any regression appears in pkgsrc platforms I will be able to handle this after gsoc. The new release is now in pkgsrc upstream and I'm the package maintainer.

PASS: test_https_get_select
SKIP: test_tls_options
PASS: test_tls_authentication
PASS: test_https_get_parallel
SKIP: test_https_get_parallel_threads
PASS: test_https_sni
SKIP: test_https_session_info
PASS: test_https_time_out
PASS: test_https_multi_daemon
PASS: test_https_get
PASS: test_empty_response
============================================================================
Testsuite summary for GNU Libmicrohttpd 0.9.65
============================================================================
# TOTAL: 11
# PASS: 8
# SKIP: 3
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
Making check in .
Making check in examples
Making check in .
Making check in .
Making check in po
Making check in doc
Making check in .
Making check in doxygen
Making check in examples
Making check in .


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5801 [GNUnet] documentation minor have not tried 2019-07-11 15:35 2019-07-11 15:35
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: change doxygen version title
Description: The generated doxygen still refers to GNUnet 0.10.x in the header. This will be confusing for people.
Let's either drop the version (not got) or bump the string to 0.11.x, or update the version with every
release.
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:
4615 [GNUnet] other feature N/A 2016-08-10 23:24 2019-07-11 12:14
Reporter: lynX Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: SVN HEAD  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: How should a client application's autoconf check for the availability of GNUnet?
Description: Here's the blurb of code that I inserted into configure.ac of the psyclpc driver in order to detect if GNUnet is installed, libgnunetcadet is available and the crypto is sane.

It isn't ideal because it uses the deprecated GC_u2h() function, but everything else in cadet_api.c looked less suitable for a quick test to me.

The other impractical thing is the terrible number of necessary includes which even need to be in that order to not break and produce odd error messages. This is not exactly spectacularly good developer UX. Looks like some header files are missing the classic multiple-include protection construct:

  #ifndef GNUNET_UTIL_LIB_H
  #define GNUNET_UTIL_LIB_H

And I really didn't understand why, in the role of a developer writing some code against GNUnet, I should have to manually include platform.h which doesn't even conform to the naming standards. My "developer expectation" was that I should only need #include <gnunet/gnunet_cadet_service.h> and that would fetch all the essential dependencies by itself, this way also reducing the chances that my code will break with some later gnunet version. Is there any higher reasoning for this behavior, or should I just go ahead and streamline those header file dependencies?

Actually my "developer/user expectation" would be that #include <gnunet/cadet.h> should be the thing. Even "service" is an implementation detail that could change in future.
Tags:
Steps To Reproduce:
Additional Information: #include <gnunet/platform.h>
#include <gnunet/gnunet_crypto_lib.h>
#include <gnunet/gnunet_common.h>
#include <gnunet/gnunet_util_lib.h>
#include <gnunet/gnunet_cadet_service.h>

int main(void) {
    const struct GNUNET_HashCode *hash = GC_u2h (4404);
    const char* expect = "VFQCGVPZJJ6PHN5DQ6NWH1BJY3Q3SNF0BVCT2B1S4Q915SMYHDRW1X2BFTEEWXG9ZC23PVH3Y1W6D4DRKRTHV2CFGHAW66W52QGM0B8";
    printf( "u2h(4404) = %s ... ", GNUNET_h2s( hash ) );
    if (strcmp(expect, GNUNET_h2s_full( hash ))) return -1;
    return 0;
}
Attached Files:
Notes
(0011032)
Christian Grothoff   
2016-08-17 00:36   
The problem is that 'platform.h' depends on gnunet_config.h so that it can #include the right system headers. Given the different platforms we have (W32, OSX, Solaris, GNU) it is _impossible_ to do this in a portable way without reliance on a configure-generated config.h.

However, we're not supposed to #include 'gnunet_config.h' as that's not a stable header. So the 'platform.h' provides a _convenience_ way around it by defining the platform-specific headers, which you do not have to use if your project has its own way of detecting and #including platform-specific details.

So I'd love to clean this up, but am not aware of a fix that would then still allow the code to build on the various target platforms. Not to mention testing any change there on 4-6 platforms isn't my definition of good fun.
(0011033)
Christian Grothoff   
2016-08-17 00:37   
(Last edited: 2016-08-17 00:40)
Oh, and in the above

#include <gnunet/gnunet_crypto_lib.h>
#include <gnunet/gnunet_common.h>
#include <gnunet/gnunet_util_lib.h>

are definitively not required.
You should only ever need platform + subsystem, and please note that some projects that use GNUnet don't use the GNUnet-platform header their, but their own (!).

(0011034)
Christian Grothoff   
2016-08-17 00:38   
Oh, and using GC_u2h is a terrible idea, as it will disappear very soon. It was introduced as a short-term hack, and it will die before the next release.
(0011037)
lynX   
2016-08-17 11:20   
> So I'd love to clean this up, but am not aware of a fix that would then still allow the code to build on the various target platforms.

Actually it is very simple. You can make gnunet_cadet_service.h also include platform.h or make a cadet.h which contains these two lines:

#include <gnunet/platform.h>
#include <gnunet/gnunet_cadet_service.h>

It is no drama that some files are generated on installation, but it is unwise if applications needlessly contain specific things that may go away in future versions, no?

> Oh, and using GC_u2h is a terrible idea

That's why I opened up this report. I don't see a better option.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5637 [GNUnet] webpage minor have not tried 2019-03-11 20:18 2019-07-10 15:24
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: extend FAQ
Description: frequent questions post-0.11.0 release in social networks:

> How does this compare with ipfs?

> in general a brief explanation of what it does in easy language?

> what's the difference between GNUnet and i2p?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014637)
ng0   
2019-07-03 12:53   
This can be split into /comparison ( 0005790 ) :

> How does this compare with ipfs?
> what's the difference between GNUnet and i2p?

and this can be considered for a different section (our website should explain it in easy terms, regardless of background etc!):

> in general a brief explanation of what it does in easy language?


If you close this, please update tickets resulting from this first (we did extend the FAQ already, but the content here remains unsolved!)
(0014664)
ng0   
2019-07-10 15:24   
We can reuse this, wikipedia linked to this.

https://web.archive.org/web/20180616130316/https://gnunet.org/compare


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5799 [GNUnet] webpage feature have not tried 2019-07-10 12:00 2019-07-10 12:00
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: integrate an (URL) link checker
Description: Rationale: we should not deploy websites which link to unavailable URLs. If we could have an integration external or internal, checking for the status of the links, that would be great.
This could be done in a couple of lines of the programming language of your choice (python, rust, ...)
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:
5710 [GNUnet] transport service feature N/A 2019-05-02 14:28 2019-07-09 13:53
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: assigned Product Version: 0.11.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.12.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:
5548 [GNUnet] transport service feature N/A 2019-02-08 18:59 2019-07-08 11:21
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.12.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:
5549 [GNUnet] transport service feature N/A 2019-02-08 19:03 2019-07-08 11:21
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.12.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:
5550 [GNUnet] transport service feature N/A 2019-02-08 19:06 2019-07-08 11:21
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.12.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:
5796 [GNUnet] transport service major always 2019-07-07 22:40 2019-07-08 11:21
Reporter: ch3 Platform:  
Assigned To: ch3 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wrong return value of TNG communicator test
Description: Even if it fails (because of missing configuration files for example) it returns 0.
Tags:
Steps To Reproduce: make test_communicator_unix && ./test_communicator_unix
Additional Information:
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-07-08 11:21
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.12.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:
5797 [GNUnet] transport service major random 2019-07-07 22:42 2019-07-08 11:20
Reporter: ch3 Platform:  
Assigned To: ch3 OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Race condition in TNG unix communicator test
Description: Sometimes the test locks itself as a result of a race condition.
I need to investigate the cause.
Tags:
Steps To Reproduce: make test_communicator_unix && ./test_communicator_unix
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5708 [GNUnet] build process feature have not tried 2019-04-30 18:46 2019-07-07 21:26
Reporter: Florian Dold 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:  
Summary: configure script should output summary of configuration, including libraries picked
Description: The configure script has lots of auto-detection. At the end, there should be a comprehensive summary of the build configuration.

Having this would help with bugs like 0005707, since it would be immediately visible that *both* libgnurl and libcurl are enabled, which is bogus.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014362)
ng0   
2019-05-01 17:15   
so basically extend what we have in the configure script already (at the end of it) and optionally output it to a file
(0014363)
Florian Dold   
2019-05-01 18:55   
Yes. There is also another slightly related feature, that maybe it can be done in one go.

Many packages (I count 150 on my system) have a <pkgname>-config program, including curl and libgcrypt. The gnunet-config tool in GNUnet already does something else, but I've discussed with Christian that we could add flags to gnunet-config to print out the package configuration and basically serve