View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7040 [Anastasis] C reducer implementation minor have not tried 2021-10-17 21:48 2021-10-19 13:13
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: reducer stores truth metadata redundantly and weirdly
Description: The reducer currently stores some truth-related data redundantly. A truth can be used by multiple policies, but the truth data is repeated in the "policies[*].methods" objects multiple times.

Instead, there should be a top-level "truth_info" object, indexed by the truth key `${methodIndex}:${providerUrl}`.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: anastasis-redundant.json (10,722 bytes) 2021-10-19 13:13
https://bugs.gnunet.org/file_download.php?file_id=1109&type=bug
Notes
(0018440)
Florian Dold   
2021-10-19 13:13   
In the attached reducer state, the truth with UUID "WS6WJX7TB8SGCWHEW02JDC2J7HB7WFEDP2VQPR1NA8T0WHMRT080" is stored twice, with exactly the same data.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7044 [Anastasis] C reducer implementation minor have not tried 2021-10-19 13:07 2021-10-19 13:07
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: C reducer returns malformed error response when provider is offline
Description: {
    "http_status": 0,
    "upload_status": 10,
    "provider_url": "http://localhost:8089/"
}

=> the "code" field is missing, and a "hint" and "details" field should ideally be present.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7041 [Taler] wallet (WebExtensions) feature always 2021-10-18 14:20 2021-10-18 14:25
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: git (master)  
Summary: remove the "accept tos" in the withdrawal, create an "add exchange" wizard
Description: All the exchange management looks like:

    complex (I the sense that the user needs to take into account a lot of information with small details),
    important (this decision will persist over the time and it may not be intuitive how to change it or that the user has the ability to change it)
    big (there the privacy policy, terms of service and different fees)
    not related to the normal userflow (adding exchange should be not a common operation of the user)

Our current solution is taking into account the terms of service but it should also display the privacy policy, the fee structure and the audit condition of the exchange.

My proposal is to remove the in-place "accept ToS" of the exchange and move it to a wizard form and just leave a select input for the known-and-all-good exchanges. All good means that there is not issue that need the user attention.

Adding the exchange then will be a wizard like procedure, with the objective to solve the previously described problems:

    complex: the wizard will give space to show explanation to the user about whats going on
    important: being the opposite of put-an-url-and-done will make the user think twice before adding
    big: we can use part of the wizard to show how fee is going to apply in the future, how long the coins are going to last, how is privacy protected and tell them to backup

If the exchange changes its pp, tos or fee we can jump in into the correct step of the wizard.

Drawbacks:

Adding an exchange can be as easy as put-an-url-and-go and this solutions will make the user "waste" more time and energy, but I think it worth it.

What could we do for pre-filled exchanges? I think that it should also go through the whole wizard procedure but with the benefit that user won't need to type anything, just read and click.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018439)
Christian Grothoff   
2021-10-18 14:25   
I disagree. Most users should never manually add exchanges, but we do need them to explicitly (!) agree to the ToS. Thus, we need to do this inline during the _first_ withdrawal process at an exchange. I'd not show the privacy policy (that's not required), and showing the fees is a different dialog that is always on, not only if the ToS changed or it is a first-time user. Making the privacy policy -only- accessible via the exchange list (where we can add exchanges) is fine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7039 [Taler] mechant backend major always 2021-10-15 11:44 2021-10-15 11:48
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.1  
Summary: merchant contract terms hashing violates RFC 8785
Description: The merchant currently doesn't replace Unicode characters by escape characters like RFC 8785 Section 3.2.2.2 [1] demands.

The wallet does follow RFC 8785, and thus the merchant and wallet disagree on the contract terms hash.

[1] https://datatracker.ietf.org/doc/html/rfc8785#section-3.2.2.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:
7038 [libeufin] command-line tools minor have not tried 2021-10-14 17:16 2021-10-14 17:17
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Avoid sending credentials when auth values aren't found in the environment
Description: In such cases, the CLI sends a username and password pair of None:None. Instead,
it should request without including the Authorization header.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018438)
ms-mantis   
2021-10-14 17:17   
This was observed along the requests made to the Sandbox.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7037 [Anastasis] backend minor have not tried 2021-10-14 15:59 2021-10-14 16:00
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: backend tests are failing during payment
Description: The anastasis backend tests (in testing/) are currently failing for me. It doesn't look close to anything I've changed, and the error seems to be related to payments:

2021-10-14T15:52:44.918320+0200 taler-merchant-httpd-94724(DX53RQR2T9QXPV38YGMQANZKAM) ERROR Assertion failed at taler-merchant-httpd_post-orders-ID-pay.c:466. Aborting.

I've attached the full test-suite.log.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: test-suite.log (747,293 bytes) 2021-10-14 15:59
https://bugs.gnunet.org/file_download.php?file_id=1108&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7036 [Anastasis] C reducer implementation minor have not tried 2021-10-13 17:33 2021-10-13 17:33
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: reducer returns odd error message when one provider is offline
Description: If one provider is offline, the action "enter_user_attributes" from state "USER_ATTRIBUTES_COLLECTING" results in an odd error response:

{"detail":"failed to 'lookup_cost'","code":8401,"hint":"The given state of the reducer is invalid."}
Tags:
Steps To Reproduce: Make a backup with all Testland providers, kill one of them, try to make a recovery.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7035 [Taler] merchant backend API (C) crash always 2021-10-13 11:28 2021-10-13 13:55
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: merchant crashed when paying order
Description: it's mostly the case that I'm missing some configuration, but it should not crash

tested version: Version: 0.8.4-1
it was installed from latest release as a debian package

Thread 1 "taler-merchant-" received signal SIGSEGV, Segmentation fault.
0x0000558b84de1ecf in process_find_operations (exchange=exchange@entry=0x558b85f11d80) at taler-merchant-httpd_exchanges.c:577
577 taler-merchant-httpd_exchanges.c: No such file or directory.
(gdb) info locals
fbw = 0x558b85f3a840
fo = 0x558b85f3dfc0
fn = 0x0
now = {abs_value_us = 1634116857692024}
need_wire = false
__FUNCTION__ = "process_find_operations"
(gdb) print "%x", fbw->af
$1 = (struct TALER_EXCHANGE_WireAggregateFees *) 0x0
quit)
Tags:
Steps To Reproduce: create an order
try to pay it
Additional Information:
Attached Files:
Notes
(0018436)
sebasjm   
2021-10-13 13:54   
adding wire fee information solved the issue

previous configuration that reproduce the error in [1] (the dates goes from jan 1 2020 to jan 1 2021)
current configuration that works ok [2]




[1]
{
  "accounts": [
    {
      "payto_uri": "payto://x-taler-bank/bank.taler:5882/sebasjm",
      "master_sig": "CAKK3HDWY5DVGTTTPFGSASS96FGJKAWMP41RYCV7MVBEX3WJ108JSNWN5DP8ZZM215TM69NZWVCBR3QNNRX1KJS7KD32VWS3GG5C60R"
    }
  ],
  "fees": {
    "x-taler-bank": [
      {
        "wire_fee": "NERDS:0.1",
        "closing_fee": "NERDS:0.1",
        "start_date": {
          "t_ms": 1577836800000
        },
        "end_date": {
          "t_ms": 1609459200000
        },
        "sig": "XP1H2GMKJVRDMFB71PDHYMQSJ3144GAVPM502JPRWKMDQAZGY7VVZ1206PMV1G5D6TY2DEYKB0RDJ7AF0PFA57MY7QSVRZX2XERS61G"
      }
    ]
  },
  "master_public_key": "958T0MBFHSKGZRZ3EM7KRRZGVX66M2S368WE7ED0T87TEB3BNPEG"
}

[2]
{
  "accounts": [
    {
      "payto_uri": "payto://x-taler-bank/bank.taler:5882/sebasjm",
      "master_sig": "CAKK3HDWY5DVGTTTPFGSASS96FGJKAWMP41RYCV7MVBEX3WJ108JSNWN5DP8ZZM215TM69NZWVCBR3QNNRX1KJS7KD32VWS3GG5C60R"
    }
  ],
  "fees": {
    "x-taler-bank": [
      {
        "wire_fee": "NERDS:0.1",
        "closing_fee": "NERDS:0.1",
        "start_date": {
          "t_ms": 1577836800000
        },
        "end_date": {
          "t_ms": 1609459200000
        },
        "sig": "XP1H2GMKJVRDMFB71PDHYMQSJ3144GAVPM502JPRWKMDQAZGY7VVZ1206PMV1G5D6TY2DEYKB0RDJ7AF0PFA57MY7QSVRZX2XERS61G"
      },
      {
        "wire_fee": "NERDS:0.1",
        "closing_fee": "NERDS:0.1",
        "start_date": {
          "t_ms": 1609459200000
        },
        "end_date": {
          "t_ms": 1640995200000
        },
        "sig": "0PDS8N4226W8AVV0GQ8CQ0J2RQBF9D9FYGFKRAFB983JF1PQ8ECBWS7HHYPG34J723MJH0YS30GX4TVFNGFH9PKK4Z4M7FWNKY28M1G"
      },
      {
        "wire_fee": "NERDS:0.1",
        "closing_fee": "NERDS:0.1",
        "start_date": {
          "t_ms": 1640995200000
        },
        "end_date": {
          "t_ms": 1672531200000
        },
        "sig": "S3P825FA8PXQDSQKJR0BHZ28GNFEPVR9NJ169XSPPSTFCP4WAV2W5T9333K2SY1NAEX33AT04E795HADYJ15RBMHWBHYJF82DDGWT3R"
      }
    ]
  },
  "master_public_key": "958T0MBFHSKGZRZ3EM7KRRZGVX66M2S368WE7ED0T87TEB3BNPEG"
}
(0018437)
Christian Grothoff   
2021-10-13 13:54   
Crash should be fixed in 862ef7c..9d7abac


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7034 [Taler] mechant backend minor have not tried 2021-10-13 07:59 2021-10-13 07:59
Reporter: ms-mantis Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: URL-decode the authentication token.
Description: The merchant backend should URL-decode the token it reads from the Authorization:-header.
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:
7033 [GNUnet] build process minor have not tried 2021-10-10 20:06 2021-10-11 23:43
Reporter: schanzen Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.15.4  
Summary: Cleanup configure flags
Description: There are a lot of unused/old flags we should get rid of.
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:
7029 [GNUnet] DHT service crash sometimes 2021-10-05 20:45 2021-10-10 20:17
Reporter: md Platform: GNU/Linux  
Assigned To: Christian Grothoff OS: Guix System  
Priority: normal OS Version: v???  
Status: resolved Product Version: 0.13.1  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.15.4  
    Target Version: 0.15.4  
Summary: Assertion failure in get_target_peers (when allocating rtargets)
Description: When testing the "http://localhost:8089/search-dht" form of Scheme-GNUnet,
 gnunet-service-dht crashed with the following message:

okt 05 20:07:27-878394 dht-25189 ERROR Assertion failed at gnunet-service-dht_neighbours.c:1181. Aborting.

Looking at gnunet-service-dht_neighbours.c:1181, that's

  rtargets = GNUNET_new_array (ret,
                               struct PeerInfo *);

so maybe 'ret' was to large? 'ret' is assigned by:

  ret = get_forward_count (hop_count,
                           target_replication);

so maybe get_forward_count returns a too large result?

Curiously, the crash only happens if the replication level is zero, and not if it is one.
Also note that that the network size (according to $GNUB/gnunet-nse) is 1:
1633458666879901 1,000000 0,000000 -nan

and ‘target_value’ is:

  target_value =
    1 + (target_replication - 1.0) / (GDS_NSE_get ()
                                      + ((float) (target_replication - 1.0)
                                         * hop_count));

So for target_replication=0, target_value = 1 - 1/(0 + (1 - 1) * hop_count) = 1 - 1/0 = some kind of infinity (or NaN?).
(GDS_NSE_get() is (an approximation of) the logarithm of the network size, so it is approx. equal to 0 here).

So target_value becomes infinity (or, allowing for numerical issues, at least very large in magnitude).
Then the forward count is set to

  forward_count = (uint32_t) target_value

I don't know what is the result of casting an infinity or NaN to an integral type, but I wouldn't recommend it. Maybe it can be very large?
Tags:
Steps To Reproduce: For developing/testing Scheme-GNUnet, I run the following services: dht, statistics, core, nse and peerinfo (no ARM!).
Additional Information:
System Description
    INFO: OS : Linux
    INFO: OS RELEASE : 5.8.15
    INFO: HARDWARE : x86_64
Attached Files:
Notes
(0018428)
md   
2021-10-06 16:36   
My calculation for target_replication=0 and GDS_NSE_get()=0 is bogus, it should be

target_value = 1 - 1/(0 + -1* hop_count)= 1 + 1/hop_count.

However, an infinity is still possible if hop_count = 0. I don't know if that can happen though.
(0018429)
Christian Grothoff   
2021-10-06 18:51   
Seems likely. Still, how did you end up with a target_replication of 0?
(0018430)
Christian Grothoff   
2021-10-06 18:53   
Fix committed to master branch.
(0018431)
Christian Grothoff   
2021-10-06 18:54   
e173017ed..6ef071b8c fixes the crash by forcing the target_replication to be in a 'sane' range. Still wonder how 0 appeared, but at least the crash should be fixed now.
(0018432)
md   
2021-10-06 19:02   
The example mini-application I'm writing allows choosing any replication level, including 0. I'll look into making the minimum level 1!

Unfortunately, Mantis doesn't allow commenting on resolves issues, so I had to reopen the issue.
(0018433)
Christian Grothoff   
2021-10-06 19:07   
I see. Ok, that explains it then. reopening: no problem. I'll consider this resolved then.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7006 [GNUnet] postgres library minor have not tried 2021-08-28 19:22 2021-10-10 20:14
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.15.4  
    Target Version: 0.15.4  
Summary: merchant dbinit does not properly report errors
Description: It just tells me "3".

$ sudo -u taler-merchant-httpd taler-merchant-dbinit -c /etc/taler/taler.conf
2021-08-28T17:17:37.295109+0000 taler-merchant-dbinit-418734 WARNING Could not run PSQL on file /usr/share/taler//sql/merchant/merchant-0000.sql: 3
2021-08-28T17:17:37.295186+0000 taler-merchant-dbinit-418734 ERROR Failed to run SQL logic to setup database versioning logic
2021-08-28T17:17:37.295238+0000 taler-merchant-dbinit-418734 ERROR Failed to initialize tables
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018139)
Christian Grothoff   
2021-08-28 20:23   
That's because it doesn't have more: it forks the "psql" binary, and the only thing we have is the psql binary exit code.
(0018140)
Florian Dold   
2021-08-28 21:00   
Ah. But then why don't we just let psql inherit stderr, so we get a decent error message? And currently the error message *looks* broken. Is the "3" a line number, an exit status or ...? At least we should indicate in the log text that this is the exit status of psql.
(0018141)
Christian Grothoff   
2021-08-28 21:54   
Fixed error message text and inherited stderr as of 7a4c1fb72..2994fa434
(0018142)
Christian Grothoff   
2021-08-28 21:54   
(Note that this is a GNUnet change.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7032 [Taler] exchange API (HTTP specification) tweak N/A 2021-10-09 12:51 2021-10-09 12:51
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: 0.8.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: migrate to 16 byte wire account salts
Description: We currently use 64 byte salts, which is inefficient and overkill. This change breaks compatibility!
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:
5774 [Taler] wallet (WebExtensions) feature have not tried 2019-06-25 14:49 2021-10-05 17:51
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
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:
Notes
(0018398)
sebasjm   
2021-09-20 03:52   
So, if I understood this correctly this is like starting a withdrawal process where the wallet create a reserve to be fulfilled with the wire transfer but instead this reserve can be filled up with a wire transfer or a payment from other wallet. Am I correct?
(0018426)
sebasjm   
2021-10-05 14:16   
I have implemented this feature into the Taler Wallet Webextension. It will be nice to have some feedback from the a design point of view.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5860 [Taler] wallet (WebExtensions) minor have not tried 2019-08-29 10:07 2021-10-05 14:34
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: browser wallet should allow completing an operation with a mobile/cli wallet
Description: There should be some button/link, and it should cause the wallet to render a QR code and link in lieu of the merchant/bank/audtior doing that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015050)
Florian Dold   
2019-11-02 21:27   
For this, the taler://pay QR code needs to be able to also transmit the nonce to the mobile wallet, as the browser wallet will have already claimed it.
(0018396)
sebasjm   
2021-09-17 20:51   
the wallet that create the qr/link now use a parameter to share the nonce-private
the wallet that use this link will detect this parameter and use that private nonce instead of creating a new one

couldn't test with android wallet but should works since I have tested with wallet cli
(0018427)
sebasjm   
2021-10-05 14:34   
Tested and works


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6459 [Taler] mechant backend feature N/A 2020-08-03 14:17 2021-10-04 21:18
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: show full contract wallet-style in merchant HTML page
Description: ASSUMING this is easily done based on what the wallet already has, we should modify the "show_order_details.en.must" template to include (existing!) JavaScript logic to properly render the JSON contract.

If such JS does not exist, and/or also in the long run, we should instead enhance our mustach template expansion capabilities so we can iterate over all contract fields and do everything mustach-template style so we can avoid needing any JavaScript.

Assigning to Florian so he can eval if existing Wallet code can easily plug this. If not, bump to 0.8.1 and we'll take care of it then via mustach.

Location in the code is marked with a FIXME and the bug number.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: sample_for_the_other_pages.png (49,291 bytes) 2021-09-22 18:08
https://bugs.gnunet.org/file_download.php?file_id=1105&type=bug
order_details.png (83,556 bytes) 2021-09-22 18:08
https://bugs.gnunet.org/file_download.php?file_id=1106&type=bug
merchant_backend_order_status_page.png (379,427 bytes) 2021-09-30 17:38
https://bugs.gnunet.org/file_download.php?file_id=1107&type=bug
Notes
(0016556)
Florian Dold   
2020-08-03 14:21   
Contracts are currently rendered via React, i.e. by client-side DOM manipulation. That's necessary in the WebExtension wallet, as in a web extension we don't have any server to render stuff for us ;-)

We could of course also use this code in the the merchant backend HTML page, but that drags in a lot of dependencies (well, mainly React.JS) that we might not want. It also wouldn't work without JavaScript anymore.
(0016557)
Christian Grothoff   
2020-08-03 14:26   
I understand that this won't work with JS anymore, that's why I suggested this as a temporary / quick fix (which means additional dependencies can also be OK). I don't think we'll have the time to do a proper (!) and fully equivalent MUST-based rendering for 0.8, and I don't think we want to show the raw JSON or _nothing_ for 0.8. So temporarily dropping in a JS-based solution seemed like an acceptable trade-off.
(0016685)
Florian Dold   
2020-08-20 16:37   
I don't think this is viable, because the wallet's rendering of the contract terms is very minimalist right now. The functionality we get from (temporarily!) integrating the JS code in the merchant backend HTML page isn't justified.

It would be more effective to pass the contract JSON into the mustache template. The mustac library can do this for another JSON library already (json-c): https://gitlab.com/jobol/mustach/-/blob/master/mustach-json-c.h

I'll work on making jansson work with mustach.
(0016686)
Florian Dold   
2020-08-21 17:57   
Putting this on feedback as the following questions are open:

1. Do we really need the label mechanism in the contract terms, or can we inline labels for better rendering, and introduce a tag for a "URL location"
2. The "Location" definition seems incomplete, shouldn't we at least have additional "free form" address lines?
3. What parts of the contract terms should be rendered on the page? Should we really list auditors/exchanges and h_wire? Is the following list enough?
    * summary
    * amount
    * product list (with pictures if available)
    * merchant information
  should probably be enough?
(0016694)
Christian Grothoff   
2020-08-21 20:52   
(Last edited: 2020-08-21 20:52)
I would allow seeing auditors/exchanges and locations via buttons to 'expand' certain details (similar to what we used to do in some wallets).
[That is, if JavaScript is enabled. So maybe if JS is off, show everything, if it is on, hide certain details behind buttons to 'expand'].

(0018134)
sebasjm   
2021-08-27 17:31   
working on this.
the page should work with and without js so i will do a build time rendering.
(0018144)
sebasjm   
2021-08-31 06:00   
there is a full react html page that mimic the same design in merchant-backoffice repository (https://git.taler.net/merchant-backoffice.git/tree/packages/backend)

we can iterate the design there and new version will be deployed with the merchant backend as the spa.html
mustache placeholders are kept for server side rendering

one last step is missing: i need help updating the Makefile.am to correctly copying from the merchant-backend submodule to the merchant distribution folder :)
(0018146)
Christian Grothoff   
2021-08-31 11:26   
To discuss this with Belen, it would be best if you could (manually) create a full-featured contract (JSON with _all_ the optional fields set to something) and had an easy way to render this contract with your page in a browser....
(0018406)
belen   
2021-09-22 18:08   
I've attached some design suggestions. I agree with Florian that rendering all the items in the contract terms is probably not necessary. I've kept things quite simple as a starting point.
(0018417)
Christian Grothoff   
2021-09-28 18:24   
(Last edited: 2021-09-28 18:25)
Full-contract page (with selective disclosure) is used in the following contexts:

1. Merchant SPA
2. Web Extension
3. Android Wallet
4. Merchant backend order status page (untrusted, possibly without JS).
(0018423)
belen   
2021-09-30 17:38   
Here comes a version 2 showing all the information in the contract except 1) nonce (I didn't think this should be included. Let me know if I am mistaken) and 2) product image (it seems somehow out of place, and I rather keep the page as simple as possible).

The approach iI followed was grouping items into logical headings, and roughly sort those headings based on their interest for the customer.
(0018425)
sebasjm   
2021-10-04 21:18   
implemented in 62f34bf4


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7026 [Taler] deployment and operations tweak have not tried 2021-10-04 10:45 2021-10-04 12:20
Reporter: ms-mantis Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Configure all the merchant instances with libEufin
Description: the deployment repository contains some "*-with-eufin" / "*-sepa" / "*-iban" deployment
scripts that were used so far to make the blog deployed with libEufin. The remaining instances
should be configured just as the blog to run in a libEufin-banked environment.

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:
7028 [Taler] deployment and operations feature have not tried 2021-10-04 10:50 2021-10-04 12:20
Reporter: ms-mantis Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Port the demo system to use libEufin as the bank
Description: Meta-bug for:

0007026
0007027


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:
7027 [libeufin] sandbox minor have not tried 2021-10-04 10:48 2021-10-04 10:48
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Define API to allow the implementation of a SPA
Description: Such application will allow the use of Sandbox as it was the PyBank.

In other words, it will allow to create and manage a bank account, and to initiate Taler withdrawals.

Eventually, it will allow to see the list of the public bank accounts, in order to see how they get donations.
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:
7025 [Taler] mechant backend crash always 2021-10-01 17:47 2021-10-02 10:06
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: urgent OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: merchant database inconsistency after paying some orders
Description: The merchant-backend reports: The service failed to fetch information from its database. (code 53)

The merchant logs reports:
ERROR Assertion failed at taler-merchant-httpd_private-get-orders.c:339.
ERROR Assertion failed at taler-merchant-httpd_private-get-orders.c:777.

It seems that it's when getting order from the database. Looking up the code, first the merchant does
TMH_db->lookup_orders
at 766 and which doing manually returns

        order_id | order_serial | creation_time | bool | bool | bool
------------------------+--------------+------------------+------+------+------
 2021.274-020C7M4QR5GYG | 6 | 1633096279000000 | f | f | f
 2021.274-00BCRHWC1BK26 | 5 | 1633095939000000 | f | f | f
 2021.274-02G87N48SX0PM | 4 | 1633095785000000 | f | f | f

for the first part (looking up the orders table) and

        order_id | order_serial | creation_time | bool | bool | bool
------------------------+--------------+------------------+------+------+------
 2021.274-020C7M4QR5GYG | 6 | 1633096279000000 | f | f | f
 2021.274-00BCRHWC1BK26 | 5 | 1633095939000000 | f | f | f
 2021.274-02G87N48SX0PM | 4 | 1633095785000000 | f | f | f
 2021.274-02T2DX94B69QM | 3 | 1633095091000000 | f | f | f
 2021.274-014FFPFHMBXYR | 2 | 1633094975000000 | f | f | f

for the second part (looking up the contract terms table)

So, order 2 and 3 are the candidates for trouble.

taler-merchant-httpd_private-get-orders.c:312 seems to assume that it is only needed to look for order in the contract terms table ONLY if was paid which seems to not take into consideration claimed-but-not-paid orders.

Either this is wrong or maybe we should not deleted the order in the first place.

I have no enough logs but seems that the prepare statement "delete_completed_order" at plugin_merchantdb_postgres.c:7908 delete _ALL_ the order that have contract_terms.

Saving this information here and I will push the proper test case if I manage to reproduce it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018424)
Christian Grothoff   
2021-10-02 10:06   
8bb460c..813f0ea should fix this, alas untested as I don't have a "problematic" DB. Sebastian: Please check against the DB that you had where there was a problem, and add feedback and/or resolve the bug.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6533 [Anastasis] authentication methods feature N/A 2020-08-24 16:56 2021-09-30 14:44
Reporter: Dominik Meister Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: acknowledged Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Video authentication
Description: Implement Video Authentication
- Protocol update and design to work with video authentication
- Client side implementation
- Backend implementation
- Evaluation external service
- Integration of external service
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018422)
Christian Grothoff   
2021-09-30 14:44   
Internet research suggests that a _pure_ video authentication (against image of user) without *identification* (say using national identity documents as part of a KYC process) is not really something that is offered commercially today. At least I could not find a single provider after looking for quite some time. So deferring this feature until that situation fundamentally changes.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7014 [GNUnet] postgres library feature N/A 2021-09-07 19:48 2021-09-23 22:53
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: support checking that the database version is really the 'latest' version
Description: ... and refuse to run if it is not. That way, we don't accidentally try to run against a database that has not been upgraded after a system update.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018411)
Christian Grothoff   
2021-09-23 22:53   
8f18cbcaf6025d40fa1d400f5a4e702ad957809a extends the API to enable DB version checks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7020 [Taler] wallet (Android App) crash always 2021-09-17 14:50 2021-09-23 19:14
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: git (master)  
Summary: WalletBackendService gets killed, wallet stays in black background waiting for a response
Description: Device: SM-A510M
OS: Lineage 17.1

Logcat

2021-09-17 03:09:07.489 2650-2678/system_process E/ActivityManager: ANR in net.taler.wallet.fdroid:WalletBackendService
    PID: 17369
    Reason: executing service net.taler.wallet.fdroid/net.taler.wallet.backend.WalletBackendService
    Load: 0.0 / 0.0 / 0.0
    CPU usage from 167066ms to 0ms ago (2021-09-17 03:06:20.264 to 2021-09-17 03:09:07.330):
      33% 2444/surfaceflinger: 20% user + 12% kernel / faults: 689 minor 3 major
      7.1% 2746/irq/570-bhy: 0% user + 7.1% kernel
      4.7% 2650/system_server: 2.8% user + 1.9% kernel / faults: 6176 minor 298 major
      3.5% 10452/kworker/u17:3: 0% user + 3.5% kernel
      1.6% 1397/decon0: 0% user + 1.6% kernel
      1.2% 3278/com.google.android.gms.persistent: 0.9% user + 0.2% kernel / faults: 16006 minor 54 major
      0.8% 15699/kworker/0:3: 0% user + 0.8% kernel
      0.7% 16232/kworker/u17:2: 0% user + 0.7% kernel
      0.7% 2472/adbd: 0.1% user + 0.5% kernel / faults: 4912 minor 38 major
      0.6% 13565/kworker/0:1: 0% user + 0.6% kernel
      0.5% 1394/s3c-fb-vsync: 0% user + 0.5% kernel
      0.5% 15283/com.google.android.googlequicksearchbox:search: 0.4% user + 0% kernel / faults: 19274 minor 856 major
      0.4% 682/kswapd0: 0% user + 0.4% kernel
      0.3% 2841/com.android.systemui: 0.2% user + 0.1% kernel / faults: 1549 minor 64 major
      0.3% 2819/com.android.bluetooth: 0.2% user + 0% kernel / faults: 288 minor 27 major
      0.3% 23632/com.whatsapp: 0.2% user + 0.1% kernel / faults: 848 minor 133 major
      0.3% 1239/mmcqd/0: 0% user + 0.3% kernel
      0.3% 3099/com.android.phone: 0.2% user + 0% kernel / faults: 1049 minor 80 major
      0.2% 8/rcu_preempt: 0% user + 0.2% kernel
      0.2% 2312/logd: 0.1% user + 0.1% kernel / faults: 264 minor 49 major
      0.1% 2500/wificond: 0% user + 0.1% kernel / faults: 51 minor
      0.1% 31750/cfinteractive0: 0% user + 0.1% kernel
      0.1% 2603/dhd_dpc: 0% user + 0.1% kernel
      0% 15365/com.google.android.googlequicksearchbox:interactor: 0% user + 0% kernel / faults: 3756 minor 1503 major
      0.1% 29427/com.google.android.youtube: 0.1% user + 0% kernel / faults: 796 minor 9 major
      0.1% 3602/com.google.android.gms: 0% user + 0% kernel / faults: 1588 minor 100 major
      0.1% 16415/kworker/u16:0: 0% user + 0.1% kernel
      0.1% 3075/com.android.launcher3: 0% user + 0% kernel / faults: 3367 minor 1572 major
      0% 2418/android.hardware.bluetooth@1.0-service: 0% user + 0% kernel / faults: 2 minor
      0% 20878/com.sony.songpal.mdr: 0% user + 0% kernel / faults: 96 minor
      0% 2602/dhd_watchdog_th: 0% user + 0% kernel
      0% 8984/com.google.android.gms.unstable: 0% user + 0% kernel / faults: 832 minor 172 major
      0% 2498/statsd: 0% user + 0% kernel / faults: 24 minor 1 major
      0% 2502/rild: 0% user + 0% kernel / faults: 27 minor 7 major
      0% 15753/kworker/u16:1: 0% user + 0% kernel
      0% 2415/zygote: 0% user + 0% kernel / faults: 781 minor
      0% 2442/lmkd: 0% user + 0% kernel / faults: 4 minor
      0% 25036/com.android.chrome: 0% user + 0% kernel / faults: 429 minor 32 major
      0% 1055/irq/10-bt532_ts: 0% user + 0% kernel
      0% 15835/logcat: 0% user + 0% kernel / faults: 4 minor
      0% 2313/servicemanager: 0% user + 0% kernel / faults: 3 minor
      0% 2386/jbd2/mmcblk0p23: 0% user + 0% kernel
      0% 12285/me.twrp.twrpapp: 0% user + 0% kernel / faults: 413 minor 48 major
      0% 617/ion_noncontig_h: 0% user + 0% kernel
      0% 31336/com.android.webview:sandboxed_process0:org.chromium.content.app.SandboxedPr: 0% user + 0% kernel / faults: 8 minor 1 major
      0% 31744/irq/99-11060000: 0% user + 0% kernel
      0% 1/init: 0% user + 0% kernel / faults: 62 minor 1 major
      0% 1641/ueventd: 0% user + 0% kernel / faults: 46 minor
      0% 2390/android.system.suspend@1.0-service: 0% user + 0% kernel / faults: 56 minor
      0% 2424/android.hardware.health@2.0-service: 0% user + 0% kernel / faults: 8 minor
      0% 6457/installer: 0% user + 0% kernel / faults: 118 minor
      0% 14880/kworker/1:2: 0% user + 0% kernel
      0% 15838/kworker/2:1: 0% user + 0% kernel
      0% 2314/hwservicemanager: 0% user + 0% kernel / faults: 69 minor 3 major
      0% 2414/netd: 0% user + 0% kernel / faults: 127 minor 3 major
      0% 2439/ashmemd: 0% user + 0% kernel / faults: 3 minor 1 major
      0% 2486/keystore: 0% user + 0% kernel / fault
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018394)
sebasjm   
2021-09-17 14:52   
debugging the app seems that the WalletBackendService.onCreate is not even called
(0018400)
grote   
2021-09-21 09:12   
This is most likely an issue introduced by https://git.taler.net/taler-android.git/commit/?id=06f16a7477b337f07526285b65a7f3003b814d33

can you confirm that it works before that commit?

I tried to debug this, but the issue seems to lie with changes in wallet-core, I know little about.
(0018401)
sebasjm   
2021-09-21 15:49   
Yes! it works in that commit. Oh, the issue was around the corner :)

Thanks!
(0018402)
sebasjm   
2021-09-21 17:08   
I see that wallet core change the global names from __akono_* to __native_* so there should be used a new version of the JNI interface Akono.
We need to publish a new version of net.taler:akono first with this change https://git.taler.net/akono.git/commit/?id=52d468141e3478523c1373f3bc81fd3a4fbfea72
(0018407)
sebasjm   
2021-09-22 18:23   
I changed the priority since the android app wont work until this is fixed.

Currently I'm following the steps to build up the android-node-v8 repository but it's taking time (between errors and compile time)

I hope to have some a confirmation that this is the correct fix soon.
(0018408)
sebasjm   
2021-09-22 22:05   
I was able to build the akono lib using android ndk 19.2.5345600

But I blocked at this error, probably I have missed a step in the build process? I don't know

2021-09-22 16:34:15.638 32497-32497/net.taler.wallet.nightly V/AkonoJni: putting module code (kotlin)
2021-09-22 16:34:15.639 32497-32497/net.taler.wallet.nightly D/akono-jni.cpp: in putModuleCodeNative
2021-09-22 16:34:15.654 32497-32497/net.taler.wallet.nightly D/akono-jni.cpp: registered module
2021-09-22 16:34:18.377 32497-32529/net.taler.wallet.nightly D/akono-jni.cpp: akono.js:24
      sendMessage: akono.sendMessage,
                         ^
    
    TypeError: Cannot read property 'sendMessage' of undefined
        at akono.js:24:22
        at NativeModule.compile (internal/bootstrap/loaders.js:300:5)
        at NativeModule.compileForPublicLoader (internal/bootstrap/loaders.js:217:8)
        at Function.Module._load (internal/modules/cjs/loader.js:538:16)
        at Module.require (internal/modules/cjs/loader.js:683:19)
        at require (internal/modules/cjs/helpers.js:16:16)
        at eval (eval at global.__native_run ([eval]:1:78), <anonymous>:1:1)
        at eval (<anonymous>)
        at global.__native_run ([eval]:1:78)
2021-09-22 16:34:18.494 2651-4693/system_process I/ActivityManager: Process net.taler.wallet.nightly:WalletBackendService (pid 32497) has died: fore BTOP
(0018409)
sebasjm   
2021-09-23 17:23   
finally made it working, the problem was that the I was using the code of androidbuild since was better documented but the code from master, with some changes from the androidbuild branch, is the working one.
I have a working akono.aar lib but I'm not able to publish it, @grote can you?

I'm going to push one more change into the taler-android repo since the wallet need to be initialized before calling it.
(0018410)
sebasjm   
2021-09-23 19:14   
i have an android wallet working!
wallet core release 0.8.1 has a bug, a new release should be made with the latest version: this if is bogus

https://git.taler.net/wallet-core.git/tree/v0.8.1/taler-wallet-embedded.js?h=prebuilt#n20972


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7021 [GNUnet] NSE service tweak sometimes 2021-09-20 12:03 2021-09-22 11:40
Reporter: md Platform: GNU/Linux  
Assigned To: Christian Grothoff OS: Guix System  
Priority: low OS Version: v???  
Status: resolved Product Version: 0.13.0  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: NSE service sometimes returns stddev=NaN
Description: The NSE service sometimes sends estimates wih stddev=NaN. This might or might not be a bug. However, this contradicts the statements in setup_estimate_message, that imply the stddev is a finite positive number (or zero) or positive infinity.

  if (variance >= 0)
    std_dev = sqrt (variance);
  else
    std_dev = variance; /* must be infinity due to estimate_count == 0 */

As infinity >= 0, this doesn't seem correct. Maybe the comment should be changed to /* must be NaN due to estimate_count == 0 */?
Tags:
Steps To Reproduce: This was detected on an offline peer. Possibly you need to delete ~/.local/share/gnunet/nse/proof.dat (not sure). Not 100% reproducible: I only observed this after the Scheme-GNUnet release. To observe this, run gnunet-nse, or run the "examples/nse-web.scm" script in Scheme-GNUnet and notice the "Scheme-GNUnet: an ill-formed message of type 323 was received’ messages.
Additional Information:
System Description
    INFO: OS : Linux
    INFO: OS RELEASE : 5.8.15
    INFO: HARDWARE : x86_64
Attached Files:
Notes
(0018399)
md   
2021-09-20 12:06   
Oops it's detected on 0.13.1, not 0.13.0.
(0018403)
Christian Grothoff   
2021-09-22 11:36   
Fix committed to master branch.
(0018404)
Christian Grothoff   
2021-09-22 11:40   
Ah, interesting catch. The logic above did 0.0/0.0 which is indeed NaN, while the comment reasoning was X/0.0 is "always" INF for all non-negative X. Well, that was almost true ;-). I've debated this with myself, and I think NaN is actually better here. So we'll keep the result at NaN. I've updated the comment in Git Master.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6096 [Taler] wallet (WebExtensions) feature have not tried 2020-02-17 15:56 2021-09-18 22:57
Reporter: Florian Dold Platform:  
Assigned To: belen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet should render complete contract terms
Description: Currently the browser wallet only renders a tiny subset of the contract terms.

It should instead support rendering the full contract schema in a user-friendly way. The schema is documented here: https://docs.taler.net/core/api-merchant.html#the-contract-terms
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017955)
Florian Dold   
2021-06-15 19:08   
Assigning to Sebastian, as he's already working on the contract terms rendering for the backoffice UI.
(0018050)
belen   
2021-08-02 16:41   
Documents showing a first design iteration are available at:
https://git.taler.net/large-media.git/tree/issue_6096

There is a set of wireframes and a video. A clickable prototype is also available at
https://www.figma.com/proto/GuGZzjPTqYKhQnapfeG8s4/Taler-web-extension?node-id=25%3A3&scaling=min-zoom&page-id=25%3A2&starting-point-node-id=25%3A3
(0018057)
belen   
2021-08-03 17:28   
After some discussion about iteration 1 of the design, we concluded it would be better to hide the terms of service upon acceptance, so that the withdrawal details remain in view when you click the "confirm withdrawal" button.

Documents showing the second design iteration are available at:

https://git.taler.net/large-media.git/tree/issue_6096/iteration_2

There is a set of wireframes and a video.

The clickable prototype is available at:

https://www.figma.com/proto/GuGZzjPTqYKhQnapfeG8s4/Taler-web-extension?node-id=25%3A3&scaling=min-zoom&page-id=25%3A2&starting-point-node-id=25%3A3
(0018389)
sebasjm   
2021-09-07 14:13   
In order to get the terms of service information the wallet will be making a request here [1]

Documentation of the exchange setup here [2] says that terms it's optional for some server (like when it's not production) so we should consider in the design a message when there is no terms of service or when the terms of service is available in other formats.
The defaults (reading the exchange server code) seems to be xml, which may or may not be parsable by the browser.

[1] https://docs.taler.net/core/api-exchange.html#get--terms
[2] https://docs.taler.net/taler-exchange-manual.html#terms-of-service
(0018390)
sebasjm   
2021-09-08 18:17   
(Last edited: 2021-09-08 18:53)
seems that there is not enough information.
for the record:
found getExchangeWithdrawalInfo but was not externalized, seems the correct way to get this info

@Florian Dold

fix awful spelling :)
(0018392)
sebasjm   
2021-09-13 20:41   
@belen, I've pushed changes that can be reviewed on sotrybook for the design impl and the testing example or with the latest version against test environment
(0018395)
belen   
2021-09-17 17:18   
I've pulled, and the changes I see seem to be about displaying the exchange terms of service. Is this what you needed me to look at?
(0018397)
sebasjm   
2021-09-18 22:57   
Yes, I have implemented the design that share here https://bugs.gnunet.org/view.php?id=6096#c18057
Since this is about the terms of service we can follow any feedback in this issue https://bugs.gnunet.org/view.php?id=5983

I will keep this issue open in order to design and implement the contract terms view


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5983 [Taler] wallet (WebExtensions) feature have not tried 2019-12-03 02:14 2021-09-17 18:38
Reporter: Florian Dold Platform:  
Assigned To: belen OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet must display exchanges' ToS
Description: ... both for the web extension and the android app.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018393)
sebasjm   
2021-09-14 16:34   
this has been worked with the design commented in issue 0006096 https://bugs.gnunet.org/view.php?id=6096

@belen we should we continue the discussion here


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7019 [Taler] documentation text N/A 2021-09-17 09:48 2021-09-17 09:48
Reporter: Christian Grothoff Platform: i7  
Assigned To: ttn OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: man pages missing for sync commands
Description: Specifically, sync-httpd and sync-dbinit. Should be very similar to the other -httpd and -dbinit commands.
Also, it would be good if we had a man page for the various options of sync (man 5 sync.conf). Once those are written, we need to import the 'prebuilt' submodule into sync.git, modify the build system to include the man pages (sync-only) and update the Debian packaging of sync.
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:
7013 [Taler] documentation text have not tried 2021-09-04 20:25 2021-09-11 12:38
Reporter: ttn Platform:  
Assigned To: ttn OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: explain and index all $-substitutable variables (e.g., DATADIR)
Description: The explanation should include origins (e.g., DATADIR comes from Autotools),
common usage, and placement.

https://mail.gnu.org/archive/html/taler/2021-09/msg00001.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018388)
Christian Grothoff   
2021-09-04 22:36   
Well, everything that can be $-substituted must be in $PATHS. Some variables there are in the default-config, others are created at runtime by libgnunetutil based on its heuristics to guess where the various autotools prefixes ended up.
(0018391)
Florian Dold   
2021-09-11 12:38   
This is not just a documentation issue, but the taler-util TS package also needs to support those variables.


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

all of this comes from questions and people who didn't understand parts of the process or simply
have some reason to refuse assignments in general.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5917 [gnunet-www] General minor have not tried 2019-10-02 14:05 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: not fixable  
Projection: none      
ETA: none Fixed in Version: 2021-02  
    Target Version: 2022-01  
Summary: write subpages for projects and structure them (gns, gnurl, fs, etc)
Description: we should have something like /projects/{projectname} where
/projects/ gives a full listing of {projectname}s and
/projects/{projectname}/ contains information related to the project.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017841)
schanzen   
2021-05-12 14:26   
See 0005791


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5835 [gnunet-www] General text always 2019-08-18 14:15 2021-09-08 21:50
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: 2022-01  
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)
nikita   
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)
nikita   
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:
5800 [gnunet-www] General minor have not tried 2019-07-11 15:27 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 2021-01  
    Target Version: 2022-01  
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)
nikita   
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?
(0017753)
Christian Grothoff   
2021-04-16 23:48   
We recently applied some typo-fixing patches. This bug is not very nice as it is kind-of open ended. Closing, as there are no specific typos mentioned that need fixing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5799 [gnunet-www] General feature have not tried 2019-07-10 12:00 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2022-01  
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:
Notes
(0017830)
Christian Grothoff   
2021-05-11 19:00   
To be integrated with Taler buildbot link checker. Assigning to me.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5791 [gnunet-www] General minor have not tried 2019-07-01 13:19 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: not fixable  
Projection: none      
ETA: none Fixed in Version: 2021-02  
    Target Version: 2022-01  
Summary: Create /software page for details on projects
Description: The /software/$name/$sublevels would contain details about the projects we work and worked on.

For the core project this will be an easy place for people to discover what we are currently doing on onion routing, and so forth. This does not nullify the existing 'use', 'install' etc pages but would go more into detail in a self-contained manner. What is $name? What can it do today? Why does it exist? Which caveats does it have today? Who is working on it? What can I use it for? etc pp.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017840)
schanzen   
2021-05-12 14:24   
(Last edited: 2021-05-12 14:25)
While this is true, this is not an issue that can be properly tracked. I have migrated the old reclaimID website which was jekyll-based to this format.
For future reference, it can be used. But this issue does not really have action items. Hence closing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5790 [gnunet-www] General minor have not tried 2019-07-01 13:14 2021-09-08 21:50
Reporter: nikita 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: 2022-01  
Summary: Create /comparison page
Description: Recurring question: How does GNUnet relate to (Name of other p2p technology project here)?

Purpose of /comparison: Provide an easy, graphical answer to questions of this type.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014634)
nikita   
2019-07-01 13:32   
More questions which would be addressed by this: "But is voice not like GNU Jami"?

The /comparison page could be highlevel (all of gnunet compared to all of (other name)) and link to individual pages once we have them (see the /software ticket)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5789 [gnunet-www] General minor have not tried 2019-07-01 12:51 2021-09-08 21:50
Reporter: nikita 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: 2022-01  
Summary: website simple introduction (and more)
Description: Common recurring question:

    
    
> CDSlice 12 hours ago [-]
>
> What exactly is GNUnet? It says it is supposed to replace the old internet stack, but that it also runs on top of it? It looks like it is some kind of research project, so do I just not have enough background information to understand what they are saying?
>
> Can anyone ELI5 what GNUnet is and why I should care about it?

>> amatus 11 hours ago [-]
>>
>>Here's a few things GNUnet replaces and why it's better:
>>Bittorrent is replaced by GNUnet "filesharing", it's trackerless, it provides a search function, users can adjust their level of anonymity for publishing, downloading, and searching.
>>DNS is replaced by "GNS", it covers the "decentralized" and "secure" points in Zooko's triangle, it a pet name system.
>>VPN is replaced by GNUnet VPN, which is just VPN over GNUnet so it can take advantage of the p2p network.
>>TCP/UDP/SPDY/QUIC is replaced by "cadet", takes advantage of the p2p network.
>>There's also a DHT.
>>And there's lots of other stuff that's in-progress.

>>>>ng0 10 hours ago [-]
>>>>
>>>>We should maybe include a "GNUnet in 5 minutes or less" on the website. The old LEGO analogy is nice, and lynX did a great comparison here: https://secushare.org/img/stack-comparison.png We don't really need the ISO OSI model here, but even this can be added, as we've already used it throughout the years to compare to the GNUnet stack.



Tasks resulting from this:

1. Write a "GNUnet explained in 5 minutes or less", which might as well be a small presentation to link to, heck even a video.

2. Include visuals for comparison (a variation of lynX stack-comparison + a comparison to ISO OSI which we used over the years)

3. reuse our LEGO model (used in some parts of the documentation) in parts of the website.

Yet to be determined where, up for discussion 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:
5778 [gnunet-www] General tweak have not tried 2019-06-26 18:16 2021-09-08 21:50
Reporter: rockxo Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: 0.11.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2022-01  
Summary: Double hyphen should be non-breaking
Description: docs.gnunet.org
(depending on the browser’s window size)
things like in section 7.8:
[…] path containing GNUnet with --with-gnunet=/path/to/gnunet and the […]
create this:
[…] path containing GNUnet with -
-with-gnunet=/path/to/gnunet and the […]
Tags: documentation, website
Steps To Reproduce:
Additional Information: Possible solution:
any “--” in a <code> section could be e.g.:
[…] with ‑-with-gnunet=/path/to/gnunet […]

or in a LaTeX source (did not test!):
[…] with "~-with-gnunet=/path/to/gnunet […]
OR
[…] with \hbox{-}-with-gnunet=/path/to/gnunet […]
Attached Files:
Notes
(0014599)
rockxo   
2019-06-26 18:26   
corrected possible solution (hopefully bypassing the HTML interpreter):
[…] with «ampersand»«hashsign»8209«semicolon»-with-gnunet=/path/to/gnunet […]
or
[…] with «ampersand»«hashsign»8209«semicolon»-with-gnunet=/path/to/gnunet […]

(this comment was created because Mantis interprets the solution as HTML code)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5637 [gnunet-www] General minor have not tried 2019-03-11 20:18 2021-09-08 21:50
Reporter: nikita 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: 2022-01  
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)
nikita   
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)
nikita   
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:
5533 [gnunet-www] General text have not tried 2019-01-30 19:20 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2022-01  
Summary: new website: create detail pages for software parts
Description: In our earlier discussions (not on record) we were talking about project related subpages: what is gnurl? detail page. what is $subsystem? detail page. what is Taler? etc.
As of now, only /gnurl exists.
The rest has to be written so that people do not have to watch the full 45+ subsystems talk, read the documentation, etc.

One possible application for this is that we should not point out caveats on the front page, but could include them in the subpage (for example: we are still researching and working on onion routing done right for gnunet).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013930)
catonano   
2019-02-22 07:09   
is this meant for 0.11 ?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5526 [gnunet-www] General feature have not tried 2019-01-27 16:24 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2022-01  
Summary: new website: pass accessibility tests
Description: We should make sure that the website passes the most basic criteria for some accessibility features or that we pass some tests which are out there.
Tags: website
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013804)
nikita   
2019-02-16 00:28   
complex task, can not be finished with our resources for 0.11.1
(0014238)
nikita   
2019-03-23 11:35   
I'm taking this off the roadmap.
While it's still necessary, the subject is far too broad to have a fixed point release and be done with
it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5525 [gnunet-www] General minor have not tried 2019-01-27 16:21 2021-09-08 21:50
Reporter: nikita Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2022-01  
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)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
2019-02-06 14:41   
Yes, if those are the implications.
(0013612)
nikita   
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)
nikita   
2019-02-06 14:47   
Try one of our pages with for example https://achecker.ca
(0013615)
nikita   
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)
nikita   
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)
nikita   
2019-02-06 19:06   
I understand enough of what triggers reader mode now, assigning to myself.
(0013975)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
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)
nikita   
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:
6974 [Taler] wallet (WebExtensions) feature N/A 2021-08-03 18:35 2021-09-06 20:07
Reporter: belen Platform:  
Assigned To: belen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: Display fee structure as part of a exchange's terms of service
Description: Currently, the exchanges' terms of service do not include information about the exchange fee structure. Fees are bound to be important to users, and users should be able to review them before accepting the terms of service. Both the web extension and the Android wallet should provide information about the free structure as part of the presentation of an exchange's terms of service.

Several approaches have been discussed, between them displaying a fees table on demand, or providing some kind of classification for exchanges based on their fee structure.

Relevant design documents include:

https://docs.taler.net/design-documents/008-fees.html
https://docs.taler.net/design-documents/012-fee-schedule-metrics.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018058)
belen   
2021-08-03 18:36   
We also discussed only showing fees that are higher than 0, and only those that apply to the denomination the user is withdrawing.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7012 [GNUnet] testing library trivial always 2021-09-03 01:56 2021-09-03 07:56
Reporter: user1111 Platform:  
Assigned To: t3sserakt OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: make check fails due to a compile error
Description: test_testing_api_cmd_netjail.c: In function ‘run’:
test_testing_api_cmd_netjail.c:44:5: error: too few arguments to function ‘GNUNET_TESTING_cmd_netjail_start_testing_system’
   44 | GNUNET_TESTING_cmd_netjail_start_testing_system ("netjail-start-testbed-1",
        | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6912 [Taler] mechant backend major always 2021-06-29 20:54 2021-09-02 23:32
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: reported transfer in instance $X from a order created in instance $Y
Description: this was tested in demo:
1.- create and pay an order from instance named sebasjm
2.- wait for the bank the exchange to send the wire transfer
3.- go to backoffice and notifiy the transfer but from another instance (my case was from default instance)
4.- transfer gets verified, get listed into transfers list from the default instance
5.- checked that is not listed in the transfer list of the sebasjm instance

note1: account payto differ, since this was from another instance with another payto uri. from this I assume that it will be a good addition to check the payto URI
note2: the order still get the information from the wire transfer, even if it was notified by another instance. which should not happen

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018148)
Christian Grothoff   
2021-08-31 13:19   
I've now written test_merchant_transfer_tracking.sh with the explicit goal to reproduce the issue -- and failed. :-(.
Sebastian: Please review the test and tell me what I did not understand correctly, and modify it to reproduce the issue.
(0018157)
Christian Grothoff   
2021-08-31 23:02   
Sorry, added the file now. Had forgotten to 'git add'.
(0018386)
sebasjm   
2021-09-02 18:40   
pushed a change into the test
(0018387)
sebasjm   
2021-09-02 22:36   
fixed and tests updated


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7007 [Taler] exchange crash always 2021-08-31 21:41 2021-09-02 18:14
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: exchange crash running initialize_taler_system.sh script in the merchant test suite
Description: I'm trying to build a setup to run integration tests and found this issue.

scripts ends at line 180 (aprox) doing the request to the exchange for the keys (/keys) after singing and uploading configuration (with taler-exchange-offline)

Exchange logs:

2021-08-31T16:45:59.747175+0000 taler-exchange-httpd-12908(MEE5M6GZVY98BRRCKPNJ41ZEWM) INFO Creating /keys at cherry pick date Thu Jan 01 00:00:00 1970
2021-08-31T16:45:59.748188+0000 taler-exchange-httpd-12908(MEE5M6GZVY98BRRCKPNJ41ZEWM) ERROR Assertion failed at json_pack.c:42. Aborting.

Exchange Secmod RSA logs:

2021-08-31T19:29:59.018366+0000 taler-exchange-secmod-rsa-1398 INFO Sending RSA denomination key M29MNZV7 (coin_kudos_ct_1)
2021-08-31T19:29:59.018705+0000 taler-exchange-secmod-rsa-1398 WARNING `sendto' failed at taler-exchange-secmod-rsa.c:548 with error: No such file or directory
2021-08-31T19:29:59.018763+0000 taler-exchange-secmod-rsa-1398 INFO Client /tmp/taler-system-runtime//exchange-secmod-rsa/clients/cliIY8Zju must have disconnected


Core dump info:

#5 0xb6dec938 in GNUNET_JSON_pack_ (spec=0xbe81f5e4) at json_pack.c:42
#6 0x0045d488 in create_krd (ksh=0x1b335c8, denom_keys_hash=0xbe81f6ec, last_cpd=..., signkeys=0x1b50a18, recoup=0x1b545a8, denoms=0x1b54600)
    at taler-exchange-httpd_keys.c:1442
#7 0x0045e004 in finish_keys_response (ksh=0x1b335c8) at taler-exchange-httpd_keys.c:1641
#8 0x0045e632 in build_key_state (hs=0x1b509e0, management_only=false) at taler-exchange-httpd_keys.c:1757
#9 0x0045e950 in get_key_state (management_only=false) at taler-exchange-httpd_keys.c:1817
#10 0x0045e9b8 in TEH_keys_get_state () at taler-exchange-httpd_keys.c:1835
#11 0x0045eefe in TEH_keys_get_handler (rc=0x1b6bf98, args=0xbe81f860) at taler-exchange-httpd_keys.c:2081

> uname -a
Linux ubuntu 5.11.0-1016-raspi #17-Ubuntu SMP PREEMPT Thu Jul 29 15:35:34 UTC 2021 armv7l armv7l armv7l GNU/Linux

exchange revision 4b9ae0bb93743cace6a835df1a7a8918a3d1ed63


Not sure if this is related, but trying to run make check fails at test_helper_rsa

2021-08-31T19:33:22.080882+0000 test-helper-rsa-1979 INFO Requesting signature over 256 bytes with key 5075T4QM
2021-08-31T19:33:22.081209+0000 taler-exchange-secmod-rsa-1993 INFO Received request to sign over 256 bytes with key 5075T4QM
2021-08-31T19:33:22.129064+0000 taler-exchange-secmod-rsa-1993 INFO Sending RSA signature
2021-08-31T19:33:22.140915+0000 test-helper-rsa-1979 INFO Received valid signature for key 5075T4QM
2021-08-31T19:33:22.144170+0000 test-helper-rsa-1979 INFO Requesting signature over 256 bytes with key PX3DER9G
2021-08-31T19:33:22.144308+0000 taler-exchange-secmod-rsa-1993 INFO Signing request failed, denomination key PX3DER9G is not yet valid
2021-08-31T19:33:22.144413+0000 test-helper-rsa-1979 WARNING External protocol violation detected at crypto_helper_denom.c:644.
2021-08-31T19:33:22.144567+0000 test-helper-rsa-1979 ERROR Unexpected error 1701
FAIL test_helper_rsa (exit status: 7)

Tags:
Steps To Reproduce:
Additional Information:
    INFO: OS : Linux
    INFO: OS RELEASE : 5.11.0-1016-raspi
    INFO: HARDWARE : armv7l
    INFO: awk : Found
    INFO: gcc : gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
    INFO: cc : cc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
    INFO: c++ : c++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0
    INFO: clang :
    INFO: clang++ :
    WARNING: make : Not Found (unexpected result)
    INFO: gmake : 4.3
    INFO: autoconf : 2.69
    INFO: automake : 1.16.3
    INFO: libtool : 2.4.6
    INFO: GNUnet : 0.15.4-alpha.0
    INFO: git commit : a2b5de8e03aea9d8664817ba51720ccf27517f4f
    INFO: libgcrypt : 1.8.7
Attached Files:
Notes
(0018152)
Christian Grothoff   
2021-08-31 21:56   
0013ce41..6c6787b4 adds some assertions to help pin down the issue (I did not yet reproduce it).
(0018153)
Christian Grothoff   
2021-08-31 21:57   
The assertion means that some argument to JSON_PACK is NULL which is not allowed. Not sure which one. Looking at the code it does not seem obvious that we have a non-NULL argument present.
(0018154)
sebasjm   
2021-08-31 22:35   
tested and those asserts are passing
(0018155)
Christian Grothoff   
2021-08-31 23:00   
And it is still crashing!? Can you use gdb to inspect the core dump and see what field exactly is failing in the spec?
(0018156)
Christian Grothoff   
2021-08-31 23:01   
Oh, and here it seems to work just fine. At least I just ran the shells script and got no crash.
(0018158)
sebasjm   
2021-09-01 15:26   
ACK, this is what i've got

(gdb) printf "%s\n", spec[i].field_name
list_issue_date
(gdb) x spec[i].object
0x0: Cannot access memory at address 0x0

#5 0xb6e76938 in GNUNET_JSON_pack_ (spec=0xbeffe594) at json_pack.c:42
#6 0x0040d6f4 in create_krd (ksh=0x45c5c8, denom_keys_hash=0xbeffe69c, last_cpd=..., signkeys=0x479790, recoup=0x47d398, denoms=0x47d3f0)
    at taler-exchange-httpd_keys.c:1447
(0018159)
Christian Grothoff   
2021-09-01 16:14   
bf2ce985..13deb5c4 fixes the crash. However, this happened when there are NO denomination keys. Which is odd, and so with this change you will NOT get a /keys reply from the exchange. But it won't crash anymore.
(0018216)
Christian Grothoff   
2021-09-02 18:14   
Fix committed to master branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6986 [Taler] exchange minor have not tried 2021-08-07 19:15 2021-09-02 18:14
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: exchange accepts sepa deposits with empty IBAN
Description: The following command results in the exchange accepting deposits with "" as the IBAN. LibEuFin doesn't like that ...

$ taler-wallet-cli deposit create EUR:5 payto://sepa/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018085)
Christian Grothoff   
2021-08-07 19:35   
Should be fixed in 1eba4f5e..c7aac576. Please confirm? ;-)
(0018220)
Christian Grothoff   
2021-09-02 18:14   
Fix committed to master branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6956 [Taler] exchange Postgres DB backend feature N/A 2021-07-23 19:23 2021-09-02 18:14
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: trigger long pollers via Postgres DB API to properly support multiple frontends
Description: We should use

https://www.postgresql.org/docs/current/libpq-notify.html

and

https://www.postgresql.org/docs/9.4/sql-notify.html

to trigger long pollers. This will also finally enable long-polling for the reserve status changes caused out-of-process by taler-exchange-wirewatch. This bug ALSO then applies to the merchant backend (and even Anastasis!).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018015)
Christian Grothoff   
2021-07-24 22:09   
A first draft API (incomplete implementation: scheduler missing) and without tests has landed in libgnunetpq!
(0018016)
Christian Grothoff   
2021-07-24 22:18   
Note: documentation stresses: first install listener, THEN once transactionally query database state you care about, and only AFTER that you will get good notifications.
(0018018)
Christian Grothoff   
2021-07-25 19:55   
API completed in GNUnet and tested. Needs to be integrated with exchange and merchant.
(0018123)
Christian Grothoff   
2021-08-23 23:39   
exchange long pollers for reserves, keys and wire are in place as of efbe0441..888895cb. That should be all in the exchange.
(0018133)
Christian Grothoff   
2021-08-25 17:27   
Implementation complete as of 5672080..696278c
(0018217)
Christian Grothoff   
2021-09-02 18:14   
Fix committed to master branch.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7011 [Anastasis] General feature N/A 2021-09-02 17:35 2021-09-02 17:35
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.3.0  
Summary: add support for more countries
Description: ... and review which questions we ask for the current ones before we go 'live'. Possibly restrict country set to those that have been reviewed.
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:
7008 [libmicrohttpd] other major always 2021-09-02 14:01 2021-09-02 17:29
Reporter: necto Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.73  
    Target Version: 0.9.73  
Summary: https://git.gnunet.org/libmicrohttpd.git is down
Description: The git repository specified on the project page in this section: http://www.gnu.org/software/libmicrohttpd/#contribute is not accessible from Switzerland.
Tags:
Steps To Reproduce: git clone https://git.gnunet.org/libmicrohttpd.git

Cloning into 'libmicrohttpd'...
fatal: repository 'https://git.gnunet.org/libmicrohttpd.git/' not found
Additional Information:
Attached Files:
Notes
(0018162)
Christian Grothoff   
2021-09-02 17:29   
We were moving servers today. It should be back now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6932 [Taler] mechant backend tweak have not tried 2021-07-22 13:09 2021-09-02 14:12
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: merchant needs integration test for POST /private/orders with UUIDs
Description: We never test this code anywhere ...

Test should be either in the merchant or in the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018160)
Christian Grothoff   
2021-09-02 14:12   
Fixed in 98d9dfb..4b8dc55.
Note that this changed the implementation a bit, as it differed from the API specification. So right now, we are finally spec-compilant and the UUIDs are just arbitrary strings in the protocol --- and the lock_uuids[] is just an array of strings.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4810 [Taler] wallet (WebExtensions) feature have not tried 2016-11-20 20:06 2021-08-31 21:24
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: the wallet should support backup and sync
Description: Chrome (and other browsers) offer sync of settings and small values, but we also need to store larger amounts of data, and we need to keep privacy considerations a priority.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012051)
Christian Grothoff   
2017-04-19 20:26   
https://www.kinto-storage.org/ seems relevant.
(0013337)
Christian Grothoff   
2018-11-14 11:36   
On design choices (background):
https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
(0018145)
sebasjm   
2021-08-31 06:02   
the wallet currently support backup with the sync service, should we test this kinto integration?
(0018147)
Christian Grothoff   
2021-08-31 11:28   
I don't understand what you're saying. First of all, *which* wallet are you talking about? (Core, Android, WebExtension?). Second, "test into integration" doesn't make sense (in English).
(0018150)
sebasjm   
2021-08-31 16:16   
The wallet core has the feature to configure a sync service, maybe that feature was not there in 2017 (when the ticket was written).

> Second, "test into integration" doesn't make sense (in English).

Kinto is the name of the software you mentioned some years ago, I should have say "should we test an integration with the kinto server?" to be more precise.
Or just having the integration with the current taler sync service is enough?
(0018151)
Christian Grothoff   
2021-08-31 21:24   
Kinto was just mentioned as something to take as inspiration when we designed sync. No actual integration with Kinto was ever envisioned, it's more that we (in the past) could take it for inspiration from the protocol-perspective, and today could still take inspiration from it in terms of UX design.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6243 [libeufin] sandbox minor have not tried 2020-05-20 19:05 2021-08-31 14:49
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: 0.1  
Summary: filter on date range is missing
Description: The sandbox is ignoring the date range from C53 requests. To be fixed.
Tags:
Steps To Reproduce:
Additional Information: The responsible function is called "constructCamtResponse()"
Attached Files:
Notes
(0018149)
ms-mantis   
2021-08-31 14:49   
That is implemented here: 3967193487e42335b43b80ee7407fa44ad39cf70.

Extensive testing is now needed, especially via Nexus' querying.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7004 [Taler] mechant backend major sometimes 2021-08-27 17:55 2021-08-30 16:46
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.8.5  
    Target Version: 0.8.5  
Summary: problems suspending god
Description: Im currently running 20 days old version, commit id c9d29b909d092dc9d5c230f496905fa3a07f64f0

I will report back if I manage to reproduce it on latest master version.

#2 0x00007f4723b8d59b in GNUNET_abort_ () at common_logging.c:281
#3 0x00005608a8deb173 in suspend_god (god=0x5608a9301dc0) at taler-merchant-httpd_get-orders-ID.c:195
#4 0x00005608a8debf56 in send_pay_request (god=0x5608a9301dc0, already_paid_order_id=0x0) at taler-merchant-httpd_get-orders-ID.c:498
#5 0x00005608a8dedeaa in TMH_get_orders_ID (rh=0x5608a8e3f7d0 <public_handlers+720>, connection=0x5608a930a090, hc=0x5608a930d340)
    at taler-merchant-httpd_get-orders-ID.c:1039
#6 0x00005608a8de4066 in url_handler (cls=0x0, connection=0x5608a930a090, url=0x5608a932b3f4 "/orders/2021.239-00RAPSN8JXAK6", method=0x5608a932b3f0 "GET",
    version=0x5608a932b445 "HTTP/1.1", upload_data=0x0, upload_data_size=0x7ffe84dd09a8, con_cls=0x5608a930a0e8) at taler-merchant-httpd.c:1651
#7 0x00007f4723c39c5f in call_connection_handler (connection=connection@entry=0x5608a930a090) at connection.c:2166
#8 0x00007f4723c3b551 in MHD_connection_handle_idle (connection=connection@entry=0x5608a930a090) at connection.c:3459
Tags:
Steps To Reproduce: trying to render order status from merchant backend
Additional Information:
Attached Files:
Notes
(0018136)
Christian Grothoff   
2021-08-27 23:11   
The line number suggest a substantially out-of-date merchant.git, and I *think* I may have solved this one already. Please really try with Git master for a bit, and if you do not succeed, I think this can be closed.
(0018143)
sebasjm   
2021-08-30 16:10   
could not reproduce on master, seems fixed


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

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

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018138)
Christian Grothoff   
2021-08-27 23:15   
I think this is fixed, at least I'm happy with what I got ;-). Marcello: unless the facade is completely fake and only works with sandbox, you should probably 'resolve' this one :-)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6917 [Anastasis] C client library feature N/A 2021-07-11 12:23 2021-08-26 18:30
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: confirmed Product Version: 0.0.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cost calculations for annual fees by reducer are imperfect
Description: Right now, the code does not consider the possibility that the user may have already paid the 'annual_fee' at all or some providers for some of the time. Thus, the cost returned is strictly speaking an upper bound.

That said, this is only relevant for users that store multiple secrets and if annual fees are applicable. As we do not yet really support 'premium' accounts (with liabilities) in the reducer/UI, this is a very minor issue.
Tags:
Steps To Reproduce:
Additional Information: Fixing this will not only require us to change a synchronous transition to an asynchronous state transition, but we MAY also need to modify the REST API to obtain the current account expiration date from the service. Not sure, as we MAY also be able to find out the information using the existing API (need to check if the account expiration time is already returned). Cleanest way would likely be a HEAD request on the policy URL and then getting the info from the HTTP headers.
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6971 [libeufin] nexus minor have not tried 2021-08-03 13:39 2021-08-25 15:19
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: nexus returns HTTP status code 500 instead of 400 when JSON body is malformed
Description: We should fix this *and* have an integration test in the wallet for this.

Christian encountered this when trying to create a facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018132)
ms-mantis   
2021-08-25 15:19   
That was fixed. See "test-libeufin-api-facade-bad-request.ts" in the wallet tests collection!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6995 [Taler] mechant backend minor have not tried 2021-08-18 16:11 2021-08-25 14:31
Reporter: Florian Dold Platform:  
Assigned To: belen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: fix style, text and structural issues with merchant backend HTML pages
Description: While the usage of the old Taler logo has been removed, the new logo is still not used in the merchant backend HTML pages.

It's currently very difficult to make changes to these pages, as there is no way to define shared material between pages. We should put the common JS and CSS (and maybe some HTML like the footer) into separate files that are included from every top-level page.

Furthermore, we need to review the text that appears on the pages for user-friendliness.

Examples:
* Is a payment "requested" or "required"
* There is no explanation about re-purchase detection. For an order with a fulfillment URL, it might be good to mention that you can scan the QR code and then *don't* have to pay again if it's already paid
* The language is not simple and friendly, but academic. "Alternatively", "Finally", sounds like we're about to write a paper.
* On the page for the order status after payment, we don't provide a link to the fulfillment URL. (Kinda related to 0006459)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: offer_refund.png (50,233 bytes) 2021-08-24 17:44
https://bugs.gnunet.org/file_download.php?file_id=1101&type=bug
offer_tip.png (49,535 bytes) 2021-08-24 17:44
https://bugs.gnunet.org/file_download.php?file_id=1102&type=bug
request_payment.png (49,658 bytes) 2021-08-24 17:44
https://bugs.gnunet.org/file_download.php?file_id=1103&type=bug
Notes
(0018117)
Christian Grothoff   
2021-08-20 21:30   
Belen, could you please have a look at the various files in merchant.git/contrib/*.mcpp and see if you can improve the language?
(0018120)
belen   
2021-08-23 15:25   
I can certainly try. It would be good to see the text in context, though. Is there an (easy-ish) way to view the html pages?
(0018121)
Christian Grothoff   
2021-08-23 16:22   
Well, largely demo.taler.net feeds from them. To see the one with the refund, you'll need to scroll to the bottom of the article (after purchase) and click on refund.

Also, they may not show if you have a WebExtension wallet installed with the 'nice' permissions, as then the wallet takes over immediately. So using the Android app + a browser without WebExtension would work best.
(0018125)
belen   
2021-08-24 17:44   
What about something like the attached?

The "Or open your Taler wallet" button replaces "Click this link to open your system's Taler wallet if it exists."

The "Don't have a Taler wallet yet? Install it!" link goes to https://taler.net/en/wallet.html

The copy in depleted_tip.en.mcpp would need to change to:

"Tip already collected"
"You have already collected this tip"

I cannot access the order details page at the moment: the Android wallet gives an error when I try to withdraw or pay. So I am not sure if this page also needs some changes.
(0018126)
Christian Grothoff   
2021-08-24 18:27   
ecf18ea..8bbe228 adjusts the templates based on Belen's suggestions above.
(0018127)
Christian Grothoff   
2021-08-24 18:29   
(Last edited: 2021-08-24 18:29)
Still TODO:
- introduce new Taler logo => Sebastian?
- order detail page => blocked on Demo working for Belen
- not sure the CSS/Design is good yet => Sebastian?
- There is no explanation about re-purchase detection. For an order with a fulfillment URL, it might be good to mention that you can scan the QR code and then *don't* have to pay again if it's already paid.
(0018128)
belen   
2021-08-25 13:00   
I can suggest a way to display the new logo, but I would need to know what is the version of the logo I should use. Is it the one in https://taler.net/?

Also, how can I see the screens involved in the re-purchase detection?

Thanks!
(0018129)
Christian Grothoff   
2021-08-25 13:04   
Yes, the taler.net logo (three blue rings with or without 'taler' text).

Re-purchase detection doesn't involve any additional screens. It is what happens if you
1) buy article with one wallet (say mobile phone in a firefox browser)
2) select same digital product again in another browser
3) *attempt* to pay with the same wallet that already purchased the article, and
4) Taler allows you to get the digital product from the different browser without paying *again*.
(0018131)
sebasjm   
2021-08-25 14:31   
I will move this 5 pages into merchant-backend and then imported like we do with spa.html

This files

./contrib/depleted_tip.en.mcpp
./contrib/show_order_details.en.mcpp
./contrib/request_payment.en.mcpp
./contrib/offer_refund.en.mcpp
./contrib/offer_tip.en.mcpp

will be renamed the from .en.mcpp to .html

i18n could be handled with javascript like we do in backoffice. Let me know if a file for each lang is preferred in this situation.


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

Now that the requirements are more clear, we should properly re-design this based on the desired user experience, and then implement an API for it in wallet-core.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018130)
belen   
2021-08-25 13:05   
Where can I find those requirements? Are they documented somewhere? And if not, who should I talk to about them?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6784 [Taler] bank (demonstrator) major always 2021-03-04 07:25 2021-08-24 20:53
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: error parsing while doing a wire transfer
Description: Wire transfer cannot be done.

I think is for this change
https://git.taler.net/bank.git/commit/?id=354f6f6608eb14e8fd27669f08d8eabacd35098f

PaytoParse is being use here:
https://git.taler.net/bank.git/tree/talerbank/app/views.py#n354

And parameters being taken from here:
https://git.taler.net/bank.git/tree/talerbank/app/templates/payto_wiretransfer.html#n41

I have pushed a fix but it will be nice to have a review (8663a5a)
Tags:
Steps To Reproduce: go to bank
create an account
wire transfer to exchange
produce error PaytoParse doesnt have a account field
Additional Information:

diff --git a/talerbank/app/templates/payto_wiretransfer.html b/talerbank/app/templates/payto_wiretransfer.html
index 91737e2..cdb3c0e 100644
--- a/talerbank/app/templates/payto_wiretransfer.html
+++ b/talerbank/app/templates/payto_wiretransfer.html
@@ -31,7 +31,7 @@
       

{{ _("Transfer money via the payto system:") }}
       

       

- <tt style="font-size: 15px">payto://x-taler-bank/[bank-hostname]/[account-number]?subject=[subject]&amount=[{{ currency }}:X.Y]</tt>
+ <tt style="font-size: 15px">payto://x-taler-bank/[bank-hostname]/[account-number]?message=[subject]&amount=[{{ currency }}:X.Y]</tt>
       


         <form action="{{ url('payto-transfer') }}"
               method="POST"
@@ -39,7 +39,7 @@
         <input type="hidden" name="csrfmiddlewaretoken" value="{{ csrf_token }}" />
         <input name="address"
                placeholder={{ _("payto address") }}
- pattern="payto://x-taler-bank/[a-z\.]+(:[0-9]+)?/[0-9]+\?subject=[a-zA-Z0-9]+&amount={{ currency }}:[0-9]+(\.[0-9]+)?" />
+ pattern="payto://x-taler-bank/[a-z\.]+(:[0-9]+)?/[0-9]+\?message=[a-zA-Z0-9]+&amount={{ currency }}:[0-9]+(\.[0-9]+)?" />
         <input class="pure-button pure-button-primary"
                type="submit"
                value={{ _("Confirm") }} />
diff --git a/talerbank/app/views.py b/talerbank/app/views.py
index 90c34b6..318016e 100644
--- a/talerbank/app/views.py
+++ b/talerbank/app/views.py
@@ -352,8 +352,8 @@ def payto_transfer(request):
     wire_transfer(
         parsed_address.amount,
         BankAccount.objects.get(user=request.user),
- BankAccount.objects.get(account_no=parsed_address.account),
- parsed_address.subject,
+ BankAccount.objects.get(account_no=parsed_address.target),
+ parsed_address.message,
     )
     set_session_hint(request, success=True, hint=gettext("Wire transfer successful!"))
     return redirect("profile")
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6757 [Taler] wallet (WebExtensions) minor have not tried 2021-02-18 11:39 2021-08-24 20:53
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: implement auditor/exchange trust checking and management
Description: The wallet currently just accepts any exchange.

Instead, three-letter currencies must always be audited by an auditor.

Other currencies must either have a trusted exchange or auditor.
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:
6678 [Taler] bank (demonstrator) minor have not tried 2021-01-06 18:09 2021-08-24 20:53
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: bank error messages don't have access-control-allow-origin headers
Description: ... this means that the Firefox wallet can't display potential error messages.
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:
6631 [Taler] bank (demonstrator) major N/A 2020-10-29 00:44 2021-08-24 20:53
Reporter: Christian Grothoff Platform: i7  
Assigned To: MS OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: various http status codes returned by the python bank are highly questionable
Description: 653f6ae..3298ef8 marks those with 'WTF'. (Also introduces symbolic names.)

Please check the status codes, and:
- unless there is a good reason, change as indicated, alas also
- ensure they are consistent with what LibEuFin does, if applicable
- ensure that they are consistent with the bank API documentation
- ensure that they are acceptable to the test cases
- ensure that they match the documented HTTP status code in GANA
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0017067)
MS   
2020-10-30 11:12   
Status codes changed here: 354bf3cf733d8d97a82e951d1b9a2f5a161d03cd. Tests are also passing. Other checks reported in the bug description are still work in progress.
(0017070)
MS   
2020-10-30 18:16   
The three discussed status codes are returned, respectively, after the (three) exceptions below:

PrivateAccountException:
  someone tried to ask the public history of a non public account. This happens only
  in a HTML response, and for this reason there is no documentation to check.

SameAccountException:
  this is raised in two, very, rare cases: (1) the customer who is withdrawing coins and
  the exchange have the same (!!) account. (2) The exchange and the merchant being paid
  have the same (!!) account. This case too seems avoidable to document.

DebitLimitException:
  yes, this needs to be documented. According to some research, the only place where
  this can (programmatically) happen is where a exchange pays a merchant (but has no
  sufficient balance for it.)
(0017100)
Christian Grothoff   
2020-11-03 22:53   
MS: are you asking a question about those three cases? I'm a bit confused what (if anything) is needed by you to resolve this.
(0017101)
MS   
2020-11-03 23:00   
I wrote it more to point out that only one case (the last) is eligible to be documented. Because the bug report asks to 'check if they are consistent with the bank API documentation'.
(0017292)
Christian Grothoff   
2021-01-01 16:42   
Has this been fixed? If not, please do so soon!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6625 [Taler] wallet (WebExtensions) minor have not tried 2020-10-16 11:17 2021-08-24 20:53
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: give better errors when web extension backend doesn't respond
Description: Due to various browser issues, it is possible that the web extension background page doesn't respond properly to our messages.

Instead of just being "stuck", all the wallet UI pages should try to display better error messages.

Ideally we'd link to some FAQ with instructions on what to try/do about it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: loading.png (29,275 bytes) 2020-10-16 16:30
https://bugs.gnunet.org/file_download.php?file_id=933&type=bug
db.png (37,917 bytes) 2020-10-16 16:30
https://bugs.gnunet.org/file_download.php?file_id=934&type=bug
Notes
(0017018)
Franz Gratzer   
2020-10-16 16:20   
Florian asked me to provide the inspection output for the Taler Extension. Hopefully the "Console" output is the needed information:

Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. update.js:26
    schedule moz-extension://716c2fe1-f7dd-4588-b0be-852de013edf2/include/update.js:26
Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. extension.js:113
    <anonymous> moz-extension://716c2fe1-f7dd-4588-b0be-852de013edf2/extension.js:113
TypeError: PrecompiledScript.executeInGlobal: Argument 1 is not an object. ExtensionContent.jsm:567:25
Use of nsIFile in content process is deprecated. 3 NetUtil.jsm:253:8
wallet not available while handling header background.js:18666:21
[ ... the same line many times repeated ... ]
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
[ ... the same line repeated ... ]
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
[ ... the same line repeated ... ]
wallet not available while handling header background.js:18666:21
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. popup.html
wallet not available while handling header background.js:18666:21
[ ... the same line repeated ... ]
wallet not available while handling header background.js:18666:21
could not retrieve balances Error: wallet core not available
    OperationFailedError moz-extension://94bd416f-acb4-4859-8a1a-2a39c5cb764c/dist/pageEntryPoint.js:4236
    callBackend moz-extension://94bd416f-acb4-4859-8a1a-2a39c5cb764c/dist/pageEntryPoint.js:10525
pageEntryPoint.js:10953:26
    updateBalance moz-extension://94bd416f-acb4-4859-8a1a-2a39c5cb764c/dist/pageEntryPoint.js:10953
    rejected moz-extension://94bd416f-acb4-4859-8a1a-2a39c5cb764c/dist/pageEntryPoint.js:526
wallet not available while handling header background.js:18666:21
[ ... the same line repeated ... ]
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
[ ... the same line many times repeated ... ]
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
wallet not available while handling header background.js:18666:21
[ ... the same line many times repeated ... ]
wallet not available while handling header background.js:18666:21
Uncaught (in promise) Error: Could not establish connection. Receiving end does not exist.
    updatePopupStats moz-extension://6fb2f216-7b39-4eea-b24d-d9e12ca1a45e/lib/ui-service.js:231
ui-service.js:231:25
(0017019)
Franz Gratzer   
2020-10-16 16:30   
I forgot to add my screenshots.

db.png shows original settings before I switched all values to "true". But that didn't help. (even after re-starting Firefox.)

loading.png shows what I get after I try to withdraw KUDOS into my browser wallet. (This screen stays forever.)
(0017020)
Florian Dold   
2020-10-16 17:05   
Thanks, these are exactly the logs I was looking for. From the logs, it's not really clear what's going wrong, other than "the WebExtension UI is unable to talk to the WebExtension background page".

Just to confirm, is this using the latest version of the wallet from the Mozilla Addon store? (Should show up as "0.8.0.2" under about:addons)

I wasn't able to reproduce this myself with 78.3.0esr. We had a similar problem in the past, where the extension simple wouldn't work on certain profiles.

Would it be possible for you to try the Taler wallet under a fresh Firefox profile? You can either start Firefox as "firefox --new-instance --ProfileManager" or go to about:profiles to run it in a new profile.

Once we know if this is an issue with certain profiles / configurations, we can figure out what's going on from there.
(0017021)
Franz Gratzer   
2020-10-16 17:53   
Yes 0.8.0.2 is the Version number I get if I open the details view in the Add-on Manager.

The Taler extension instantly worked in the new profile where this was the only extension without any personalisation of the browser.

My original profile might be rather unusual. I always use private browsing, delete all data when closing the browser, I use Adblocker Ultimate and have the Gnome Extensions manager installed. Aside from that I have made several adjustments for more privacy (but I didn't need to go into the "about:config" page for that. So it shouldn't be way out of the ordinary.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6537 [Taler] wallet (TS core) tweak have not tried 2020-08-25 15:05 2021-08-24 20:46
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: have integration test for withdrawing "too late"
Description: We should have an integration test for the following scenario:

* wallet starts withdrawal
* reserve is created with the exchange
* we simulate waiting for a long time (via --timetravel)
* the wallet tries to finish the withdrawal, and is now faced with an error
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016765)
Florian Dold   
2020-08-25 19:02   
There are two variations to this:

1. Reserve expired
2. Wallet committed to coin selection, started withdrawal, got interrupted, and when resuming, the denominations withdrawal period is already over.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6965 [Taler] wallet (WebExtensions) minor always 2021-07-29 12:28 2021-08-24 20:41
Reporter: belen Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: Extension popup remains open when an extension tab opens
Description: The extension popup remains open when an extension tab opens, for instance when I click the "open" button when a Taler action is detected, or when I click the "help" link on an empty balance tab.

Tags:
Steps To Reproduce: 1. Install the extension
2. Click the "help" link on the balance tab.

Outcome: the popup stays open, even though all that I need to attend to now is the extension tab.

Expected outcome: the popup should close itself when an extension tab has been opened.
Additional Information: Found on Firefox Version 90.0 for Ubuntu (21.04)
Commit: 37031700d094d2e281529b937f196b65a0f83f2e
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4880 [Taler] wallet (WebExtensions) tweak N/A 2017-02-05 22:09 2021-08-24 20:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: add images to contracts
Description: It should be possible to specify image previews of the items sold and/or of the author/seller in the contract and display them. (Fully embedded and/or URIs but with hash of resource to authenticate it.)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011692)
Florian Dold   
2017-02-06 12:28   
There's a related web standard https://www.w3.org/TR/SRI/, if we use this we don't have to fetch the images and verify them manually in JavaScript. We can just translate it into the corresponding HTML element instead.

I agree that this is a good thing, at least for the merchant logo/banner, I've seen other payment systems do this.
(0011693)
Florian Dold   
2017-02-06 12:29   
Eh, currently the standard only supports the "script" tag, and leaves the "img" tag open for future versions :-(
(0015242)
Florian Dold   
2020-01-07 21:36   
Should this image be associated with the whole order? Or should it be possible to have one image per product in the product list? Maybe both?

Currently *all* of the contract terms used in our various demos have an empty product list and only a summary.
(0015474)
Christian Grothoff   
2020-03-29 22:02   
This is now implemented in the Android wallet. Hence changing category to WebExtension.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6860 [Taler] Merchant frontends (Python3) minor have not tried 2021-05-10 17:17 2021-08-24 20:40
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version: 0.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: avoid redirect loop in blog merchant frontend demo
Description: When the user agent blocks cookies (or for some other reason the cookie that we expect isn't set correctly, such as due to escaping issues), the browser is currently sent in a redirect loop.

This could be avoided via some intermediate URL that just sets the order ID cookie *or* shows a warning to the user that the cookie wasn't set.
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:
6985 [Taler] documentation text always 2021-08-07 12:01 2021-08-24 20:39
Reporter: davidak Platform:  
Assigned To: Stefan OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: FAQ: double spending
Description: someone complained that they did not find information how taler solves double spending

source: https://github.com/liberapay/liberapay.com/issues/1309#issuecomment-894609559

i'm not sure if that is important enough to be added to the FAQ, but it should be documented somewhere. seems to be a relevant questions for people coming from cryptocurrencies
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018084)
Stefan   
2021-08-07 16:38   
Taking a look at '2.6.2. Database Scheme' on https://docs.taler.net/taler-exchange-manual.html double spending seems to be self-understanding and no matter for the FAQs.

In fact, the German translation on the FAQ web site depicts the scenario clearly by stating:
Was ist, wenn mein Computer gehackt wurde?
Im Fall eines Einbruchs in die Geräte können tatsächlich Coins aus Taler-Wallets ausgegeben werden. Wurde ein Coin ausgegeben, ist das Coin entwertet. Wer es zuerst ausgibt, verfügt über den bewegten Geldwert. Es bietet sich daher an, den Bestand regelmäßig zu kontrollieren, um einen eventuellen Verlust zeitnah festzustellen.

I can imagine it a good idea to extend the English original text:
What if my computer is hacked?
In case of a compromise of one of your devices, an attacker can spend coins from your wallet. In case a coin has been spent, this coin cannot be spent a second time. When a payee deposits a coin its value is irrevocably conveyed to the banking account of the payee.
Checking your balance might reveal to you that your device has been compromised.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6984 [Taler] documentation tweak always 2021-08-07 11:46 2021-08-24 20:39
Reporter: davidak Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: search in docamentation broken
Description: someone noticed that the search is broken

https://docs.taler.net/search.html?q=double#

source: https://github.com/liberapay/liberapay.com/issues/1309#issuecomment-894609559
Tags:
Steps To Reproduce:
Additional Information: From Console:

Uncaught Error: Syntax error, unrecognized expression: <!DOCTYPE html>

<html>
  <head>
    <meta charset="utf-8" />
Attached Files:
Notes
(0018083)
Christian Grothoff   
2021-08-07 16:05   
MS: I don't know if you have any affinity to look into this one, if not, maybe pass it along to Sebastian or Florian...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6964 [Taler] wallet (WebExtensions) minor always 2021-07-29 12:18 2021-08-24 20:39
Reporter: belen 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.8.5  
Summary: Extension provides no hint when Taler action detected
Description: If I don't have the "automatically open wallet based on page content" permission enabled, it's very hard for me to know when a Taler action has been detected in a page. I must open the Taler extension to find out. If I don't, I will miss the Taler action.

The extension should provide a visual cue whenever a Taler action is detected and the "automatically open wallet" permission is disabled.
Tags:
Steps To Reproduce: 1. install the web extension, leaving the permission to automatically open the wallet based on page content unselected
2. Go to the demo bank and start a withdrawal

Outcome: nothing changes in the extension to tell me that a Taler action has been detected in the withdrawal page.

Expected outcome: the extension should provide a visual cue to tell me that something requires my attention.
Additional Information: There are a couple of approaches we could take for this:

1. Display some kind of badge in the Taler extension icon. For examples of this approach, see uBlock Origin, Privacy Badger and Cookie Autodelete extensions (see attached file addon_feedback.png).

2. Display an overlay somewhere in the browser, for instance the right-hand side. For an example of this approach, see the Unpaywall extension. It displays a green, open padlock if a free version of an academic paper exists. Clicking the padlock brings you to that free version in a new browser tab (see attached file unpaywall_overlay.png).

Happy to discuss approaches before coming up with a design.

Found on Firefox Version 90.0 for Ubuntu (21.04)
Commit: 37031700d094d2e281529b937f196b65a0f83f2e
Attached Files: addon_feedback.png (7,632 bytes) 2021-07-29 12:18
https://bugs.gnunet.org/file_download.php?file_id=1089&type=bug
unpaywall_overlay.png (204,539 bytes) 2021-07-29 12:18
https://bugs.gnunet.org/file_download.php?file_id=1090&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6963 [Taler] wallet (WebExtensions) minor always 2021-07-29 11:55 2021-08-24 20:39
Reporter: belen 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.8.5  
Summary: Link to open system's Taler wallet during withdrawal provides no feedback if "automatically open wallet" permission is disabled
Description: The withdrawal page in the demo bank provides a very handy link to open my system's wallet if one exists. This link works like a charm if the permission to automatically open the wallet based on page content is activated. However, when that permission is not activated, clicking that link does nothing. That makes you think the demo is not working.

We should provide some kind of feedback to users so that they are prompted to open the Taler extension.

Tags:
Steps To Reproduce: 1. install the web extension, leaving the permission to automatically open the wallet based on page content unselected
2. Go to the demo bank and start a withdrawal
3. In the withdrawal page, click "this link"

Outcome: absolutely nothing happens. No feedback at all is provided to users in response to their action.

Expected outcome: something should prompt users to check the Taler web extension if it is installed.
Additional Information: We should discuss what's technically feasible here. For instance, I am not sure whether the page can detect if a web extension is installed. If yes, we could simply show a message to users asking them to check the extension.

If not, we could display a generic message on clicking that link when no system wallet is detected.

Found on Firefox Version 90.0 for Ubuntu (21.04)
Commit: 37031700d094d2e281529b937f196b65a0f83f2e
Attached Files:
Notes
(0018024)
sebasjm   
2021-07-29 16:14   
I think we can use this to create the same behavior as clicking this link in mobile
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
cons:
 * safari did not implement this behavior
 * we need to add a web+ before our taler scheme: changing taler+http to web+taler+http (which I think this is a valid change for mobile apps that will use this)
(0018049)
belen   
2021-08-02 10:04   
What would users see? A notification like the one shown in the documentation (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/protocolregister.png) with an action for users to run the Taler action?

If that's the case, this seems a good solution. Since the Taler extension doesn't run in Safari, I don't think that browser not supporting the behaviour is a big deal.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6961 [Taler] wallet (WebExtensions) minor always 2021-07-29 09:25 2021-08-24 20:39
Reporter: belen Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: Unable to activate "automatically open wallet" permission if not selected at installation time
Description: If I don't select the "automatically open wallet" permission in the initial add-on screen upon installation, I can not enable the permission later in the Settings tab.




Tags:
Steps To Reproduce: 1. Install the add-on
2. In the initial screen, do not select the "automatically open wallet" permission
3. Open the add-on, navigate to the Settings tab and check the "automatically open wallet" permission checkbox
4. Close the add-on popup
5. Re-open the add-on and navigate to the Settings tab

Outcome: the "automatically open wallet" permission checkbox is unchecked.

Expected outcome: the checkbox should be checked, since I selected it in step 3 above.
Additional Information: Found on Firefox Version 90.0 for Ubuntu (21.04)
Commit: 37031700d094d2e281529b937f196b65a0f83f2e
Attached Files: additional_permissions_popup.png (94,428 bytes) 2021-07-29 14:28
https://bugs.gnunet.org/file_download.php?file_id=1091&type=bug
Notes
(0018022)
sebasjm   
2021-07-29 14:11   
Clicking the checkbox should trigger firefox asking you to allow/deny the wallet request of additional permission.
If I ignore this popup and follow the steps you describe the behavior is consistent.

So I'm thinking that there may be an issue triggering this popup in your environment. Could you confirm that this firefox permission popup works if you click in the initial screen?
(0018023)
belen   
2021-07-29 14:28   
If I select the checkbox on the initial screen, I can see the popup (see attached additional_permissions_popup.png).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6908 [Taler] wallet (TS core) minor have not tried 2021-06-23 10:28 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: don't show "unexpected exception (message: explicitly terminated)"
Description: When a pending refresh can't finish because the wallet is being stopped, this message is sometimes shown. While completely harmless, it looks like some more severe problem has occurred. We should improve the logging in this case.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6867 [Taler] wallet (Android App) major always 2021-05-16 01:25 2021-08-24 20:39
Reporter: davidak Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: withdraw from exchange is pending forever
Description: https://youtu.be/SSQW56RCC9E?t=617
Tags:
Steps To Reproduce: see video
Additional Information:     app version 0.8.0 (not available in selection above)
Attached Files: Screenshot from 2021-05-16 01-24-35.png (79,429 bytes) 2021-05-16 01:27
https://bugs.gnunet.org/file_download.php?file_id=1056&type=bug
Notes
(0017856)
davidak   
2021-05-16 01:27   


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6866 [Taler] wallet (Android App) crash have not tried 2021-05-16 01:21 2021-08-24 20:39
Reporter: davidak 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.8.5  
Summary: app crash when withdraw amount is too high
Description: https://youtu.be/SSQW56RCC9E?t=495

when you withdraw 20+*9s (9999999...) from exchange, the app crashes
Tags:
Steps To Reproduce: see video
Additional Information: app version 0.8.0 (not available in selection above)
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6599 [Taler] wallet (TS core) minor have not tried 2020-09-10 19:30 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet should emit better error message when balance is insufficient due to pending refresh
Description: Right now, when a refresh is very slow, making a purchase can result in "insufficient balance", even though the balance the wallet shows *looks* sufficient.

We should instead emit a different error code for this message, which can be appropriately handled by the UI.
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:
6595 [Taler] wallet (TS core) minor have not tried 2020-09-09 17:06 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet should check version of bank integration API before using it
Description: ... to make future upgrades easier.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6588 [Taler] wallet (TS core) tweak have not tried 2020-09-08 16:48 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet-core should support range queries for the transactions list
Description: This might require some additional indices to be faster!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6570 [Taler] wallet (WebExtensions) feature have not tried 2020-09-04 13:10 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: improve rendering of transactions list
Description: Right now we pretty much dump the JSON. We should apply a similar styling as we had in the old history renderer.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017148)
Florian Dold   
2020-11-18 17:53   
General rendering has been improved, but still missing is:

* displaying details
* showing error information and details
(0017887)
Florian Dold   
2021-05-20 21:49   
Now that the wallet supports it, what's also missing is the deletion of transactions.
(0017945)
sebasjm   
2021-06-07 16:51   
displaying details and deletion can be seen at b023bb502edf8d62f51257aff2105f3c33713b42
(0017951)
Florian Dold   
2021-06-14 18:35   
Discussed on mumble: There should also be an option to retry a pending operation. The wallet-core operation "retryTransaction" is analogous to "deleteTransaction".
(0018080)
belen   
2021-08-06 17:09   
I have pushed some designs to https://git.taler.net/large-media.git/tree/issue_6570

They cover the rendering of the transaction history and transaction details, deleting transactions and retrying a pending operations.

Pending showing error information and details. It would be good to see those as shown in the wallet first, since the whole idea is to bring the web extension as close as possible to the wallet.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6567 [Taler] wallet (Android App) minor have not tried 2020-09-04 08:12 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: balance display truncates balance and need better labeling
Description: When I have only TESTKUDOS in the wallet and I go to the balances page, the header shows:

   "Balance: 18.4 TESTKU..." (truncated)

and a list of transactions is shown below, without any label that this is a list of transactions.

IMHO we should pull the balance out of the action bar header and maybe even render centered.

The transaction list below needs clearer labeling, as everything else points the user to "balance", when in fact these "+/- XYZ" entries are transactions.

"""

# Balance [ action bar header]

                    123.45
               TESTKUDOS

   [ shown only when multiple currencies are in the wallet]
    show other currencies

[ written in smaller, gray-ish font]
Transactions (only for TESTKUDOS)

[ ... existing transactions list ... ]

"""
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016985)
grote   
2020-09-28 19:53   
Is there a consensus that the UI should be changed as described? I see that Christian added a relationship to 0004819 which would also resolve the issue (at least for TESTKUDOS).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6565 [Taler] wallet (TS core) minor have not tried 2020-09-03 20:46 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet should try recoup when payment fails with certain error codes
Description: Currently recoup is only done when the exchange information is updated/queried.
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:
6558 [Taler] wallet (TS core) feature have not tried 2020-09-03 12:34 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: transaction item for "lost coins due to expiration" needed
Description: In some cases, the auto-refresh comes to late and the wallet loses coins. The wallet has to show an appropriate item in the transactions list for that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016824)
Florian Dold   
2020-09-03 17:27   
According to the discussion in 0006561, we also need to make sure that coins can be "revived" from this state when they were marked as expired because of a wrong system time setting.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6548 [Taler] wallet (TS core) tweak have not tried 2020-09-01 14:34 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: wallet should handle (accidental!) double spending and have integration test for it
Description: ... which can be caused by a restore from backup.

The wallet should respond appropriately.
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:
6027 [Taler] wallet (Android App) feature always 2020-01-06 23:44 2021-08-24 20:39
Reporter: davidak Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: android wallet should support tipping
Description: ... via taler:// tip URIs.

The wallet-core now exposes the tipping API: https://docs.taler.net/taler-wallet.html#tipping-api-calls
Tags:
Steps To Reproduce: 1. open https://survey.demo.taler.net/
2. submit survey
3. scan QR code with app

you just get an error which says: URL from QR code doesn't contain Taler payment.
Additional Information: Android app version 0.6.0pre8, apk from website
Attached Files:
Notes
(0015234)
Florian Dold   
2020-01-07 17:10   
Tipping is not implemented yet in the Android UI for the wallet. I'll keep this bug open to track progress for the feature.
(0015293)
grote   
2020-01-22 19:54   
Meanwhile the survey returns:

The backend returned status code 404.

Backend Response:

{'code': 1151, 'hint': 'Reserve unknown at exchange'}
(0017762)
Christian Grothoff   
2021-04-18 02:30   
Survey page should be fixed now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5840 [Taler] deployment and operations tweak have not tried 2019-08-18 15:24 2021-08-24 20:39
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: set up buildbot to run taler-wallet-cli periodically against test and demo
Description: Buildbot should
 * download the latest wallet from NPM
 * use the CLI to trigger the integration test against {test,demo}.taler.net
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015043)
nikita   
2019-10-28 12:57   
More along the lines of "what makes a complete test" as I'm not yet testing all subcommands of integration test.
A complete test == all subcommands, but for {demo, test} depending on the runner?
(0015044)
Florian Dold   
2019-10-28 13:01   
Right now the headless wallet doesn't implement tests for certain functionality. While this functionality will be exposed separately as well, it should be part of the "integrationtest" subcommand as well.

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

("integrationtest" runs a bunch of tests against the specified URLs but doesn't depend on any local state, while the other subcommands manipulate your local wallet database.)
(0016750)
Florian Dold   
2020-08-24 16:56   
The wallet now has a much bigger suite of integration tests.

We should upgrade the respective worker to run it.
(0016924)
MS   
2020-09-08 15:46   
This bug waits 0006490.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6843 [Taler] merchant backoffice SPA major always 2021-04-12 16:33 2021-08-24 20:32
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: every input type can be forgetable, handle UI to add checkbox
Description: this apply to the order

https://docs.taler.net/core/api-merchant.html#private-order-data-cleanup
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:
6901 [Taler] merchant backoffice SPA feature always 2021-06-14 16:33 2021-08-24 20:31
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: create a duration input UI
Description: For input values for fields of this type
https://docs.taler.net/core/api-common.html#tsref-type-RelativeTime

Should support touch and click (mobile/desktop)
Should have have seconds, minutes, hours and days
Should support forever

backoffice instance creation form needs this

attaching android example as an option
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: photo_2021-06-14_11-26-27.jpg (8,911 bytes) 2021-06-14 16:33
https://bugs.gnunet.org/file_download.php?file_id=1078&type=bug
There are no notes attached to this issue.


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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6659 [Taler] Web site(s) text always 2020-12-04 08:52 2021-08-24 20:31
Reporter: Stefan Platform:  
Assigned To: Stefan OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: FAQ website on taler.net - Answer to the question on user complaints, authorities for dispute settlement, and auditors' roles
Description: We have a question raised on the Taler FAQ website (https://taler.net/en/faq.html): 'To whom would consumers complain to in case of non-conversion or non-compliance?' which is not fully answered yet.

Actually, users of payment services can turn to national authorities dealing with complaints. Therefore, I would like to recommend that the FAQ website displays the following paragraph in addition to the text we already have there (2nd paragraph):

In case of user complaints concerning the management of exchange services, users can turn to their national authority responsible for settling disputes. For exchange services conducting business in Germany the authority in charge of disputes 'Universalschlichtungsstelle des Bundes' is reachable on https://www.verbraucher-schlichter.de. In addition to this, the European Online Dispute Resolution (ODR) platform provided by the European Commission can be called for the settlement of disputes concerning exchange services running their businesses in member states of the European Union.
 
Any exchange is audited by one or more independent auditors. Merchants and consumer wallets will report certain issues automatically to the auditors, but auditors may also provide a method for manual submission of issues. The auditors are expected to make their reports available to the respective regulatory authorities, or even the general public.

And now the German version (regarding https://taler.net/de/faq.html):

An welche Stelle können sich Nutzer des Bezahlsystems wenden, falls es zu Problemen mit Umwandlungen von Geldwerten oder Transaktionen kommt?

Nutzer wenden sich im Fall von Beschwerden über Exchange-Betreiber an die nationale Schlichtungsstelle des Landes, in dem der Exchange-Betreiber seinen Hauptsitz hat. In Deutschland ist dies die Universalschlichtungsstelle des Bundes in Kehl (https://www.verbraucher-schlichter.de). Bei einem Hauptsitz des Exchange-Betreibers in einem Staat der Europäischen Union besteht zudem die Möglichkeit, über die Plattform der Europäischen Kommission zur Online-Streitbeilegung (http://ec.europa.eu/odr) eine Beschwerde einzureichen.

Jeder Taler-Exchange wird von einem oder mehreren unabhängigen Auditoren geprüft und validiert. Sowohl die Verkäufersoftware als auch Taler-Wallets senden automatisiert Berichte an die Auditoren, die aus den Berichten erkennen, falls es zu Problemen bei Buchungen gekommen sein sollte. Die Auditoren haben auch die Möglichkeit, jederzeit einen Bericht über die Buchungen des Exchange manuell auszulösen, um Probleme zeitnah zu erkennen. Die Auditoren sind verpflichtet, ihre Berichte an die zuständigen Aufsichtsbehörden - und auch an die interessierte Öffentlichkeit - weiterzuleiten.
Tags: taler.net, translation, website
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:
6680 [Taler] Web site(s) text have not tried 2021-01-07 04:35 2021-08-24 20:31
Reporter: ttn Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: update wallet webpage
Description: Could you update the Website [4] with some instructions on how to both manually install the wallet from the binary (i.e. the link to the downloads and maybe some pointers about the installation process for unsigned add-ons) and link to the build instructions (I guess the wallet.git's README?)? Instead of linking to the dead Mozilla Addon Store website, we could maybe put a disclaimer that currently the extension is under review with Mozilla and we are having some difficulties with the review process.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017377)
ttn   
2021-01-20 05:56   
On gv.taler.net, i found the directory '/var/www/files/wallet/' with what appears to be recently
updated .xpi files.

(a) Is that (the latest) what you want to ask people to install "manually"?
(b) What is the externally visible URL for that directory?
(c) If answer to (a) is "no", which directory should i look in?

(I'm not familiar w/ web extensions development, but am happy to learn. :-D)
(0017378)
Christian Grothoff   
2021-01-20 22:29   
Really only Florian can say:
(a) I strongly suspect: yes. Florian needs to confirm.
(b) I don't think it is exposed at all yet. I think we should use wallet.taler.net/download/*. Florian should set that up, if (a) is right.
(c) see above.
(0017383)
ttn   
2021-01-21 04:24   
Poking around libeufin docs, i found:

 https://taler.net/files/wallet/

Whether that is the desired location or not, i don't know. :)
(0017384)
Florian Dold   
2021-01-21 11:07   
That's indeed the desired externally visible location for the download!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6612 [Taler] documentation feature have not tried 2020-09-29 17:57 2021-08-24 10:32
Reporter: Florian Dold Platform:  
Assigned To: ttn OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.1  
Summary: write some additional simple storefronts to illustrate/validate merchant backend API use cases
Description: We currently have the donations shop and digital content shop.

Some use cases of the merchant backend (selling of scarce products ("concert tickets"), inventory management, purchases bound to some login/account, management of purchases via proof of purchase) do not have a clear, simple demo implementation, but are either missing or buried in a Woocommerce patch.

We should:
1) Write down which use cases we actually care about
2) Implement them in very simple demo apps in the existing taler-frontend-demos repo and ideally write some API usage guide while doing that
3) adjust the merchant backend API if necessary

The motivation for this is to validate the API. Some corner cases are still unclear, such as the claim token (and how to write a shop for, say, concert tickets, where the storefront isn't an oracle to convert the order ID into a claim token),
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016986)
Florian Dold   
2020-09-29 18:42   
Other interesting use cases:

* Taler-native concert ticket shop (no login)
* Traditional ticket shops with Taler as one of many payment methods


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6864 [Taler] wallet (WebExtensions) major always 2021-05-15 07:27 2021-08-23 17:43
Reporter: leklachu Platform: Firefox  
Assigned To: sebasjm OS: Ubuntu  
Priority: urgent OS Version: 20.04  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.8.5  
Summary: Withdrawing money in Demo does not show exchange fees
Description: [Firefox extension version 0.8.0.9]

When withdrawing KUDOS in the GNU Taler demo, the option is to 'accept exchange fees and withdraw' but the exchange fees are not shown. (They are shown for payment.) Fees can be seen by observing the new wallet balance is 0.2 Kudos lower than that withdrawn.
Tags: Taler, Transparency, Wallet, Withdraw
Steps To Reproduce: 1. Create Taler demo account at https://demo.taler.net/en/
2. Withdraw 5 KUDOS into wallet
3. Observe amount to withdraw is 5 KUDOS
4. Accept withdrawal
5. See wallet history, 4.8 KUDOS withdrawn.
6. Realise Taler is just a new front for extorting money worldwide to finance Stallman's global takeover to subvert the world's development resources into completing Hurd
Additional Information:
Attached Files:
Notes
(0018088)
sebasjm   
2021-08-09 16:06   
I'm currently working on https://bugs.gnunet.org/view.php?id=6570 which I think it handles it perfectly.
I'm adding Belen into the conversation to check if there is something that she needs to check.
(0018122)
belen   
2021-08-23 17:43   
After reading the description, it seems to me there are 2 issues here:

1. The exchange fees are not shown during the withdrawal process
2. The exchange fees are not shown in the transaction history

1 above is addressed by the designs in https://bugs.gnunet.org/view.php?id=6096
2 above is addressed by the designs in https://bugs.gnunet.org/view.php?id=6570


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

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

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

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

# 1. Balances

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

# 2. Funds reservation

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

# 3. Device identifiers and encryption

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

# 4. Payments

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

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

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

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

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

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

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

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

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


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6949 [Taler] documentation text have not tried 2021-07-23 13:36 2021-08-11 11:52
Reporter: Christian Grothoff Platform: i7  
Assigned To: ttn OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: inventory use-cases should be properly described in merchant backend manual
Description: The manual should properly describe the inventory management use-case (limited stocks), and how to use product locks (when customer is building shopping cart), as well as order locks (once shopping cart is "complete") and the auto-unlocking (see 0006937).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018096)
ttn   
2021-08-11 05:34   
See https://git.taler.net/docs.git/commit/?id=108101d5c13e2e1e1e12290c29a53969ce715511
(particularly, the FIXME).
(0018098)
Christian Grothoff   
2021-08-11 09:17   
FIXME: I would say that the product locks expire after a given time if they are not transferred into an order lock, and the order locks expire when the offer to the customer expires without payment. There is not really any 'event' other than time that would remove the locks.
(0018099)
ttn   
2021-08-11 11:52   
Some recent commits, ending w/ "simplify":
2789962 2021-08-11 simplify; swap out old FIXME for new FIXME
f357f26 2021-08-11 link to ‘Reverse proxy configuration’
eaab49e 2021-08-11 replace hyphen between ‘reverse’ and ‘proxy’ with space
552ceeb 2021-08-11 add a pair of identical FIXMEs: "What about 40[34] swizzling? (0006944)"
Direct link: https://git.taler.net/docs.git/log/

Anyway, the new FIXME should be the last one in this file.

On to "how to use locks" documentation....


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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6988 [libeufin] nexus minor have not tried 2021-08-08 12:41 2021-08-08 12:43
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: transaction fetching with "--level=all" does not download statements if downloading reports fails due to no new data
Description: The command

$ libeufin-cli accounts fetch-transactions --level all --range-type all myacct

should download statements, even if no new reports are available and we thus get an EBICS error for downloading reports.

Currently, it gives up after trying to download the reports, and thus will never even get to downloading statements.
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:
6874 [Taler] bank (demonstrator) minor have not tried 2021-05-17 13:37 2021-08-05 23:16
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: investigate performance issues of wire gateway API
Description: Currently the requests from the exchange to the bank's wire gateway API cause high CPU load (seen as load on uwsgi).

We should investigate where this is coming from.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017943)
MS   
2021-06-05 10:36   
According to one first investigation, the problem lies in the Django's authentication system.
Possibly the password hashing slows things down. The problematic routine is "django.contrib.auth.authenticate()", called from "basic_auth()". Basically by commenting basic_auth() out, the high CPU usage disappears (*).

(*) there is only one high peak from uwsgi, just upon launching the bank.
(0018078)
Florian Dold   
2021-08-05 23:16   
=> pybank will eventually be rolled into LibEuFin, where we won't use the django auth system


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6981 [libeufin] nexus minor always 2021-08-05 21:30 2021-08-05 21:30
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: nexus returns 400 when facade authentication fails (instead of 401)
Description: In the logs: caught exception while handling .../taler-wire-gateway/history/{incoming,outgoing}/ (Authorization header not found)
Client gets a 400 bad request. Should be a 401. Reproduced easily via wget.
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:
6979 [Taler] wallet (TS core) minor have not tried 2021-08-04 21:24 2021-08-04 21:24
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: wallet should handle timeouts better
Description: The wallet currently doesn't handle timeout elegantly. Instead of some ad-hoc timeout parameter, we should use cancellation tokens, especially for HTTP requests.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6941 [Taler] merchant backend API (HTTP specification) feature have not tried 2021-07-23 13:19 2021-08-04 17:56
Reporter: ms-mantis Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: design protocol / business procedure for validating the owner of an order via the nonce
Description: In case of disputes, the business infrastructure needs to allow wallets to automatically verify their nonces.

A case might be to verify a nonce at a venue's entrance, in case two wallets claim to have bought the same ticket.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018067)
Christian Grothoff   
2021-08-04 17:56   
Note that checking "nonce" was deliberately not implemented in 0006955. Once it is specified, we should check the validity of the 'nonce' when posting a new order to the merchant backend.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6977 [Taler] wallet (TS core) minor have not tried 2021-08-04 17:47 2021-08-04 17:55
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: make wallet-core more resistant against node supply chain attacks
Description: The core wallet packages already have very few run-time dependencies.

However, the build process pulls in a huge number of packages.

We should restructure the build process so that it can also use ambient versions of the various executables instead of the ones shipped via NPM.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018065)
Florian Dold   
2021-08-04 17:55   
Might be a good idea to switch to https://github.com/evanw/esbuild to replace rollup and TypeScript.

Almost all of our run-time dependencies should be vendored.


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6972 [libeufin] nexus minor have not tried 2021-08-03 14:53 2021-08-03 14:53
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: review /facades and /facades/${id} implementation
Description: We currently have a lot of code duplication there, and the code is not generic for the facade, but only works with the TWG facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6771 [Taler] deployment and operations minor have not tried 2021-02-26 11:56 2021-08-01 15:16
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: website translation: add check that placeholders in translation and original string align
Description: Otherwise we might get hard to understand errors down the line.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017761)
Christian Grothoff   
2021-04-18 02:28   
Eh, I thought Weblate has a build-in check for this. What is the bug about?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6899 [Taler] bank (demonstrator) minor have not tried 2021-06-09 15:38 2021-08-01 15:15
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9  
Summary: bank requires expensive computation on every API call with authorization
Description: The bank uses hashed+salted passwords for API authentication.

Unlike with human users, where the authentication check is done once at login (and then only a signed cookie is verified), checking a password for *every* request is rather expensive.

We could:
* move to plain text API keys
* cache hashes of successful logins in memory

As a further complication in the pybank, we need to somehow work around the built-in django authentication system and do our own checks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017946)
Christian Grothoff   
2021-06-10 14:30   
What I do not get is that usually (in a good design), the (expensive) hash should be done on the client-side ONLY. After all, the HASH is what should be sent over the network, and a HASH of the password/passphrase is what we should store locally on the server-side. So why is this a problem in the first place?
(0017999)
Christian Grothoff   
2021-07-19 14:53   
This will be fixed when we migrate to libeufin as the existing Pybank should just die.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6952 [Taler] documentation text have not tried 2021-07-23 13:42 2021-08-01 15:07
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: document how public /pay handles refunded coins
Description: The current implementation allows them, but excludes the refunded amount from the total payment amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018008)
Florian Dold   
2021-07-23 14:18   
From our workshop discussion: The merchant should actually just *reject* /pay requests with refunded coins, as due to the exchange API, such payments can never work in the first place. Once a coin is refunded, it can't be spent on the same h_contract_terms again.

The merchant code should not accommodate with extra, complex logic for an input that will lead to an error at the exchange anyway.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6951 [Taler] documentation text have not tried 2021-07-23 13:41 2021-08-01 15:07
Reporter: Florian Dold Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: document state machine for payment process
Description: We should have a diagram for the "state machine" behind the payment process.

Oec also suggesting having this in an executable from, so that the code doesn't fall out of sync with the specification. But at this point, considering that there is a DB in between, I'm not sure how we would approach this.
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:
6652 [Taler] exchange feature have not tried 2020-11-26 17:07 2021-08-01 15:04
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: low OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: support peer-to-peer payments
Description: Right now we have a strict separation between merchants and customers. Eventually we might also want to support direct payments between customers via their Taler wallet.

The main challenge for this is KYC. We could implement special KYCed reserves for this that are then used as the wire info for a payment (payto://taler-kyc-reserve/) from customer to customer. The KYC would allow transaction limits to be placed on receiving money as a customer. A prerequisite for these P2P payments would be that the receiving party has a KYC registered reserve/account with an exchange.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017366)
Florian Dold   
2021-01-17 20:53   
It's still totally unclear is how the signaling between the sender and receiver of the P2P payment will work. Unlike when a merchant is involved, the two parties can't directly communicate with each other. Of course the exchange might be able to help here, at least as long as it's not expensive for the exchange.

So what's the desired user experience here?

Does the receiver of the money initiate? If so, does the receiver simply give some generic address, or do they create some kind of "P2P contract terms"? How does the receiver learn whether/when they received a payment?

Does the sender of the money initiate? If so, how does the sender know when/how to sign deposit permissions? Or do we have some special "wildcard deposit permission" where the P2P receiver can substitute their own wire transfer information?
(0017367)
Florian Dold   
2021-01-17 21:17   
Pro/con of sender-initiated payments:
* can be used to simply attach money to some message
* doesn't give the sender any guarantees what will happen with their money
* requires additional "wildcard deposit permission" support from the exchange
   (the receiver of the message does a /deposit, but can give arbitrary wire data)
* the contract terms will be chosen by the receiver, and will be completely under their control
* the size of the payment message is proportional to the number of coins involved

Pro/con of receiver-initiated payments:
* lots of overlap with payments based on a merchant backend
* unclear how the communication will happen between the two parties

I think the sender-initiated payments are simpler and cover more use cases that are not already covered by payments where a merchant backend is involved.
(0018046)
Christian Grothoff   
2021-08-01 15:04   
Spec seems done, moving towards implementation category.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6756 [Taler] documentation text have not tried 2021-02-18 11:22 2021-08-01 12:24
Reporter: Florian Dold Platform:  
Assigned To: Stefan OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: document considerations for how exchanges are identified
Description: We have had some discussions around whether to identify exchanges by their canonical base URL or by their master public key. In particular, there are scenarios where the master public key could change while the base URL stays the same.

We should document these considerations somewhere, because confusion about this has come up repeatedly in the past.
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:
6954 [Taler] merchant backoffice SPA feature have not tried 2021-07-23 14:20 2021-08-01 12:20
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create sample deployment to test external authentication
Description: We currently have only tested the SPA with merchant-internal token authentication.

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6968 [GNUnet] other minor have not tried 2021-08-01 11:04 2021-08-01 11:06
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: Debian package improvements
Description: The current Debian package for GNUnet needs a few improvements. I'm filing this bug to keep track of them.

* User/group names should probably not be dynamic. I don't know any other Debian package that has variable user names. It just makes things more complex.

* Configuration files dynamically generated to /etc/ are just overwritten on each install. That's unacceptable, as it might overwrite user changes. We need to use the standard ucf tooling so that Debian manages configuration files on upgrades properly.

* We are currently installing systemd system unit files *dynamically* to /etc/, instead of using debhelper facilities.

* We are currently installiny systemd user unit files manually. This means that every user who logs in will auto"magically" run a GNUnet peer.

* We don't seem to use dpkg-statoverride correctly. We check with "dpkg-statoverride --list", but then don't use statoverride to *change* the permissions permanently.

* The insert_gns logic seems buggy, considering that "set -e" is set. The error handling part will never be executed, but the script will just be stopped.

* The whole NSS setup logic should IMHO only be executed when the user explicitly requested so via debconf.
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:
6401 [GNUnet] GNS feature always 2020-06-21 22:18 2021-07-31 10:58
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.15.1  
Summary: Filter DNS2GNS answers in some cases
Description: Currently, dn2gns does not filter by queried record type.
We should probably filter *unless* the client is _not_ on loopback and the resulting message would be too big for a single UDP packet.

Here, we should ideally _also_ check the (E)DNS settings and if (E)DNS is not specified, stick to the 512-byte maximum (and first filter only DNSSEC Records if (E)DNS is not specified _and_ the reply gets too big).
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:
6114 [GNUnet] integration tests minor always 2020-03-06 10:05 2021-07-31 10:58
Reporter: tanguy Platform: x86_64  
Assigned To: schanzen OS: Guix System  
Priority: normal OS Version: 944b1d0  
Status: feedback Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.15.1  
Summary: Tests failing on Guix System
Description: To update GNUnet package from 0.11.8 to 0.12.2, I had to disable several tests. Those are:
  - src/cadet/Makefile
    * test_cadet_2_reopen
    * test_cadet_5_forward
    * test_cadet_5_signal
    * test_cadet_5_keepalive
    * test_cadet_5_speed
    * test_cadet_5_speed_ack
    * test_cadet_5_speed_reliable
    * test_cadet_5_speed_reliable_backwards
    * test_cadet_5_speed_backwards
    * test_cadet_5_reopen
  - src/transport/Makefile
    * test_transport_api_https
    * test_transport_blacklisting_multiple_plugins
  - src/testbed/Makefile
    * test_testbed_api_2peers_1controller
    * test_testbed_api_test
    * test_testbed_api_statistics
    * test_testbed_api_topology
    * test_testbed_api_topology_clique

I'm attaching the full log.

Some tests where already disabled for version 0.11.8:
  - src/transport/Makefile
    * test_transport_api_manipulation_cfg
    * test_transport_api_udp_nat
  - src/topology/Makefile
    * test_gnunet_daemon_topology
  - src/namestore/Makefile
    * am__append_2
  - src/gns/Makefile
    * am__append_4
  - contrib/Makefile
    * check_PROGRAMS.*

Those I didn't try to re-enable, so I don't have any log.
Tags: tng
Steps To Reproduce: Get latest Guix sources: https://guix.gnu.org/cookbook/en/guix-cookbook.html#Direct-checkout-hacking
Apply GNUnet 0.12.2 patch: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39673
Build: $ ./pre-inst-env guix build --keep-failed gnunet
Additional Information: my_gnunet_bugreport.log

I had to complete it manually because gnunet-bugreport does not really work well on Guix System.


    INFO: gnunet-bugreport 0.11.0
    INFO:
    INFO: Please submit the following
    INFO: information with your bug report:
    =========================================
    INFO: OS : Linux
    INFO: OS RELEASE : 5.4.18-gnu
    INFO: HARDWARE : x86_64
    INFO: awk : 5.0.1
    INFO: gcc :
    INFO: cc :
    INFO: c++ :
    INFO: clang :
    INFO: clang++ :
    WARNING: make : Not Found (unexpected result)
    INFO: gmake :
    INFO: automake : 1.16.1
    INFO: libtool : 2.4.6
    WARNING: libextractor : 1.9
    INFO: GNUnet 0.8 : Not Found (good)
    INFO: GNUnet : 0.12.2
    INFO: git commit :
    INFO: libgcrypt : 1.8.4
    INFO: mysql :
    INFO: pkg-config : 0.29.2
    INFO: glib2 : 2.60.6
    INFO: GTK2 : 2.24.32
    INFO: GTK3 : 3.24.13
    INFO: GTK4 :
    ERROR: GMP : 6.1.2
    ERROR: libunistring : 0.9.10
    INFO: GNU gettext : 0.20.1
    INFO: gettext : 0.20.1
    INFO: libcurl : 7.65.3
    INFO: libgnurl : 7.67.0
    INFO: libmicrohttpd : 0.9.70
    INFO: GNU GLPK : 4.65
    INFO: GnuTLS : 3.6.9
    =========================================
    INFO: Bug report saved in ./my_gnunet_bugreport.log
Attached Files: 4z2sv4v1a6h8092160sq61arwyy68r-gnunet-0.12.3.drv.bz2 (40,527 bytes) 2020-03-06 10:05
https://bugs.gnunet.org/file_download.php?file_id=876&type=bug
Notes
(0015778)
schanzen   
2020-04-24 10:32   
Is this patch applied yet?
(0015800)
nikita   
2020-04-29 11:59   
(Last edited: 2020-04-29 12:09)
What patch? I only see a build directory or what I assume is one (.drv.bz is a compressed log file (thanks Ricardo)) and the guix bugtracker holds no patch to fix this.
tanguy: It is very likely you run into a similar problem like Nix: https://github.com/NixOS/nixpkgs/issues/73793

(0015801)
nikita   
2020-04-29 12:06   
> I had to complete it manually because gnunet-bugreport does not really work well on Guix System.

Can we get a separate bugreport for this? gnunet-bugreport is a bit basic and I was meaning to abstract it more, but this takes time
(0015803)
tanguy   
2020-04-29 12:28   
Hi guys!

Thanks for following up on this! Unfortunately, I haven't done anything since my last note! Sorry!

I'll try to spend some time on it at the week end, and I'll open a separate report for gnunet-bugreport.
(0015806)
nikita   
2020-04-29 12:59   
Hi,

I think the resolution lies within the 2 bugreports I linked to this one, I'd advice to just skip the tests again for now.
(0015853)
tanguy   
2020-05-05 09:14   
Hi,

@schanzen, yes, my patch has been merged into guix master with all the failing tests deactivated. We now have a "working" gnunet 12.2 on Guix and I'm trying to validate (slowly, slowly) all the components to make sure it works.

@nikita, I reported the gnunet-bugreport problem (which looks like a guix system "problem") in 0006233. I'll read the 2 linked bugs and the Nix issue. Thanks for the links! So for the time being, I'll keep the failing test deactivated.
(0015862)
schanzen   
2020-05-06 17:41   
Seems to be a TNG related issue. Moving to 0.14
(0016439)
tanguy   
2020-07-10 15:41   
Hi @schanzen,

I've uprgaded Guix package to 0.13.0 (I'll send the patch for integration today) and I had to disable another test to make the tests pass:
* test_testbed_api_test_timeout

Kind regards
(0016440)
schanzen   
2020-07-10 16:07   
(Last edited: 2020-07-10 16:08)
Did you have to disable thsi test in addition or only this test this time? Di you have a log to look at?
Testbed is not critical, so I guess this is fine.

I am asking because there is a chance that the cadet tests now work.

(0016451)
tanguy   
2020-07-15 11:10   
Hi @schanzen

> Did you have to disable thsi test in addition or only this test this time?

In addition of all the tests mentioned above.

> Di you have a log to look at?

Yes…

```
FAIL: test_testbed_api_test_timeout
===================================

Jul 15 08:32:56-017816 test_testbed_api_test-19106 ERROR Assertion failed at test_testbed_api_test_timeout.c:98.
Jul 15 08:32:56-018321 ats-19248 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018322 ats-19274 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018321 ats-19236 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018345 ats-19247 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018940 ats-19271 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018943 ats-19198 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019071 ats-19228 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019124 ats-19227 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019137 ats-19194 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019456 ats-19312 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019508 ats-19221 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019651 ats-19230 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019992 ats-19181 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-021692 ats-19278 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022023 util-client-19189 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-022196 ats-19255 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022500 ats-19211 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022795 ats-19205 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-023986 ats-19290 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-023998 ats-19294 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-024072 ats-19261 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-024544 transport-api-core-19213 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-024672 ats-19269 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-025049 util-client-19200 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-025494 transport-api-core-19219 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-025964 ats-19286 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026422 ats-19324 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026638 ats-19212 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026765 ats-19316 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-027634 util-client-19241 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-028315 util-client-19265 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-031411 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031510 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031556 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031575 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031901 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031924 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031935 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031954 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032872 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032885 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032896 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032907 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032918 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032929 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032939 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032950 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032963 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
FAIL test_testbed_api_test_timeout (exit status: 1)
```

> I am asking because there is a chance that the cadet tests now work.

I'll try to run the cadet tests and I'll re-enable them in the next package update if they pass.
(0016452)
schanzen   
2020-07-15 11:24   
Interesting. If you have the time, it would be great if you could execute the failing tests by themselves (not in make check) so that we can see what is happening.
There should also be .log files for each test with potentially more info.
I currently do not have a guix system and on my platforms the tests pass atm so I cannot reproduce.
(0016453)
tanguy   
2020-07-15 13:53   
>> I am asking because there is a chance that the cadet tests now work.
> I'll try to run the cadet tests and I'll re-enable them in the next package update if they pass.

They pass ! I'll submit a patch to update the package definition.


> There should also be .log files for each test with potentially more info.

It looks the same to me:

```
cat /tmp/guix-build-gnunet-0.13.1.drv-0/gnunet-0.13.1/src/testbed/test_testbed_api_test_timeout.log
Jul 15 08:32:56-017816 test_testbed_api_test-19106 ERROR Assertion failed at test_testbed_api_test_timeout.c:98.
Jul 15 08:32:56-018321 ats-19248 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018322 ats-19274 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018321 ats-19236 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018345 ats-19247 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018940 ats-19271 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-018943 ats-19198 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019071 ats-19228 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019124 ats-19227 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019137 ats-19194 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019456 ats-19312 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019508 ats-19221 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019651 ats-19230 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-019992 ats-19181 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-021692 ats-19278 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022023 util-client-19189 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-022196 ats-19255 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022500 ats-19211 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-022795 ats-19205 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-023986 ats-19290 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-023998 ats-19294 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-024072 ats-19261 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-024544 transport-api-core-19213 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-024672 ats-19269 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-025049 util-client-19200 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-025494 transport-api-core-19219 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-025964 ats-19286 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026422 ats-19324 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026638 ats-19212 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-026765 ats-19316 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
Jul 15 08:32:56-027634 util-client-19241 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-028315 util-client-19265 WARNING Error during sending message of type 344: Broken pipe
Jul 15 08:32:56-031411 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031510 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031556 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031575 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031901 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031924 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031935 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-031954 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032872 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032885 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032896 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032907 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032918 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032929 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032939 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032950 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
Jul 15 08:32:56-032963 transport-api-core-19121 ERROR Error receiving from transport service (1), disconnecting temporarily.
FAIL test_testbed_api_test_timeout (exit status: 1)
```

The failure might come from the Guix test environment, but I'm not knowledgeable enough to investigate. Sorry!
(0016658)
tanguy   
2020-08-19 14:47   
Hi Gnunet!

I don't know if I should have opened a new bug report for this, so I'm posting it here. Feel free to let me know if this should be in its own bug report. This being said…

In Guix, we have a working package definition for 0.13.1. I tried to update to 0.13.2, but (at least) one more test is failing:

```
[…]
make[3]: Entering directory '/tmp/guix-build-gnunet-0.13.2.drv-0/gnunet-0.13.2/src/util'
  CC test_bio.o
  CCLD test_bio
  CC test_client.o
  CCLD test_client.nc
  CCLD test_client_unix.nc
  CC test_common_allocation.o
  CCLD test_common_allocation
  CC test_common_endian.o
  CCLD test_common_endian
  CC test_common_logging.o
  CCLD test_common_logging
  CC test_configuration.o
  CCLD test_configuration
  CC test_container_bloomfilter.o
  CCLD test_container_bloomfilter
  CC test_container_dll.o
  CCLD test_container_dll
  CC test_container_meta_data.o
  CCLD test_container_meta_data
  CC test_container_multihashmap.o
  CCLD test_container_multihashmap
  CC test_container_multihashmap32.o
  CCLD test_container_multihashmap32
  CC test_container_multipeermap.o
  CCLD test_container_multipeermap
  CC test_container_heap.o
  CCLD test_container_heap
  CC test_crypto_symmetric.o
  CCLD test_crypto_symmetric
  CC test_crypto_crc.o
  CCLD test_crypto_crc
  CC test_crypto_ecdsa.o
  CCLD test_crypto_ecdsa
  CC test_crypto_eddsa.o
  CCLD test_crypto_eddsa
  CC test_crypto_ecdhe.o
  CCLD test_crypto_ecdhe
  CC test_crypto_ecdh_eddsa.o
  CCLD test_crypto_ecdh_eddsa
  CC test_crypto_ecdh_ecdsa.o
  CCLD test_crypto_ecdh_ecdsa
  CC test_crypto_ecc_dlog.o
  CCLD test_crypto_ecc_dlog
  CC test_crypto_hash.o
  CCLD test_crypto_hash
  CC test_crypto_hash_context.o
  CCLD test_crypto_hash_context
  CC test_crypto_hkdf.o
  CCLD test_crypto_hkdf
  CC test_crypto_kdf.o
  CCLD test_crypto_kdf
  CC test_crypto_paillier.o
  CCLD test_crypto_paillier
  CC test_crypto_random.o
  CCLD test_crypto_random
  CC test_crypto_rsa.o
  CCLD test_crypto_rsa
  CC test_disk.o
  CCLD test_disk
  CC test_getopt.o
  CCLD test_getopt
  CC test_hexcoder.o
  CCLD test_hexcoder
  CC test_mq.o
  CCLD test_mq
  CC test_os_network.o
  CCLD test_os_network
  CC test_peer.o
  CCLD test_peer
  CC test_plugin.o
  CCLD test_plugin
  CC test_program.o
  CCLD test_program
  CC test_regex.o
  CCLD test_regex
  CC test_resolver_api.o
  CCLD test_resolver_api.nc
  CC test_scheduler.o
  CCLD test_scheduler
  CC test_scheduler_delay.o
  CCLD test_scheduler_delay
  CC test_service.o
  CCLD test_service
  CC test_strings.o
  CCLD test_strings
  CC test_strings_to_data.o
  CCLD test_strings_to_data
  CC test_speedup.o
  CCLD test_speedup
  CC test_time.o
  CCLD test_time
  CC test_tun.o
  CCLD test_tun
  CC test_os_start_process.o
test_os_start_process.c: In function ‘run_task’:
test_os_start_process.c:127:22: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdin = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_YES,
                      ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
test_os_start_process.c:129:23: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdout = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_NO,
                       ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
test_os_start_process.c: In function ‘check_kill’:
test_os_start_process.c:205:22: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdin = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_YES,
                      ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
test_os_start_process.c:207:23: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdout = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_NO,
                       ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
test_os_start_process.c: In function ‘check_instant_kill’:
test_os_start_process.c:250:22: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdin = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_YES,
                      ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
test_os_start_process.c:252:23: error: too many arguments to function ‘GNUNET_DISK_pipe’
   hello_pipe_stdout = GNUNET_DISK_pipe (GNUNET_YES, GNUNET_YES, GNUNET_NO,
                       ^~~~~~~~~~~~~~~~
In file included from ../../src/include/gnunet_network_lib.h:72:0,
                 from ../../src/include/gnunet_scheduler_lib.h:96,
                 from ../../src/include/gnunet_mq_lib.h:38,
                 from ../../src/include/gnunet_client_lib.h:46,
                 from ../../src/include/gnunet_util_lib.h:68,
                 from test_os_start_process.c:29:
../../src/include/gnunet_disk_lib.h:429:1: note: declared here
 GNUNET_DISK_pipe (enum GNUNET_DISK_PipeFlags pf);
 ^~~~~~~~~~~~~~~~
make[3]: *** [Makefile:2362: test_os_start_process.o] Error 1
make[3]: Leaving directory '/tmp/guix-build-gnunet-0.13.2.drv-0/gnunet-0.13.2/src/util'
make[2]: *** [Makefile:3057: check-am] Error 2
make[2]: Leaving directory '/tmp/guix-build-gnunet-0.13.2.drv-0/gnunet-0.13.2/src/util'
make[1]: *** [Makefile:558: check-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-gnunet-0.13.2.drv-0/gnunet-0.13.2/src'
make: *** [Makefile:636: check-recursive] Error 1
```

Any idea what went wrong?! Any help welcome.
(0016659)
schanzen   
2020-08-19 16:23   
Hi. There was a change in the APIs which we did not fix for the release in the tests.
So this is expected and our fault, 0.13.3 will fix it.
(0016663)
tanguy   
2020-08-19 17:38   
Hi @schanzen, thanks for your answer!

So I'll skip 0.13.2 and wait for 0.13.3.
(0017623)
schanzen   
2021-03-14 14:09   
Is this still an issue with recent versions?
(0017860)
Brendan   
2021-05-17 08:29   
Probably not. I have a 0.14.1 package definition ill be sending in soon that builds with only two disabled tests:

test_transport_api_https (these kinds of tests usually fail in CI environments)
test_setu_api

 FAIL: test_setu_api
===================

May 07 09:28:41-437567 util-client-12440 WARNING Error during sending message of type 1021: Broken pipe
May 07 09:28:41-437591 set-12440 INFO Destroying channel due to GNUNET_CADET_disconnect()
May 07 09:28:41-437596 setu-12440 WARNING Union operation failed
May 07 09:28:41-438776 set-12440 INFO Destroying channel due to GNUNET_CADET_disconnect()
May 07 09:28:41-438781 setu-12440 WARNING Union operation failed
May 07 09:28:41-447502 setu-12440 ERROR Bytes Transmitted: 10627
May 07 09:28:41-447511 setu-12440 ERROR Reached tradeoff bandwidth/rtt: 10627.000000
May 07 09:28:41-447515 set-12440 ERROR RTT:1.000000
FAIL test_setu_api (exit status: 1)
(0017861)
Brendan   
2021-05-17 08:46   
Also here is error for test_transport_api_https


May 17 06:38:46-467773 transport-https_server-5785 ERROR Failed to start transport-https_server IPv4 server component on port 12084
May 17 06:38:46-467868 transport-https_server-5785 ERROR Failed to start transport-https_server IPv6 server component on port 12084
May 17 06:38:46-467874 transport-https_server-5785 ERROR No transport-https_server server component started on port 12084
May 17 06:38:46-467998 transport-5785 ERROR Failed to load transport plugin for `libgnunet_plugin_transport_https_server'
May 17 06:39:16-247433 test_transport_api_https-5765 WARNING Testcase timed out
May 17 06:39:16-249309 ats-5786 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
FAIL test_transport_api_https (exit status: 1)
(0017866)
schanzen   
2021-05-17 15:08   
The https tests are wonky. The setu test issue should be investigated I guess. Keeping open for now.
(0017892)
Brendan   
2021-05-22 16:54   
Here is another test failure, although it doesn't fail every time.
 
cat /tmp/guix-build-gnunet-0.14.1-00c2115.drv-0/source/src/testbed/test_testbed_underlay.log
May 20 20:42:55-459013 test_testbed_underlay-9591 WARNING Peers 0 and 2 should not get connected
May 20 20:42:55-461567 ats-9620 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
May 20 20:42:55-461939 ats-9624 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
May 20 20:42:55-463838 transport-api-core-9616 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466559 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466716 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466740 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
FAIL test_testbed_underlay (exit status: 1)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5998 [GNUnet] namestore service minor have not tried 2019-12-20 02:56 2021-07-31 10:58
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.15.1  
Summary: Namestore should enforce delegation rules for record adding according to LSD001
Description: GNS2DNS: It is possible to add (e.g. A) records to a name that already has a GNS2DNS record => It does not work the other way around so this should also not work (?).

Tags: lsd0001
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:
5893 [GNUnet] build process minor have not tried 2019-09-13 19:35 2021-07-31 10:58
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.15.1  
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: chore
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5708 [GNUnet] build process feature have not tried 2019-04-30 18:46 2021-07-25 09:27
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Extend gnunet-config with output of build configuration Was: configure script should output summary of configuration
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: beginner, chore, low hanging fruit
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014362)
nikita   
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 a dual purpose.

So in addition to writing these values to a file, they should also be exposed via AC_DEFINE so that gnunet-config can output them.

It's useful both for other packages that consume GNUnet, as well as for figuring out what features your installed version supports. AFICT there is currently no other way than to look at the source tree and ./configure invocation for that. Some build systems (e.g. cmake and meson) can use this <pkgname>-config tool to discover dependencies.
(0014370)
Christian Grothoff   
2019-05-02 14:32   
I'm not sure writing to another _file_ makes sense, we have the configure output to the terminal, and of course options detected should go into gnunet_config.h via AC_DEFINE() -- many do already -- so that's already a file we generate with the result of configure. Expanding gnunet_config.h to include more is fine, having an extra file seems superfluous.

I'm not sure how this relates to gnunet-config (separate issue?), or why this was assigned to me (hence un-assigning).
(0014627)
nikita   
2019-07-01 12:25   
This already ends up in config.log, I don't understand why having another file is necesssary. If we want to extract it from there, we can just use an awk script to get the information out of there, given that we still have the source.
(0014628)
nikita   
2019-07-01 12:30   
Having the gnunet-config tool handle this with say, --cflags, --ldflags etc in case you want to *install* this will be better because maybe (I'm not 100% sure) having a file which changes per installation might introduce non-reproducible artifacts to the distribution (not: the binary builds). Having gnunet-config handle this also means we can point to a single installed tool for developers and users.
(0017678)
schanzen   
2021-04-03 20:50   
I take from this conversation that what we want to have are flags for gnunet-config including:

--features
--prefix
--libs
--cflags

etc.
Shounds like an easy task for new contributors to me.
(0018017)
schanzen   
2021-07-25 09:27   
Flags to be added:

[X] CFLAGS
[X] LDFLAGS
[X] PREFIX
[ ] --db-backends -> postgres sqlite mysql etc
[ ] --http-client-backend -> curl/gnurl
[ ] --transports -> http bluetooth tcp udp etc
[ ] --ssl-backend -> gnutls vs openssl
[ ] --is-experimental -> Boolean/True/False with retval


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6926 [GNUnet] util library minor have not tried 2021-07-16 19:17 2021-07-24 10:58
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version: 0.15.0  
Summary: some config errors are reported without any file information
Description: When (by mistake!) using @INCLUDE@ instead of @INLINE@, I only get the following log line:

  Jul 16 16:27:50-400090 util-17611 WARNING Syntax error while deserializing in line 1

However, I do not get *any* information about which log file is actually affected.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017992)
Christian Grothoff   
2021-07-17 20:17   
Fixed in 33830e71f..70de6f2ad


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6925 [GNUnet] util library minor have not tried 2021-07-16 19:15 2021-07-24 10:58
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version: 0.15.0  
Summary: @INLINE@ does not understand absolute paths
Description: The path after inline is always interpreted as a relative path, even when starting with a slash.

Jul 16 17:06:13-563615 util-6214 WARNING Error while determining the file size of `/etc/taler//etc/taler/exchange-system.conf'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017993)
Christian Grothoff   
2021-07-17 20:17   
Fixed in 33830e71f..70de6f2ad


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6916 [GNUnet] core service trivial always 2021-07-09 14:40 2021-07-24 10:58
Reporter: baseball11 Platform:  
Assigned To: thejackimonster OS:  
Priority: low OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version: 0.15.0  
Summary: Unabled to use GNUNet Library with C++.
Description: struct GNUNET_MESSENGER_MessageBody
(In file: src/include/gnunet_messenger_service.h)
's member variables using C++ reserved words(delete and private)

Because of this It's impossible to use gnunet library with C++ (Cause compile error).

I tried to commit, but I don't seem to have an access to the repository, so I post this here.

Thank you.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017994)
thejackimonster   
2021-07-17 21:14   
This should be fixed now with following commit:
https://git.gnunet.org/gnunet.git/commit/?id=c892ac24758e34a109db15df17fdf38e27ac7de3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6930 [Anastasis] C client library minor N/A 2021-07-19 14:29 2021-07-19 14:29
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: acknowledged Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.3.0  
Summary: check truth expiration is included properly in policy expiration
Description: The current API does not return when truth expires after uploads, which is probably fine as truth uploads are fully client-controlled.
However, we should double check that the truth expiration is correctly set and always at the same time where the accounts with the encrypted recovery document expire --- as we only show the policy expiration in the UI, and it would be bad if the policy persisted longer than the truth. Needs testing/review.
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:
5844 [Taler] wallet (TS core) tweak have not tried 2019-08-18 21:07 2021-07-13 06:51
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
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:
Notes
(0016932)
Florian Dold   
2020-09-08 18:12   
Instead of wrapper types, we can use flavors, which are compile-time only:

interface Flavoring<FlavorT> {
  _type?: FlavorT;
}
export type Flavor<T, FlavorT> = T & Flavoring<FlavorT>;

(via https://spin.atomicobject.com/2018/01/15/typescript-flexible-nominal-typing/)

This allows implicit conversions between the "unflavored" type and flavored type, but prevents mixups between different flavored types.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6363 [Taler] mechant backend feature have not tried 2020-06-03 13:31 2021-07-13 06:49
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: allow merchants to query more information about the deposit status
Description: Quoting from the e-mail discussion:

>> I'm not really sure what to do there in practice, as "Taler 1.0" doesn't
>> really have any way for the merchant to ask about the status of the
>> transfer other than trying to call the exchange.
>>
>
> Well, we do have:
>
> https://docs.taler.net/core/api-exchange.html#get--deposits-$H_WIRE-$MERCHANT_PUB-$H_CONTRACT_TERMS-$COIN_PUB
>
> We could easily add a HTTP "Failed Dependency" status code to the API
> here and define a message format to indicate details about the problem
> to the merchant (and prescribe resolution strategies).
>
> This would mostly require another taler-exchange-XXX process to _query_
> LibEuFin for R-transactions, *and* a change to the exchange DB schema.
> More messy: this will require additional changes to the merchant
> backend. Please file a bug on this on Mantis, but I think we should
> target Taler v1.5 for this, given the scope of the changes and need for
> testing -- and the hopefully reasonably low likelihood of occurrence. At
> least I think we should be fine to manually handle the first generation
> of complaints for R-transactions, and that might even be better than
> trying to automate a process where we may not fully understand all the
> ways these things fail in practice.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016388)
Christian Grothoff   
2020-07-06 11:00   
Some status information is now provided ('wired'), alas automatically querying LibEuFin for transactions as _merchant_ is missing: right now, the merchant has to manually POST incoming transactions to the backend.

Writing a taler-merchant-wirewatch tool should be done, but later.
(0017804)
Christian Grothoff   
2021-05-09 13:48   
DD13 will include the required wire API changes (as we need to change the wire API for DD13 anyway).
(0017805)
Christian Grothoff   
2021-05-09 19:45   
Discussed with Florian: wire API should NOT be used for this, but a separate libEuFin facade created.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6911 [GNUnet] documentation text N/A 2021-06-28 23:45 2021-07-05 09:50
Reporter: gmacedo Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version: 0.15.0  
Summary: Fix wrong links syntax - broken link
Description: Fix broken links to maintainers' personal websites that were written with the wrong syntax.
Tags: documentation
Steps To Reproduce: 1. Go to "1.4 Project governance" section in the reference manual - https://docs.gnunet.org/handbook/gnunet.html#Project-governance.
2. Try to access the link each maintainers' personal website.
3. The links are broken, pointing to an internal link in the page, instead of each correct website.
Additional Information: Patch to fix:

---
diff --git a/doc/handbook/chapters/preface.texi b/doc/handbook/chapters/preface.texi
index d1afdf756..961ec0737 100644
--- a/doc/handbook/chapters/preface.texi
+++ b/doc/handbook/chapters/preface.texi
@@ -185,8 +185,8 @@ The current maintainers of GNUnet are:
 
 @itemize @bullet
 
-@item @uref{Christian Grothoff, https://grothoff.org/christian/}
-@item @uref{Martin Schanzenbach, https://schanzen.eu}
+@item @uref{https://grothoff.org/christian/, Christian Grothoff}
+@item @uref{https://schanzen.eu, Martin Schanzenbach}
 
 @end itemize
 
---
Attached Files:
Notes
(0017983)
schanzen   
2021-07-05 09:49   
Fixed in 56af99b50..7799411a8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6913 [GNUnet] util library crash always 2021-07-04 11:49 2021-07-05 09:47
Reporter: gmacedo Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.14.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: Git master  
    Target Version: 0.15.0  
Summary: Segmentation fault while writing full config with gnunet-config
Description: gnunet-config will segfault when trying to write the full configuration file.

# gnunet-config -F
Segmentation fault
Tags: bug
Steps To Reproduce: Execute `gnunet-config -F`
Additional Information: GNUnet version:

# gnunet-config -v
gnunet-config v0.14.1 git-2a1a812f3
Attached Files:
Notes
(0017981)
gmacedo   
2021-07-04 17:03   
Please let me know if there is any info that I can send to help debugging.
(0017982)
schanzen   
2021-07-05 09:46   
Fixed in b102545f6..56af99b50


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5775 [Taler] wallet (TS core) minor have not tried 2019-06-25 14:55 2021-06-22 15:36
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: test weird corner cases regarding the exchange's /keys info
Description: For example:
- two exchanges claiming to have the same master public key
- exchanges that change their master public key
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


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

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


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

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

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

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

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

Then, type-specific key-value pairs where:

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


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

taler-check-proof FILENAME.json

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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6907 [Taler] wallet (WebExtensions) minor have not tried 2021-06-22 13:14 2021-06-22 13:14
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: operations should support cancellation tokens
Description: The wallet implementation currently doesn't handle cancellation and timeouts nicely. Most operations should take a cancellation token and pass that to other operations that are invoked.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6905 [Taler] wallet (TS core) minor have not tried 2021-06-16 13:13 2021-06-16 13:13
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: wallet benchmarking needed
Description: It's currently not really clear at all where the wallet-core is slow --- we need more benchmarking.
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:
6902 [GNUnet] set service feature always 2021-06-15 20:20 2021-06-15 20:20
Reporter: elias 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: SETU: Add SHA-512 final checksum to full_done and done message
Description: As described in the RFC: A SHA-512 of the complete set (every element) should be added to the done/full_done message. Additionally a check should be introduced that compares the received checksum in done/full_done message with the hash of the local set.
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:
5059 [Taler] wallet (TS core) minor have not tried 2017-06-04 17:47 2021-06-15 19:05
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: handle cases where an exchange's key changes, but the base URL stays the same
Description: Currently the wallet gets confused by this and may refuse some operations until you reset the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017954)
Florian Dold   
2021-06-15 19:05   
This is implemented now, but needs a test case.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4615 [GNUnet] other feature N/A 2016-08-10 23:24 2021-06-15 13:37
Reporter: lynX Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
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:
6505 [Taler] wallet (TS core) text have not tried 2020-08-21 17:50 2021-06-15 10:54
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: define UX and API for "global errors/notifications"
Description: Global errors/notifications are events that need user attention and/or that aren't displayed in a transaction list item.

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

To prevent spammy notifications / thrashing, every global error/notification should get some ID based on the type of the problem and the underlying resource.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6708 [Taler] wallet (WebExtensions) minor have not tried 2021-01-18 23:43 2021-06-14 11:51
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: implement UI for wallet deposits (WebExtension)
Description: See 0006707, but for the WebExtension 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:
6102 [GNUnet] resolver service feature always 2020-02-19 13:25 2021-06-10 23:01
Reporter: schanzen Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Resolver limited to IP addresses
Description: The RESOLVER service (and API) is limited to IP addressed. This should be extended to all DNS records.
This also affects LSD001, as GNS2DNS and CNAME resolution is artificially limited to A/AAAA.
Tags: lsd0001
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:
6743 [GNUnet] file-sharing service feature have not tried 2021-02-06 18:11 2021-06-10 23:01
Reporter: cy1 Platform: Gentoo  
Assigned To: schanzen OS: Linux  
Priority: low OS Version: 5.9.1  
Status: feedback Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: anonymous structs in GNUNET_FS_ProgressInfo impede modularity
Description: I'd like to write myself a dispatcher that delegates to various dispatchers in different modules for each operation, like:

```
static void* progress_cb (void *cls,
                          const struct GNUNET_FS_ProgressInfo *info) {
    switch(info->status) {
    case GNUNET_FS_STATUS_SEARCH_RESULT:
              return search_progress(info->value.search);
        case GNUNET_FS_DOWNLOAD_PROGRESS:
              return download_progress(info->value.download);
        ...
        };
}
```

But since info->value.search is an anonymous struct, there is no way to write the function signature for search_progress, or download_progress, outside of using typeof like:

```
const struct GNUNET_FS_ProgressInfo dummyvariable __attribute__((__unused__));
void* search_progress(const typeof(dummyvariable.value.search) info);
```

I would appreciate it if each of the members of that union could be given names, however ludicrously verbose, so that I could write:

```
void* search_progress(GNUNET_FS_ProgressInfoSearch info);
```

Once I know it's a search event, there's no reason to access value.download or value.publish, so it just prevents me from removing verbosity, and introduces potential for interface boundary failures such as accidentally using code which accesses value.download in a search dispatcher. Anyway it's just a little nitpick I wanted to get reported so that someone with commit access could patch it whenever they get around to it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: named_progress_values.bundle (1,047 bytes) 2021-02-06 18:11
https://bugs.gnunet.org/file_download.php?file_id=1030&type=bug
Notes
(0017558)
schanzen   
2021-02-21 10:55   
Can you check 8095b1a1b..a3971a93c if that is what you need?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6870 [GNUnet] transport service minor have not tried 2021-05-17 10:33 2021-06-10 19:36
Reporter: schanzen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: [TNG] UDP Communicator should tell TNG service of outgoing queue on packet receipt
Description: Currently, the UDP communicator tells the service of outgoing queues whenever we connect to an ip/port given a hello.
The communicator then tries to verify this connection through a key exchange.

The receiver, upon receiving a KX, tries to send an answer back via the TNG service. (Backchannel)
Before doing that, the receiver should tell the TNG service of the outgoing queue to the endpoint from which we just received
the KX.

Currently, this is not done and this results in a situation where if the receiver does not have any other connections, it will never
send an answer to the KX.

Basically, we should treat the incoming packet like a connection request from the TNG service, providing unverified queues for
use in a virtual link.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6555 [GNUnet] core service minor always 2020-09-02 09:13 2021-06-10 19:36
Reporter: mateusz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after...
Description: git master gnunet is flooding my logs (and filling hard disk) with LOTS of such entries:

Aug 31 10:05:03-185017 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185026 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185033 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185050 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185071 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185092 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185104 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185111 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185118 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185125 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185132 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185139 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185183 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185193 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185336 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185362 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185375 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185387 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185398 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185409 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Aug 31 10:05:03-185421 util-service-26086 WARNING Processing code for message of type 367 did not call `GNUNET_SERVICE_client_continue' after 42 h
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016874)
schanzen   
2020-09-05 17:50   
Seems to be a transport issue. Have not seen this before myself.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6433 [GNUnet] TCP transport feature N/A 2020-07-17 12:05 2021-06-10 19:36
Reporter: t3sserakt 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: 0.16.0  
Summary: Writing a test to simulate an attack on the tcp communicator KX to test the replay protection.
Description: There is a replay protection for the tcp communicator implemented using a nonce send together with the ephemeral key. If the nonce is not send back the queue will be destroyed. To test this there has to be a peer not sending back the nonce within the defined limits. One possible way to do this is to build a variant of the tcp communicator to be used for the second peer in the communicator test. This second build changes some parts of the communicator code to send a wrong challenge or none at all.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6098 [GNUnet] UDP transport minor have not tried 2020-02-18 21:12 2021-06-10 19:36
Reporter: schanzen Platform:  
Assigned To: t3sserakt OS:  
Priority: normal OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: [TNG] UDP communicator performance issues
Description: The UDP communicator is very slow.
Example:
* Short size packet test done.
* 5000/5000 packets in 72041828 us (8 KiB/s) -- avg latency: 2518451 us

Looking at the code it is very inefficient wrt packet buffering and encryption.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6011 [GNUnet] UNIX transport minor always 2019-12-25 14:03 2021-06-10 19:36
Reporter: schanzen 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.16.0  
Summary: [TNG] UNIX communicator performance issues
Description: A trained eye might notice the absolutely unacceptable, abysmal performance of this
communicator considering it is using UDS (we should expect ~XGB/s!).
As it is not meant to be used productively (and can't really) this is not a blocker, but
still something worth investigating. I do not know if this was also the case for the old
plugin
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015222)
schanzen   
2019-12-26 06:20   
This is also an issue for the TCP communicator. Maybe this is a general issue with MQ or TNG api.
(0015223)
schanzen   
2019-12-26 20:54   
We now also have a UDP communicator which does no flow control (additional messages with (mock)transport).
It is now likely clear that something is wrong with the MQ (in general?).
(0015347)
schanzen   
2020-02-11 17:51   
For reference, current numbers:

* Size packet test done.
* 12798/12798 packets -- avg latency: 3148434 us
* Short size packet test done.
* 5000/5000 packets in 838528 us (745 KiB/s) -- avg latency: 409401 us
* Long size packet test done.
* 5000/5000 packets in 1717230 us (88 MiB/s) -- avg latency: 1034307 us
(0015377)
schanzen   
2020-02-18 17:13   
(Last edited: 2020-02-18 17:14)
In HEAD performance is now increased drastically (but still not optimal).

Unix: Short ~5MB/s Long: ~300MB/s
TCP: Short ~4MB/s Long: ~200MB/s

UDP is currently not functional. The packet send logic is very inefficient and the test always fails.

(0015378)
schanzen   
2020-02-18 17:15   
Note that the issue might actually be test design and lack of FC and not so much the communicator itself.


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

each accepting a respective IPv4/6 address

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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5886 [GNUnet] cadet service minor N/A 2019-09-09 18:10 2021-06-10 19:36
Reporter: buttfly Platform:  
Assigned To: t3sserakt OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
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:
Notes
(0017056)
schanzen   
2020-10-29 11:21   
Might make sense as we did a similar thing for GNS


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

What we need is a way to pre-populate PEERSTORE, so (1) logic to import data from some fixed location, and (2) to select (some) information stored in the local PEERSTORE and export it to then include it in the 'make dist' TGZ to be installed at that fixed location when GNUnet is installed.
Tags: tng
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0015745)
schanzen   
2020-04-23 10:49   
Fix for 0.13 or move to 0.14. Probably the former.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5710 [GNUnet] transport service feature N/A 2019-05-02 14:28 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: confirmed Product Version: 0.11.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.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: tng
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:
5650 [GNUnet] statistics service minor always 2019-03-16 17:55 2021-06-10 19:36
Reporter: ic.rbow 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.16.0  
Summary: Metrics collected by statistics lack canonical identifiers
Description: $ gnunet-statistics -s nse

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

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

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

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

instead of

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


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

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

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

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

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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5644 [GNUnet] transport service minor always 2019-03-13 10:27 2021-06-10 19:36
Reporter: ic.rbow Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 0.11.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Transport service spams warnings
Description: I'm getting my log files filled with almost exact duplicates of unactionable warnings:

...
Mar 13 09:20:49-997116 transport-27937 WARNING Calculated flow delay for UDPv6 at 3025 ms for 2YQA
Mar 13 09:20:50-006651 transport-27937 WARNING Calculated flow delay for UDPv6 at 3015 ms for 2YQA
Mar 13 09:20:50-018709 transport-27937 WARNING Calculated flow delay for UDPv6 at 3003 ms for 2YQA
Mar 13 09:20:50-019859 transport-27937 WARNING It took us 61 s to send 176/176 bytes to WEGY (1, tcp)
Mar 13 09:20:50-020478 transport-27937 WARNING It took us 61 s to send 176/0 bytes to WEGY (-1, tcp)
Mar 13 09:20:50-021069 transport-27937 WARNING It took us 61 s to send 32872/0 bytes to WEGY (-1, tcp)
...

There's a section in FAQ that says it's no big deal. So those are INFOs at best, maybe even DEBUG.
Tags: tng
Steps To Reproduce: Run a node with tcp and/or udp transport plugins.
Additional Information:
Attached Files:
Notes
(0014193)
nikita   
2019-03-14 02:22   
(Last edited: 2019-03-14 02:23)
What's the issue here? In other words, what do you think is wrong from your perspective, why, and what would be the fix/improvement you'd like to see.

(0014195)
ic.rbow   
2019-03-14 07:57   
Service logs are flooded with unimportant messages and I can't turn them off using another log level - without losing less frequent but potentially more important messages.

This makes following logs more difficult than necessary to monitor. Additionally this puts pressure on disk and network IO, storage and processing resources.
This is wrong because it gives no benefit over the "yes, we have latency issues until TNG comes" message in FAQ.

I would like to demote those two kinds of messages to DEBUG level unless there is another way to resolve this.
(0014196)
ic.rbow   
2019-03-14 08:08   
It may be well worth going through all the messages and reviewing their level. I think anything above WARNING should be an actionable message and ERRORs really should not be ignored by node operators.

GTK is notorious for having useless "warnings" spam, let's not follow that lead.


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5615 [GNUnet] Bluetooth transport feature have not tried 2019-02-27 20:29 2021-06-10 19:36
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Support platforms without bluez
Description: Our bluetooth service is only built if bluez is found.
Bluez is for the Linux kernel only.

It would be good to get support for other platforms which do not have the bluez.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014126)
nikita   
2019-03-03 10:26   
I think for the major BSD Operating Systems this is implemented in kernel.
I will try and gather information.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5603 [GNUnet] transport service minor have not tried 2019-02-23 01:48 2021-06-10 19:36
Reporter: nikita Platform: amd64  
Assigned To: OS: NetBSD  
Priority: normal OS Version: current  
Status: new Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: 4 transport tests fail
Description: FAIL:
test_transport_api_https
test_transport_api_reliability_https
test_transport_api_reliability_https_xhr
test_transport_api_slow_ats
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013956)
nikita   
2019-02-23 01:50   
(Last edited: 2019-02-23 01:58)
test-suite.log

edit: It turns out 24.9 MB is too big for mantis.

https://d.n0.is/pub/tmp/gnunet-transport-test-suite.log



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5552 [GNUnet] UDP transport feature N/A 2019-02-08 19:11 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: congestion control for UDP
Description: UDP currently does not rate-limit transmissions in the absence of ACKs. We should implement some sane rate limiting here. Some of it likely at the transport-level (for uni-directional communicators), and for incoming messages at least the KX/DH operations need to probably be limited per sender to a certain "fair" share.
Tags: tng
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 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: t3sserakt OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.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: tng
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:
5531 [GNUnet] TCP transport feature N/A 2019-01-28 19:26 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: support other TCP NAT traversal methods
Description: In particular those where third party facilitates (backchannel) and both peers send SYNs (possibly with low TTL) to traverse NATs on both ends. This will be complicated and require extensive testing and should only be done once backchannel suppot in TNG has been tested.
Tags: tng
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5529 [GNUnet] TCP transport feature have not tried 2019-01-28 19:21 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: TCP communicator does not support connection reversal yet
Description: For the autonomous NAT traversal method, TCP communicator still needs to implement the function for connection reversal. Shouldn't be too hard.
Tags: tng
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:
5507 [GNUnet] integration tests minor always 2019-01-12 01:38 2021-06-10 19:36
Reporter: Heiko Stamer Platform:  
Assigned To: OS: Debian GNU/Linux  
Priority: none OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: test_transport_api_manipulation_cfg fails
Description: FAIL: test_transport_api_manipulation_cfg
=========================================

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5482 [GNUnet] testbed service minor sometimes 2018-11-23 08:00 2021-06-10 19:36
Reporter: Heiko Stamer Platform:  
Assigned To: OS: Gentoo Linux  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Some CADET tests failed
Description: Unfortunately, now some CADET tests failed:

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

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

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

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


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5124 [GNUnet] transport service crash random 2017-08-21 23:20 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: segfault in send_with_session in transport service
Description: (gdb) ba
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f7a7364c42a in __GI_abort () at abort.c:89
#2 0x00007f7a73cd05e9 in GNUNET_abort_ () at common_logging.c:293
#3 0x0000555dead0b0f0 in send_with_session (n=0x555deced35a0, msgbuf=0x555decfe50c8, msgbuf_size=316, priority=0,
    timeout=..., use_keepalive_timeout=0, cont=0x555dead0c5d1 <transmit_send_continuation>, cont_cls=0x555decfe5090)
    at gnunet-service-transport_neighbours.c:857
#4 0x0000555dead0d117 in try_transmission_to_peer (n=0x555deced35a0) at gnunet-service-transport_neighbours.c:1406
#5 0x0000555dead12423 in master_task (cls=0x555deced35a0) at gnunet-service-transport_neighbours.c:2978
#6 0x00007f7a73d0d30e in run_ready (rs=0x555deccd3850, ws=0x555deccebe80) at scheduler.c:670
#7 0x00007f7a73d0dc59 in GNUNET_SCHEDULER_run (task=0x7f7a73d11516 <service_main>, task_cls=0x7ffdde04d2a0)
    at scheduler.c:937
#8 0x00007f7a73d16662 in GNUNET_SERVICE_run_ (argc=3, argv=0x7ffdde04d7a8, service_name=0x555dead1d814 "transport",
    options=GNUNET_SERVICE_OPTION_NONE, service_init_cb=0x555dead06989 <run>, connect_cb=0x555deacffadb <client_connect_cb>,
    disconnect_cb=0x555deacffd9f <client_disconnect_cb>, cls=0x0, handlers=0x7ffdde04d400) at service.c:1846
#9 0x0000555dead07553 in main (argc=3, argv=0x7ffdde04d7a8) at gnunet-service-transport.c:2878
Tags: tng
Steps To Reproduce: Ran a peer for a while, this _may_ have happened on shutdown.
Additional Information:
System Description
Attached Files:
Notes
(0012387)
Christian Grothoff   
2017-08-21 23:21   
UDP & TCP were enabled.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5102 [GNUnet] transport service crash have not tried 2017-07-02 17:26 2021-06-10 19:36
Reporter: L29Ah Platform: Linux  
Assigned To: OS: Gentoo  
Priority: normal OS Version:  
Status: acknowledged Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: execution attempt in: (null), 00000000-00000000 00000000
Description: #0 0x0000000000000000 in ?? ()
#1 0x000003475ab2b739 in recv_message (cls=0x678ac73d70, msg=<optimized out>) at client.c:315
#2 0x000003475ab53cbc in GNUNET_MST_from_buffer (mst=0x678ac73d00, buf=<optimized out>, buf@entry=0x0,
    size=<optimized out>, size@entry=0, purge=purge@entry=0, one_shot=one_shot@entry=0) at mst.c:232
#3 0x000003475ab54292 in GNUNET_MST_read (mst=<optimized out>, sock=<optimized out>, purge=purge@entry=0,
    one_shot=one_shot@entry=0) at mst.c:359
#4 0x000003475ab2c59a in receive_ready (cls=0x678ac73d70) at client.c:397
#5 0x000003475ab65c28 in run_ready (ws=0x678ac571f0, rs=0x678ac57160) at scheduler.c:670
#6 GNUNET_SCHEDULER_run (task=task@entry=0x3475ab6cb30 <service_main>, task_cls=task_cls@entry=0x3b090d42770)
    at scheduler.c:937
#7 0x000003475ab6ba7a in GNUNET_SERVICE_run_ (argc=<optimized out>, argv=0x3b090d42ce8,
    service_name=0x6789386e0a "transport", options=<optimized out>, service_init_cb=<optimized out>,
    connect_cb=<optimized out>, disconnect_cb=0x6789370cb0 <client_disconnect_cb>, cls=0x0, handlers=0x3b090d42ab0)
    at service.c:1845
#8 0x000000678936f9a6 in main (argc=<optimized out>, argv=<optimized out>) at gnunet-service-transport.c:2878
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013936)
catonano   
2019-02-22 07:20   
is this meant for 0.11 ?


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4038 [GNUnet] transport service block have not tried 2015-10-29 23:04 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: transport service leaks sockets
Description: I see hundreds of these, causing accept() to fail:

gnunet-se 26540 gnunet9 1018u unix 0xffff88103ee160c0 0t0 43811407 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
gnunet-se 26540 gnunet9 1019u unix 0xffff88103c366b40 0t0 43793331 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
gnunet-se 26540 gnunet9 1020u unix 0xffff88103c3664c0 0t0 43793332 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
gnunet-se 26540 gnunet9 1021u unix 0xffff880cebeba480 0t0 43793333 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
gnunet-se 26540 gnunet9 1022u unix 0xffff880cebebbb40 0t0 43793334 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
gnunet-se 26540 gnunet9 1023u unix 0xffff880dc49a0440 0t0 43793335 /tmp/gnunet-system-runtime//gnunet-service-transport.sock type=STREAM
Tags: tng
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0009857)
Christian Grothoff   
2015-10-29 23:13   
Ok, 'ss -x' suggests that these sockets are not connected to any other process :-(.
(0009860)
Christian Grothoff   
2015-10-30 00:36   
Ok, so it seems this is not something that simply happens 'over time': running a peer for a while doesn't show even 2 of those 'extra' connections. So most likely a very large number of them is created at the same time (i.e. due to some error with retries).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3951 [GNUnet] NAT traversal library feature N/A 2015-08-27 14:49 2021-06-10 19:36
Reporter: bratao Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Use STUN other_address to do our reversal test
Description: Actually we check our NAT type by issuing a request to STUN, than asking gnunet.org for a reversal.

Grothoff installed in gnunet.org a full mode STUN, that have two address. We should use the returned OTHER_ADDRESS to do this reversal.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

My 2 cents, comments welcome!

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

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

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

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

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

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

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

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

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

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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3867 [GNUnet] WLAN transport feature N/A 2015-06-27 02:41 2021-06-10 19:36
Reporter: dangole Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Fast WiFi transport / setup-helper should be implemented
Description: The current WLAN transport is limited to very low data rates and cannot make use of modern hardware features like MIMO or aggregation.

One way to achieve more throughput and easy peering could be via WiFi-Direct aka. P2P.

For that, a to-be-implemented helper needs to connect to wpa_supplicant via it's control interface and make use of the P2P_* API and pass-on information about WiFi-P2P connections/peers.

On some OS, access to the wpa_supplicant control socket is limited. However, it may be possible to have the OS network management pass-through or allow indirect access of the P2P API.

On yet other platforms, P2P is highly integrated with mDNS service announcement/discovery...

An alternative to using wpa_supplicants's P2P API could be using IBSS/Ad-Hoc mode or even 802.11s with pre-defined parameters, which is merely a matter of documentation and having some sort of broadcast/multicast peer discovery (see 0003866)
Tags: tng
Steps To Reproduce:
Additional Information: wpa_supplicant's API at
http://w1.fi/wpa_supplicant/devel/ctrl_iface_page.html

Related to
https://gnunet.org/bugs/view.php?id=3866
Attached Files:
Notes
(0009351)
Christian Grothoff   
2015-06-27 16:47   
Sounds nice, are you planning/willing to help with this?
(0009354)
dangole   
2015-06-27 17:52   
Directly using wpa_supplicant's control socket seems to be the way.

Code example:
http://cgit.freedesktop.org/~dvdhrm/miracle/tree/src/wifi

Note that there may be several instances of wpa_supplicant running on a system. On some (proprietary) platforms, p2p_supplicant and wpa_supplicant each provide individual sockets. A gnunet-wpa_supplicant-helper should thus glob for available control sockets and connect to ALL of them and probe their P2P capabilities. It should announce the gnunet service and periodically scan for other p2p peers using all P2P-capable supplicants. If peers are found, it should setup a P2P connection, a deterministic order e.g. over some least-significant-bits of the peers pubkeys can decide which role (GO or client) to setup on each side. If IPv6 link-local addressing is enough for GNUnet's UDP transport to work, the resulting P2P interface should be usable for plugin_transport_udp_broadcasting.

Related discussions:
https://bugzilla.gnome.org/show_bug.cgi?id=734073

https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html
(0012055)
dangole   
2017-04-21 20:53   
My perspective on this issue has suddenly changed due to
http://ml.ninux.org/pipermail/battlemesh/2017-April/005445.html
and the realization that support for injecting frames at arbitary legacy, MCS and VHT bitrates has been (re-)added to mac80211 on Linux about a year ago.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3866 [GNUnet] transport service feature N/A 2015-06-27 02:17 2021-06-10 19:36
Reporter: dangole Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: local peer discovery should be implemented
Description: Ideally by announcing and querying using different mDNS backends like bonjour/apple?, android?/binder, avahi/dbus, mdns/ubus, ...
Another way might be to use UDPv6 link-local multicast directly on-top of Ethernet-like media.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0009352)
Christian Grothoff   
2015-06-27 16:48   
We do use UPDv6 multicast, and UDPv4 broadcast for local discovery already.
(0009353)
dangole   
2015-06-27 17:39   
I see, looking at the code it seems sufficient.
It would be nice to allow configuring the specific interface to use for multicast/broadcast as well as adding/removing interfaces during runtime.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3714 [GNUnet] transport service major have not tried 2015-03-16 10:04 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: memory leaks in transport service
Description: Just found a 17 GB transport service process (tcp + udp loaded) on my system this morning (after several days of running). So there is still a problem...
Tags: tng
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:
3651 [GNUnet] transport service feature always 2015-02-05 01:47 2021-06-10 19:36
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: test_transport_address_switch testcases fail if no switching happens
Description: With the latest code, it is possible that while ATS 'tries' a switch, transport notices 'trouble' with the new address, tells ATS that the new address is 'bad' and sticks to the 'old' address. As a result, the connection is maintained with the original address throughout the testcase, causing it to fail. As the testcase fails to provoke a situation where an address switch should actually happen *for sure*, this is largely the testcases fault.

The reason why the address switch fails is another issue (will be reported separately).
Tags: tng
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0008848)
Christian Grothoff   
2015-02-09 17:07   
I've changed the tests in SVN 35200 to then not fail, but as such they are then simply not testing what they are supposed to test. But that's a bug with the test. IMO we should use blacklisting or preferences/priorities to make the switch happen.
(0008943)
Christian Grothoff   
2015-02-28 18:27   
Changing severity to 'feature', as this is now just a test that doesn't test something properly.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3346 [GNUnet] NAT traversal library feature have not tried 2014-03-24 11:46 2021-06-10 19:36
Reporter: Matthias Wachs Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: NAT functionionality and interaction with transport service has to be tested
Description: We must validate and test the NAT functionality and interaction with transport service.

It is reported that configuring a peer behind nat and nat punching does not work correctly.

Testing the tranport configuration fails (which executes a NAT test) and error messages occur when a peer is running...
Tags: tng
Steps To Reproduce:  [transport]
 PLUGINS = tcp udp

 [transport-tcp]
 PORT = 2086
 ADVERTISED_PORT = 0

 [transport-udp]
 PORT = 2086
 ADVERTISED_PORT = 0

 [nat]
 BEHIND_NAT = YES
 PUNCHED_NAT = YES
 DISABLEV6 = YES
 INTERNAL_ADDRESS = 10.0.1.1
 EXTERNAL_ADDRESS = <a_host>.<tld>

Additional Information:
Attached Files:
Notes
(0015379)
mildred   
2020-02-18 22:36   
I have the impression that the NAT code changed quite a bit since this issue was written. PUNCHED_NAT for instance belongs to nat-auto (and not nat).
(0015386)
schanzen   
2020-02-19 13:30   
This is likely an issue which will be addressed in TNG in some way. So it will not be addressed directly, but closed when TNG has this feature (and tests)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3309 [GNUnet] core service feature N/A 2014-02-07 14:59 2021-06-10 19:36
Reporter: Bart Polot Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: Core needs to indicate a peer's willingness to accept traffic for other peers.
Description: Core should have 3 tiers of peers:
- Backbone peers: computers with good connectivity and no power limitations that are willing to route traffic for other peers.
- Limited peers: computers with either connnectivity limitations (NAT, Dial-up, Slow wireless, etc.) or power limitations (battery operated). Are willing to route traffic for other only if there is no backbone peer available to do so (due to wireless range, for instance).
- Restriced peers: computers/devices that are not willing to route traffic for others under any circumstance (for instance, smartphone using GSM while on roaming in a different country).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2628 [GNUnet] NAT traversal library feature N/A 2012-11-07 10:01 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 0.9.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: network autoconfiguration code should be improved and moved into libgnunetnat
Description: gnunet-setup now has some autoconfiguration code (-a option) to detect the network configuration and generate a 'reasonable' configuration automatically. Instead of having this logic live in gnunet-gtk/, it should live in libgnunetnat with a reasonable API. Additionally, we should have a command-line tool in gnunet/ to create a good configuration (instead of only having gnunet-setup -a; in fact, maybe then we can get rid of the -a option to gnunet-setup). Finally, the existing autoconfiguration can likely be improved (however, specific issues should be added as separate bugs).
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006715)
Christian Grothoff   
2012-12-15 15:32   
The code was moved to src/nat/nat-auto.c; but it is still incomplete, should be augmented with a command-line tool to call it --- and we need testcases (and the NAT testbed...).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1941 [GNUnet] WLAN transport feature N/A 2011-11-22 20:08 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: WLAN should report performance metrics to ATS
Description: This is with the caveat that the information may not be easily available/accessible. But on devices with limited battery, it would certainly make sense for ATS to be aware of power consumption.

Alternatively, WLAN should at least report issues such as retransmission (fragmentation/ACKs) so that ATS can see that a particular peer has bad receiption.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1937 [GNUnet] transport service feature N/A 2011-11-22 20:01 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: plugins must queue multiple messages
Description: The 'TransmitFunction' in the current API requires plugins to have "unbounded" queue (or at least queue of size > 2); it might be better to have at MOST one message pending per plugin/target and only send the next one after the continuation was called (or use 'notify_transmit_ready-style API?). Having queues *again* implemented in each plugin is simply ugly.
Tags: tng
Steps To Reproduce:
Additional Information: HTTP/S implements DLL
Attached Files:
Notes
(0005762)
Matthias Wachs   
2012-05-02 10:45   
(Last edited: 2012-05-02 10:45)
I checked all transport plugins ... All of them use a DLL to store an unlimited number of messages.

A "'notify_transmit_ready-style API" is a major change to all plugins what can cause a lot of new bugs... ?

(0005763)
Christian Grothoff   
2012-05-02 11:01   
Well, that's why it is a low-priority issue. However, the point is that by eliminating the need to queue messages in each plugin, we avoid several problems:

* possibly unbounded queues (out-of-memory and other badness)
* functional duplication among plugins
  (queues managed fully by transport service => simpler plugins => fewer bugs)
* easier to write new plugins
* reduced buffer bloat

In any case, there is a reason why this issue was not scheduled for 0.9.3.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1936 [GNUnet] DV service or transport feature N/A 2011-11-22 20:00 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: need performance test for DV
Description: We should have a way to benchmark DV's performance to ensure that the service is as fast as expected when routing traffic.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1935 [GNUnet] DV service or transport feature N/A 2011-11-22 19:59 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: DV's bandwidth allocation is not really working as-is
Description: We are unable to properly account for the "indirect" traffic usage (we should somehow map the priority of the indirect traffic to allocations for the direct links -- this will need integration with ATS).

Furthermore, the bandwidth used by DV for indirection of traffic for other peers should be allocated based on some kind of tit-for-tat mechanism that considers how much those other peers route for us.

APIs (including ATS/plugin/transport) and the exact resource allocation algorithm (including division of work between DV and ATS) still need to be worked out here.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1934 [GNUnet] transport service feature N/A 2011-11-22 19:56 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: transport's code to probe latency and switch transports needs refinement & testing
Description: We need to periodically probe latency/transport cost changes and possibly switch the address transport uses for a connection; this naturally then needs to be tested (also with ATS).

The frequency for address probes should be determined by limiting the fraction of bandwidth used for probes, resulting in more probes on powerful peers and fewer probes if we know lots of addresses. Also, maybe the frequency of probing alternative peer's addresses that we are currently connected to should be slightly higher.
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1923 [GNUnet] SMTP transport feature N/A 2011-11-22 13:21 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: SMTP transport plugin should be (re-)implemented
Description: We need to do:
- sending (SMTP/SMTPS)
- receiving (IMAP/IMAPS/POP?)
- rate limiting
- improved batching
- resource limit integration with ATS
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1795 [GNUnet] DV service or transport feature always 2011-09-19 11:55 2021-06-10 19:36
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.16.0  
Summary: DV is not implemented
Description: Tests crash reliabily right now. DV was removed from buildbots and marked as experimental in the build. DV should be fixed to not crash... (did we change that much in the plugin API!?).
Tags: tng
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006987)
Christian Grothoff   
2013-03-18 12:56   
Code is mostly there; what is missing:
1) get proper distances to other peers from ATS/transport/core API
2) need ability to blacklist individual TCP-connection between some
   peers to force DV in the testcase
3) consensus service has problems (needs to be fixed first)
(0007146)
Christian Grothoff   
2013-06-03 13:10   
DV implementation is now finished (using SET API instead of consensus); however, the code is untested and SET still needs to migrate to mesh (as it currently uses stream which then causes assertion failures).
(0007222)
Christian Grothoff   
2013-07-10 14:44   
Set is now ready. Time to test DV...
(0007544)
Christian Grothoff   
2013-10-20 20:27   
Matthias: did you and Sree make any progress on the testing issue for DV?
(0007545)
Christian Grothoff   
2013-10-20 20:28   
Reminder sent to: Matthias Wachs, Sree Harsha Totakura
Did you make any progress on this yet?
(0007549)
Sree Harsha Totakura   
2013-10-20 22:04   
I remember testing DV testcases with Matthias sometime ago. AFAIR, the failing DV testcase due to testbed timing out is fixed by reducing the per-operation timeout and observing the number of failed overlay connections. The overlay topology is again retried after sometime and this time it succeeds due to DV propagation.
(0007550)
Christian Grothoff   
2013-10-21 11:56   
Well, right now the tests fail. With SVN HEAD, "CACHE_SIZE = 0" in template_dv.conf results in testbed crashing on assertion failure (because cache is NULL as the hash map is not initialized with a size of zero).

If I set CACHE_SIZE to 1 instead, I get (instantly):
$ ./test_transport_blacklist
Oct 21 11:54:03-356461 test-transport-blacklist-2067 ERROR Testbed connect peers despite blacklist!
grothoff@pixel:~/svn/gnunet/src/dv$ ./test_transport_dv
Testbed connected peers, should not happen...
Oct 21 11:54:12-698630 mesh-2168 ERROR Assertion failed at gnunet-service-mesh.c:3498.
Oct 21 11:54:12-698705 mesh-2168 ERROR type GNUNET_MESSAGE_TYPE_MESH_CONNECTION_ACK unknown!
Oct 21 11:54:12-698741 mesh-2168 ERROR Assertion failed at gnunet-service-mesh.c:3090.
Oct 21 11:54:12-700561 set-2166 ERROR Assertion failed at gnunet-service-set.c:369.
(0007578)
Sree Harsha Totakura   
2013-10-29 10:46   
I fixed the bug in testbed which causes it to crash when CACHE_SIZE is set to 0. The DV testcases however do not pass.
(0007624)
Matthias Wachs   
2013-11-12 14:20   
(Last edited: 2013-11-12 14:55)
Blacklist IDs updated -> ./test_transport_blacklist passes
-> transport blacklisting for tcp connections works

Analyzing dv service:
- Peers connect on CORE level
- SET transmission is done
- SETs are exchanged correctly

- The SETs seem to be empty?

(0007625)
Matthias Wachs   
2013-11-12 15:44   
My analysis:

The consensus sets exchanged between peers are empty, because direct connected peers are never added to the consensus set.


Routes for direct neigbours are added for a neighbour:

- Direct neighbour is created in core_connect
- handle_ats_update sets distance to 1 and tries to refresh routes...

But routes are never added:

In handle_ats_update -> refresh_routes:
  if (NULL != neighbor->neighbor_table)
  {

    GNUNET_CONTAINER_multipeermap_iterate (neighbor->neighbor_table,
                                           &check_possible_route,
                                           neighbor);
  }


neighbor->neighbor_table is never created and never populated!
(0007680)
Matthias Wachs   
2013-11-25 15:34   
Added direct connections to consensus set ...
ATM SETs are not exchanged ... SET tests fail seems to be a set problem...
(0007689)
Matthias Wachs   
2013-11-26 10:46   
Analysis peers do not exchange sets:

6DER initiate with G3FJ
6DER initiate with 6ULB
6DER initiate with DJ5S

G3FJ listens to 6DER
G3FJ listens to 6ULB

6ULB initiate with G3FJ
6ULB initiate with DJ5S
6ULB listens to 6DER

DJ5S listens to 6DER
DJ5S listens to 6ULB

Not established
# DJ5S - G3FJ


-- Nov 26 10:31:42-661563 dv-2431 DEBUG I am peer: 6DER
Nov 26 10:31:42-908563 dv-2431 DEBUG Initiating SET union with peer `G3FJ'
Nov 26 10:31:42-920771 dv-2431 DEBUG Finished building my SET for peer `G3FJ' with 0 elements, committing

Nov 26 10:31:42-933992 dv-2431 DEBUG Adding direct route to 6ULB

Nov 26 10:31:42-946805 dv-2431 DEBUG Initiating SET union with peer `6ULB'
Nov 26 10:31:42-948181 dv-2431 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:31:42-950916 dv-2431 DEBUG Finished building my SET for peer `6ULB' with 1 elements, committing

Nov 26 10:31:42-951765 dv-2431 DEBUG Adding direct route to DJ5S

Nov 26 10:31:42-963605 dv-2431 DEBUG Initiating SET union with peer `DJ5S'
Nov 26 10:31:42-964156 dv-2431 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:31:42-964706 dv-2431 DEBUG Adding peer `6ULB' with distance 1 to SET
Nov 26 10:31:42-965152 dv-2431 DEBUG Finished building my SET for peer `DJ5S' with 2 elements, committing

-- Nov 26 10:31:42-691340 dv-2441 DEBUG I am peer: DJ5S

Nov 26 10:31:43-021856 dv-2441 DEBUG Starting SET listen operation with peer `6DER'
Nov 26 10:31:43-069040 dv-2441 DEBUG Starting SET listen operation with peer `6ULB'

-- Nov 26 10:31:42-721183 dv-2437 DEBUG I am peer: 6ULB

Nov 26 10:31:42-971826 dv-2437 DEBUG Initiating SET union with peer `G3FJ'
Nov 26 10:31:42-984021 dv-2437 DEBUG Finished building my SET for peer `G3FJ' with 0 elements, committing

Nov 26 10:31:43-032581 dv-2437 DEBUG Initiating SET union with peer `DJ5S'
Nov 26 10:31:43-033904 dv-2437 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:31:43-036799 dv-2437 DEBUG Adding peer `6DER' with distance 1 to SET
Nov 26 10:31:43-037532 dv-2437 DEBUG Finished building my SET for peer `DJ5S' with 2 elements, committing

Nov 26 10:31:43-011622 dv-2437 DEBUG Starting SET listen operation with peer `6DER'

-- Nov 26 10:31:42-735928 dv-2427 DEBUG I am peer: G3FJ
Nov 26 10:31:43-076361 dv-2427 DEBUG Starting SET listen operation with peer `6DER'
Nov 26 10:31:43-114702 dv-2427 DEBUG Starting SET listen operation with peer `6ULB'
(0007690)
Matthias Wachs   
2013-11-26 10:50   
(Last edited: 2013-11-26 10:50)
Output with DV and SET on debug:

mwachs@fulcrum:~/coding/gnunet/src/dv$ ./test_transport_dv
Nov 26 10:48:57-307802 test-transport-dv-4387 DEBUG Starting HELPER process `/home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-helper-testbed'
Nov 26 10:48:57-308625 test-transport-dv-4387 DEBUG Transmitted 3552 bytes to /home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-helper-testbed
Nov 26 10:48:57-314904 test-transport-dv-4387 DEBUG Got 3647 bytes from helper `/home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-helper-testbed'
Nov 26 10:48:57-386462 dv-api-4413 DEBUG Connecting to DV service
Nov 26 10:48:57-386462 dv-api-4411 DEBUG Connecting to DV service
Nov 26 10:48:57-386724 dv-api-4412 DEBUG Connecting to DV service
Nov 26 10:48:57-394499 dv-api-4417 DEBUG Connecting to DV service
==4423== Memcheck, a memory error detector
==4423== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4423== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4423== Command: /home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-service-dv -c /tmp/testbed7LspHu/2/config
==4423==
==4422== Memcheck, a memory error detector
==4422== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4422== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4422== Command: /home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-service-dv -c /tmp/testbed7LspHu/0/config
==4422==
==4421== Memcheck, a memory error detector
==4421== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4421== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4421== Command: /home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-service-dv -c /tmp/testbed7LspHu/1/config
==4421==
==4435== Memcheck, a memory error detector
==4435== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4435== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4435== Command: /home/mwachs/coding/gnb/lib/gnunet/libexec/gnunet-service-dv -c /tmp/testbed7LspHu/3/config
==4435==
Nov 26 10:48:58-776848 dv-4421 DEBUG I am peer: 6ULB
Nov 26 10:48:58-852755 dv-4421 DEBUG Core connected to G3FJ (distance unknown)
Nov 26 10:48:58-855182 dv-4421 DEBUG Core connected to DJ5S (distance unknown)
Nov 26 10:48:58-858854 dv-4421 DEBUG Direct connection to G3FJ established, routing table exchange begins.
Nov 26 10:48:58-870211 dv-4421 DEBUG Adding direct route to G3FJ
Nov 26 10:48:58-850489 dv-4435 DEBUG I am peer: G3FJ
Nov 26 10:48:58-853510 dv-4423 DEBUG I am peer: DJ5S
Nov 26 10:48:58-927197 dv-4435 DEBUG Core connected to 6ULB (distance unknown)
Nov 26 10:48:58-929891 dv-4435 DEBUG Core connected to 6DER (distance unknown)
Nov 26 10:48:58-931190 dv-4423 DEBUG Core connected to 6ULB (distance unknown)
Nov 26 10:48:58-933679 dv-4435 DEBUG Direct connection to 6DER established, routing table exchange begins.
Nov 26 10:48:58-934599 dv-4423 DEBUG Core connected to 6DER (distance unknown)
Nov 26 10:48:58-939355 dv-4423 DEBUG Direct connection to 6DER established, routing table exchange begins.
Nov 26 10:48:58-944680 dv-4435 DEBUG Adding direct route to 6DER
Nov 26 10:48:58-950385 dv-4423 DEBUG Adding direct route to 6DER
Nov 26 10:48:58-949586 dv-4422 DEBUG I am peer: 6DER
Nov 26 10:48:59-023968 dv-4421 DEBUG Initiating SET union with peer `G3FJ'
Nov 26 10:48:59-026331 dv-4422 DEBUG Core connected to G3FJ (distance unknown)
Nov 26 10:48:59-028926 set-api-4421 DEBUG set client created
Nov 26 10:48:59-029731 dv-4422 DEBUG Core connected to 6ULB (distance unknown)
Nov 26 10:48:59-030789 dv-4422 DEBUG Core connected to DJ5S (distance unknown)
Nov 26 10:48:59-032974 set-4440 INFO started
Nov 26 10:48:59-034588 dv-4422 DEBUG Direct connection to G3FJ established, routing table exchange begins.
Nov 26 10:48:59-040989 dv-4421 DEBUG Finished building my SET for peer `G3FJ' with 0 elements, committing
Nov 26 10:48:59-047848 dv-4422 DEBUG Adding direct route to G3FJ
Nov 26 10:48:59-052586 set-4440 DEBUG client created new set (operation 2)
Nov 26 10:48:59-052634 set-4440 DEBUG union set created
Nov 26 10:48:59-052863 dv-4421 DEBUG Core connected to 6DER (distance unknown)
Nov 26 10:48:59-056242 set-4440 DEBUG evaluating union operation
Nov 26 10:48:59-056294 set-4440 DEBUG sent op request without context message
Nov 26 10:48:59-056858 dv-4421 DEBUG Direct connection to 6DER established, routing table exchange begins.
Nov 26 10:48:59-057465 dv-4421 DEBUG Adding direct route to 6DER
Nov 26 10:48:59-070346 dv-4421 DEBUG Starting SET listen operation with peer `6DER'
Nov 26 10:48:59-074112 set-4440 DEBUG new listener created (op 2, app 4IUT9PIE)
Nov 26 10:48:59-074150 set-4440 DEBUG considered all incoming requests
Nov 26 10:48:59-074403 dv-4421 DEBUG Direct connection to DJ5S established, routing table exchange begins.
Nov 26 10:48:59-074627 dv-4421 DEBUG Adding direct route to DJ5S
Nov 26 10:48:59-092883 dv-4421 DEBUG Initiating SET union with peer `DJ5S'
Nov 26 10:48:59-093660 set-api-4421 DEBUG set client created
Nov 26 10:48:59-094886 dv-4421 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:48:59-097015 set-4440 DEBUG client created new set (operation 2)
Nov 26 10:48:59-097056 set-4440 DEBUG union set created
Nov 26 10:48:59-097254 set-4440 DEBUG client ins/rem element of size 36
Nov 26 10:48:59-096526 dv-4435 DEBUG Starting SET listen operation with peer `6DER'
Nov 26 10:48:59-097641 dv-4421 DEBUG Adding peer `6DER' with distance 1 to SET
Nov 26 10:48:59-097883 set-4440 DEBUG client ins/rem element of size 36
Nov 26 10:48:59-098118 dv-4421 DEBUG Finished building my SET for peer `DJ5S' with 2 elements, committing
Nov 26 10:48:59-098471 set-4440 DEBUG evaluating union operation
Nov 26 10:48:59-098505 set-4440 DEBUG sent op request without context message
Nov 26 10:48:59-106663 set-4444 INFO started
Nov 26 10:48:59-107176 dv-4423 DEBUG Starting SET listen operation with peer `6DER'
Nov 26 10:48:59-115811 set-4446 INFO started
Nov 26 10:48:59-116599 set-4444 DEBUG new listener created (op 2, app A35H9N4K)
Nov 26 10:48:59-116632 set-4444 DEBUG considered all incoming requests
Nov 26 10:48:59-118205 dv-4435 DEBUG Direct connection to 6ULB established, routing table exchange begins.
Nov 26 10:48:59-119602 dv-4435 DEBUG Adding direct route to 6ULB
Nov 26 10:48:59-128571 set-4446 DEBUG new listener created (op 2, app 46Q0EAUB)
Nov 26 10:48:59-128617 set-4446 DEBUG considered all incoming requests
Nov 26 10:48:59-130344 dv-4423 DEBUG Direct connection to 6ULB established, routing table exchange begins.
Nov 26 10:48:59-131721 dv-4423 DEBUG Adding direct route to 6ULB
Nov 26 10:48:59-135212 dv-4435 DEBUG Starting SET listen operation with peer `6ULB'
Nov 26 10:48:59-136495 set-4444 DEBUG new listener created (op 2, app 3EHDSDB7)
Nov 26 10:48:59-136528 set-4444 DEBUG considered all incoming requests
Nov 26 10:48:59-147625 dv-4423 DEBUG Starting SET listen operation with peer `6ULB'
Nov 26 10:48:59-148502 set-4446 DEBUG new listener created (op 2, app 9VP5P4I2)
Nov 26 10:48:59-148596 set-4446 DEBUG considered all incoming requests
Nov 26 10:48:59-228971 dv-4422 DEBUG Initiating SET union with peer `G3FJ'
Nov 26 10:48:59-232234 set-api-4422 DEBUG set client created
Nov 26 10:48:59-234479 set-4454 INFO started
Nov 26 10:48:59-243288 dv-4422 DEBUG Finished building my SET for peer `G3FJ' with 0 elements, committing
Nov 26 10:48:59-255213 set-4454 DEBUG client created new set (operation 2)
Nov 26 10:48:59-255264 set-4454 DEBUG union set created
Nov 26 10:48:59-257499 set-4454 DEBUG evaluating union operation
Nov 26 10:48:59-257535 set-4454 DEBUG sent op request without context message
Nov 26 10:48:59-257988 dv-4422 DEBUG Direct connection to 6ULB established, routing table exchange begins.
Nov 26 10:48:59-258628 dv-4422 DEBUG Adding direct route to 6ULB
Nov 26 10:48:59-270711 dv-4422 DEBUG Initiating SET union with peer `6ULB'
Nov 26 10:48:59-271242 set-api-4422 DEBUG set client created
Nov 26 10:48:59-272230 dv-4422 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:48:59-274335 set-4454 DEBUG client created new set (operation 2)
Nov 26 10:48:59-274374 set-4454 DEBUG union set created
Nov 26 10:48:59-274565 set-4454 DEBUG client ins/rem element of size 36
Nov 26 10:48:59-275012 dv-4422 DEBUG Finished building my SET for peer `6ULB' with 1 elements, committing
Nov 26 10:48:59-275332 set-4454 DEBUG evaluating union operation
Nov 26 10:48:59-275363 set-4454 DEBUG sent op request without context message
Nov 26 10:48:59-275506 dv-4422 DEBUG Direct connection to DJ5S established, routing table exchange begins.
Nov 26 10:48:59-275880 dv-4422 DEBUG Adding direct route to DJ5S
Nov 26 10:48:59-287648 dv-4422 DEBUG Initiating SET union with peer `DJ5S'
Nov 26 10:48:59-288067 set-api-4422 DEBUG set client created
Nov 26 10:48:59-288372 dv-4422 DEBUG Adding peer `G3FJ' with distance 1 to SET
Nov 26 10:48:59-288609 set-4454 DEBUG client created new set (operation 2)
Nov 26 10:48:59-288643 set-4454 DEBUG union set created
Nov 26 10:48:59-289021 set-4454 DEBUG client ins/rem element of size 36
Nov 26 10:48:59-289127 dv-4422 DEBUG Adding peer `6ULB' with distance 1 to SET
Nov 26 10:48:59-289673 set-4454 DEBUG client ins/rem element of size 36
Nov 26 10:48:59-289873 dv-4422 DEBUG Finished building my SET for peer `DJ5S' with 2 elements, committing
Nov 26 10:48:59-290195 set-4454 DEBUG evaluating union operation
Nov 26 10:48:59-290225 set-4454 DEBUG sent op request without context message
Nov 26 10:49:02-913768 testbed-api-topology-4387 WARNING Error while establishing a link: 0x10: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:03-100675 testbed-api-topology-4387 WARNING Error while establishing a link: 0x13: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Nov 26 10:49:08-101927 testbed-api-topology-4387 WARNING Error while establishing a link: 0x15: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Nov 26 10:49:08-101958 testbed-api-topology-4387 WARNING Error while establishing a link: 0x14: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:13-103372 testbed-api-topology-4387 WARNING Error while establishing a link: 0x17: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:13-103407 testbed-api-topology-4387 WARNING Error while establishing a link: 0x16: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Testbed failed to connect peers,
Nov 26 10:49:23-110327 testbed-api-topology-4387 WARNING Error while establishing a link: 0x22: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:23-111899 testbed-api-topology-4387 WARNING Error while establishing a link: 0x25: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Nov 26 10:49:28-113248 testbed-api-topology-4387 WARNING Error while establishing a link: 0x27: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Nov 26 10:49:28-113280 testbed-api-topology-4387 WARNING Error while establishing a link: 0x26: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:33-114558 testbed-api-topology-4387 WARNING Error while establishing a link: 0x29: Timeout during TRANSPORT_try_connect() at peer G3FJ -- Retrying
Nov 26 10:49:33-114595 testbed-api-topology-4387 WARNING Error while establishing a link: 0x28: Timeout during TRANSPORT_try_connect() at peer DJ5S -- Retrying
Nov 26 10:49:38-115932 test-transport-dv-4387 INFO Links successful 10 / 8 fai

(0007700)
Florian Dold   
2013-11-26 15:00   
I can confirm that gnunet-consensus-profiler also stopped working ...

At the moment it looks to me like there's just no data going through the mesh channel, so maybe mesh is broken, but I'll have to investigate further ...
(0007701)
Florian Dold   
2013-11-26 15:13   
(Last edited: 2013-11-26 15:13)
Confirmed, if the service would actually get data, something like
Nov 26 15:03:56-017111 set-3675 DEBUG dispatching mesh message (type: 581)
would be in the logs.

(0007702)
Florian Dold   
2013-11-26 15:18   
Ah! Mesh crashes ...
Nov 26 15:17:31-190177 mesh-api-5069 DEBUG Mesh service disconnected, reconnecting
(0007728)
Matthias Wachs   
2013-11-27 10:28   
Peers exchange sets, routes are discovered:

Nov 27 10:15:09-003955 dv-321 DEBUG I am peer: DJ5S
Nov 27 10:15:09-622887 dv-321 DEBUG Discovered new route to G3FJ using 2 hops
Nov 27 10:15:09-624684 dv-321 DEBUG Delivering CONNECT about peer `G3FJ'

Nov 27 10:15:08-891056 dv-317 DEBUG I am peer: 6DER
Nov 27 10:15:09-423679 dv-317 DEBUG Discovered new route to DJ5S using 2 hops
Nov 27 10:15:09-426123 dv-317 DEBUG Delivering CONNECT about peer `DJ5S'
(0007761)
Matthias Wachs   
2013-12-05 14:25   
Current state (location of crash):

==2224== Invalid read of size 8
==2224== at 0x403EB5: cull_routes (gnunet-service-dv.c:1165)
==2224== by 0x56836BB: GNUNET_CONTAINER_multipeermap_iterate (container_multipeermap.c:361)
==2224== by 0x403FD7: handle_direct_disconnect (gnunet-service-dv.c:1187)
==2224== by 0x405D68: cleanup_neighbor (gnunet-service-dv.c:1816)
==2224== by 0x406087: handle_core_disconnect (gnunet-service-dv.c:1858)
==2224== by 0x5450C46: disconnect_and_free_peer_entry (core_api.c:389)
==2224== by 0x56836BB: GNUNET_CONTAINER_multipeermap_iterate (container_multipeermap.c:361)
==2224== by 0x545624B: GNUNET_CORE_disconnect (core_api.c:1221)
==2224== by 0x406332: shutdown_task (gnunet-service-dv.c:1924)
==2224== by 0x56A6DD0: run_ready (scheduler.c:593)
==2224== by 0x56A7657: GNUNET_SCHEDULER_run (scheduler.c:808)
==2224== by 0x56B56DA: GNUNET_SERVICE_run (service.c:1478)
==2224== Address 0x6f07920 is 0 bytes inside a block of size 48 free'd
==2224== at 0x4C2BA6C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2224== by 0x566FE1E: GNUNET_xfree_ (common_allocation.c:236)
==2224== by 0x4032B4: handle_direct_connect (gnunet-service-dv.c:878)
==2224== by 0x4042E5: handle_ats_update (gnunet-service-dv.c:1303)
==2224== by 0x4E3BE4D: process_pi_message (ats_api_performance.c:382)
==2224== by 0x4E3CB6A: process_ats_message (ats_api_performance.c:554)
==2224== by 0x566D130: receive_task (client.c:589)
==2224== by 0x56A6DD0: run_ready (scheduler.c:593)
==2224== by 0x56A7657: GNUNET_SCHEDULER_run (scheduler.c:808)
==2224== by 0x56B56DA: GNUNET_SERVICE_run (service.c:1478)
==2224== by 0x4067D3: main (gnunet-service-dv.c:2085)
==2224==
(0007782)
Christian Grothoff   
2013-12-08 21:51   
(Last edited: 2013-12-08 21:53)
I don't see the above anymore right now. But I get:

Dec 08 21:49:56-819037 dv-32086 ERROR Assertion failed at gnunet-service-dv.c:757.
Dec 08 21:50:04-694219 transport-32063 ERROR Assertion failed at plugin_transport_dv.c:313.

..Dec 08 21:50:07-176106 dv-32081 WARNING External protocol violation detected at gnunet-service-dv.c:1515.
Dec 08 21:52:29-184547 dv-32147 ERROR Assertion failed at gnunet-service-dv.c:660.

(0007783)
Christian Grothoff   
2013-12-08 21:51   
I _also_ get:
==32091== Invalid read of size 1
==32091== at 0x4C2E819: bcmp (mc_replace_strmem.c:935)
==32091== by 0x10B55F: build_set (gnunet-service-dv.c:844)
==32091== by 0x569C1B9: impl_send_continue (mq.c:289)
==32091== by 0x56ABEC0: run_ready (scheduler.c:595)
==32091== by 0x56AC812: GNUNET_SCHEDULER_run (scheduler.c:817)
==32091== by 0x56BB60F: GNUNET_SERVICE_run (service.c:1478)
==32091== by 0x10F3C8: main (gnunet-service-dv.c:2101)
==32091== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==32091==
(0007834)
Christian Grothoff   
2013-12-11 00:39   
DV now stopped crashing and seems to be exchanging routes, but I don't see it actually establishing connections (core/transport-level).
(0007901)
Christian Grothoff   
2013-12-19 00:09   
DV now connects at the ATS and transport layers, but not at CORE. This is very strange, as CORE does get the 'connect' and does respond with a KX initiation. It seemed that then ATS (!) may decide to switch to TCP (which is blacklisted), which then causes the KX to fail (as gnunet-service-transport_neighbours takes the ATS opinion into account while it checks for the blacklist). It is possible that the (blacklisted) TCP connection is then removed from ATS, but that does not help: core somehow got a disconnect (from transport), but transport continues to be connected, and DV has no timeout implemented so the situation is also never rectified by DV disconnect/reconnect. I'm not sure how exactly CORE gets the disconnect while transport remains connected, but it is late...
(0007928)
Christian Grothoff   
2013-12-22 01:43   
I'm re-scheduling this one for 0.10.1, as we clearly won't have time to finish it, and 0003229 is much more pressing.
(0014373)
Christian Grothoff   
2019-05-02 14:45   
Note that DV *is* now implemented (but not tested) as part of TNG.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6898 [GNUnet] GNS feature have not tried 2021-06-01 21:11 2021-06-01 21:11
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:  
Summary: GNS as DID registry
Description: Check and implement what is needed to allow the use of GNS as a DID Document registry for issuers.
This may also require documentation in the handbook and possibly a technical specification (LSD).
https://www.w3.org/TR/did-core/
Tags: beginner
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:
6897 [GNUnet] transport service feature have not tried 2021-06-01 21:09 2021-06-01 21:09
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:  
Summary: TNG QUIC communicator
Description: Write a communicator for the QUIC protocol. Use the TCP communicator or HTTP communicator as a basis.
Tags: beginner, tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6269 [libeufin] sandbox minor have not tried 2020-05-29 08:48 2021-05-27 15:53
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.1  
Summary: sandbox should emit c52/c53 more like real banks do
Description: Right now we generate a fresh c53 statement for every request.

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6268 [libeufin] sandbox minor have not tried 2020-05-29 08:47 2021-05-27 15:41
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.1  
Summary: sandbox should support balances in c52/c53
Description: Right now, we always display a balance of 0.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017920)
MS   
2021-05-27 15:41   
For now (4c44480..d527df4) every report always include the whole history of one bank account.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6736 [libeufin] command-line tools major have not tried 2021-02-04 11:08 2021-05-27 14:46
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Failing exit code needed, after unexpected response statuses.
Description: The command line tool does not always fail, when a command gets a unexpected response. A pass over the current logic is needed to make ALL the commands fail after a unexpected response.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017495)
MS   
2021-02-04 11:09   
One example is the command that deletes bank connections.
(0017919)
MS   
2021-05-27 14:46   
Implemented here: 51c5cc2..4c44480. Right now every command fails when the server responds with something != 200 OK.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6633 [libeufin] nexus minor have not tried 2020-10-29 22:10 2021-05-27 10:47
Reporter: MS Platform:  
Assigned To: Florian Dold OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.1  
Summary: Not all the requests get authenticated!
Description: Make sure that all the requests check the Authorization-header.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017911)
MS   
2021-05-27 10:35   
(Last edited: 2021-05-27 10:36)
It seems that some Taler facade API calls do not check any authorization.

Beside that, all the "direct" EBICS operations (like /send-ini, for example) do not check the authorization neither.
(0017912)
MS   
2021-05-27 10:47   
Errata: Taler does check for authorization, just "later" in the flow, in the context of checking the permissions over the resources being offered.


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

Currently we might run into waiting for a timeout (for re-doing the same order type) until the bank cancels the active transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017910)
MS   
2021-05-27 10:27   
Lowering the priority to match its related issue.


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

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

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6265 [libeufin] sandbox minor have not tried 2020-05-28 11:23 2021-05-27 10:25
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.2  
Summary: write script to fill sandbox with sample transactions
Description: We need some more or less "interesting" sample data in the sandbox, would be good to have some script that can populate the sandbox easily via the HTTP API of the sandbox.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017909)
MS   
2021-05-27 10:25   
Implemented with the "/admin/bank-accounts/{label}/generate-transactions" endpoint.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6882 [GNUnet] testbed service minor have not tried 2021-05-21 10:37 2021-05-22 17:43
Reporter: md Platform: GNU/Linux  
Assigned To: OS: Guix System  
Priority: normal OS Version: v???  
Status: new Product Version: 0.14.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: test_testbed_underlay fails
Description: The test_testbed_underlay test fails on Guix System when applying the patches for
updating to 0.14.1. On Guix' bug tracker: <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45875#62>
Tags:
Steps To Reproduce: For what's it worth: the package definition uses the commit 00c21152e81c10dff640ec932127e74ea8bc25ac.
Additional Information: Here's the log:

$ cat /tmp/guix-build-gnunet-0.14.1-00c2115.drv-0/source/src/testbed/test_testbed_underlay.log
May 20 20:42:55-459013 test_testbed_underlay-9591 WARNING Peers 0 and 2 should not get connected
May 20 20:42:55-461567 ats-9620 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
May 20 20:42:55-461939 ats-9624 ERROR Assertion failed at container_multipeermap.c:347. Aborting.
May 20 20:42:55-463838 transport-api-core-9616 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466559 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466716 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
May 20 20:42:55-466740 transport-api-core-9606 ERROR Error receiving from transport service (1), disconnecting temporarily.
FAIL test_testbed_underlay (exit status: 1)
System Description
    INFO: OS : Linux
    INFO: OS RELEASE : 5.8.15
    INFO: HARDWARE : x86_64
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6718 [libeufin] nexus minor have not tried 2021-01-23 20:39 2021-05-20 16:56
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: urgent OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: make sure all "obvious" CRUD operation exist and have tests
Description: We need to make sure that all resources have all reasonable "CRUD" (CReate, Update, Delete) supported, and that these operations are tested.

(And also what happens with dependencies. I.e., we might require that a bank account can't be deleted when there's a facade using it.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017461)
MS   
2021-01-30 14:09   
This got addressed to some extent, but can't claim now that ALL the operations are thoroughly covered.
(0017565)
MS   
2021-02-26 09:38   
(Last edited: 2021-02-26 11:09)
The following list should help define which resources are now held in LibEuFin.

Nexus:
- user account
- bank connection
- facade
- bank account
- Ebics subscriber
- scheduled tasks
- permission settings
- initiated payments

Sandbox:
- bank account
- Ebics subscriber
- Ebics host
(0017631)
MS   
2021-03-22 19:02   
After internal discussion, this bug will be solved just after every API endpoint will be covered by a test.
(0017795)
MS   
2021-05-07 11:47   
Testing creation and deletion/modification of a permission: b414de853371b98d125a92a4d9e9578be9b0f0d5

Deletion is modification because is achieved by setting the "revoke" status to one existing permission.
(0017806)
MS   
2021-05-10 11:59   
Creation and update of Nexus users gets tested here: 9772e5837ea861b23690b6727f1a67c7b2edf1da.

The update happens in terms of password change.
(0017807)
MS   
2021-05-10 12:04   
Payment initiations do not need a dedicate test case because their operations (*) are quite basic, and tested already
along the whole test suite.

(*) The update operation is basically the submission of a initiated payment. There is no deletion operation so far.
(0017838)
MS   
2021-05-12 10:04   
The bank account resource (as offered by Nexus) is tested here: 41b65e90b9eb1a0a4a999bce75df29a0ea3aedcc.
(0017839)
MS   
2021-05-12 11:59   
The bank connection resource gets tested here: 83b02069c931306c72c470e0285693719f65d0ca

This test however goes only through the creation and deletion of one, as updates got already tested
along the whole test suite. Updates include fetching transactions and bank account information from banks.
(0017848)
MS   
2021-05-14 12:40   
(Last edited: 2021-05-14 12:55)
Tasks scheduling gets tested here: dcef82d677f8b79b0a7b78f485f08fcd0f7d8c96
(0017876)
MS   
2021-05-18 18:08   
Facade creation and deletion get tested here: 0299e719ce4c97748090fa238cb5f68303fb4abf.
(0017884)
MS   
2021-05-20 16:56   
Nexus resources got covered. Eventually, a separate bug for the Sandbox can be opened.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6880 [Taler] bank (demonstrator) minor have not tried 2021-05-20 16:36 2021-05-20 16:36
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: /admin/add/incoming should prevent reuse of reserve public key
Description: Every reserve public key should receive money only once.

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:
6877 [GNUnet] build process minor always 2021-05-18 03:19 2021-05-18 19:00
Reporter: Brendan Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Consider allowing shallow fetches from git repos.
Description: When fetching a commit behind HEAD from gnunet/taler repos, git has to do a full fetch instead which takes a long time.
It is convenient for packaging from a commit that it can do a shallow fetch to save time, but not essential.
Tags:
Steps To Reproduce:
Additional Information: guile: warning: failed to install locale
environment variable `PATH' set to `/gnu/store/378zjf2kgajcfd7mfr98jn5xyc5wa3qv-gzip-1.10/bin:/gnu/store/sf3rbvb6iqcphgm1afbplcs72hsywg25-tar-1.32/bin'
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /gnu/store/18pi1dbri5p3w8fpm3qs65p5pm6nxhcz-gnunet-0.14.1-c2cd7ec/.git/
error: Server does not allow request for unadvertised object c2cd7ec031ff925294b5c4c0c992fe9014846430
Failed to do a shallow fetch; retrying a full fetch...
Attached Files:
Notes
(0017873)
schanzen   
2021-05-18 09:54   
Can you elaborate why you need this? We usually tag our releases so you can pull the tags and dev branches as well as master(0000004:0000001)
(0017875)
Brendan   
2021-05-18 14:35   
Sometimes we build from other commits when the release is broken and bugs are fixed later like is the case now. It's not a big deal, you can always reject this if its somehow troublesome to do. In guix we have roughly 1100 packages who's source refers to some arbitrary commit for various reasons rather than the release tarball or tag.
(0017877)
schanzen   
2021-05-18 19:00   
I think our policy for packagers is that they can get their own account and work in a branch for packaging. There you may then create tags (e.g. 0.14.1guix{0,1,2...}) which include fixes to your build system as well in order to create your own release versions.
At least, that is how it will be for debian.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6016 [Taler] wallet (TS core) feature have not tried 2019-12-26 21:43 2021-05-12 16:28
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: wallet should recover from payments where the exchange reports an invalid coin
Description: These cases include:

 * coin is double-spent
 * coin is of a denomination that is not offered by the exchange anymore (due to exchange DB reset)

The wallet has to report this error and offer the possibility to re-try the payment using a different set of coins (if balance is sufficient).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017845)
Florian Dold   
2021-05-12 16:28   
The double-spending scenario is now covered and has a test case. The "selected denomination is now outdated" scenario still needs a test case.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2075 [libextractor] plugins feature N/A 2012-01-16 22:51 2021-05-07 22:05
Reporter: Christian Grothoff Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: current SVN  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: implement meta-data extraction from video files using libvlc
Description: libvlc (from the VideoLAN/vlc project) and in particular the libvlc_media.h header of that library, provides a way to extract interesting meta-data from various video formats:

/** Meta data types */
typedef enum libvlc_meta_t {
    libvlc_meta_Title,
    libvlc_meta_Artist,
    libvlc_meta_Genre,
    libvlc_meta_Copyright,
    libvlc_meta_Album,
    libvlc_meta_TrackNumber,
    libvlc_meta_Description,
    libvlc_meta_Rating,
    libvlc_meta_Date,
    libvlc_meta_Setting,
    libvlc_meta_URL,
    libvlc_meta_Language,
    libvlc_meta_NowPlaying,
    libvlc_meta_Publisher,
    libvlc_meta_EncodedBy,
    libvlc_meta_ArtworkURL,
    libvlc_meta_TrackID,
    /* Add new meta types HERE */
} libvlc_meta_t;

We should create an LE plugin that uses libvlc to extract this meta data.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017797)
Christian Grothoff   
2021-05-07 22:03   
test-vlc.c works if you use libvlc_media_new_path() -- if lua is installed.

But, libvlc_media_new_fd() and libvlc_media_new_callbacks() both fail for vlc3 and vlc4 (git master).
So this is clearly a hard vlc problem, likely the lua scripts don't work with the callbacks. I guess this bug has to wait for vlc5 or so...

Anyway, starting point 'vlc_extractor.c' is in git, but non-functional.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6395 [libeufin] nexus minor have not tried 2020-06-18 21:54 2021-05-03 11:21
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.1  
Summary: implement bank protocol-specific logic in a less ad-hoc way via interfaces and a registry
Description: Instead of having some ad-hoc methods and switch statements, we should define an interface and use polymorphism.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017648)
MS   
2021-03-25 10:45   
What is 'registry'?
(0017793)
MS   
2021-05-03 11:21   
Implemented here: 688af0d49e77ca918c7f66c37bd047b4560bf779.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2518 [libextractor] plugins feature N/A 2012-08-24 23:32 2021-05-02 22:33
Reporter: Christian Grothoff 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: 1.13  
    Target Version: 1.13  
Summary: real plugin should be ported to new API
Description: Plugin for the old API exists in src/plugins/old/
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017792)
Christian Grothoff   
2021-05-02 22:33   
Fixed in 1cc2d75..d40016f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2516 [libextractor] plugins feature N/A 2012-08-24 23:30 2021-05-01 23:02
Reporter: Christian Grothoff 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: 1.13  
    Target Version: 1.13  
Summary: ELF plugin should be ported to new API
Description: ELF plugin currently only lives in plugins/old/ with the old plugin API.
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:
6853 [Taler] bank (demonstrator) minor have not tried 2021-04-29 15:53 2021-04-29 15:54
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: public accounts page doesn't update
Description: Registering new users doesn't show the "Joining bonus" wire transfer under the 'Bank' tab at the public accounts page.
Tags:
Steps To Reproduce:
Additional Information: The pager had 15 entries when this was observed.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6851 [GNUnet] build process minor always 2021-04-26 10:08 2021-04-26 10:08
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: Warnings with autoconf 2.70
Description: There are a lot of warnings introduced with autoconf 2.70. Some are a result from external dependencies (e.g. https://github.com/curl/curl/issues/6647) others we have to fix ourselves. This is a tracker bug for fixing compat with 2.70.

We may want to stay compatible with autoconf 2.69, but that would require a lot of macros.
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:
2072 [libextractor] plugins feature N/A 2012-01-16 16:03 2021-04-20 19:04
Reporter: Christian Grothoff 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: PDF plugin needs to be implemented; should handle XMP data in PDF files
Description: Specifications are here:

http://www.adobe.com/devnet/xmp/pdfs/xmp specification.pdf

http://www.adobe.com/devnet/pdf/pdf reference.html

Naturally, we want as much of the real work to be done by either GNU PDF or some other GPLv3-compatible library.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017775)
Christian Grothoff   
2021-04-20 19:04   
https://gitlab.freedesktop.org/poppler/poppler/-/tree/master/glib would seem to be able to do the trick, see the 'document' header.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2076 [libextractor] plugins feature N/A 2012-01-16 22:59 2021-04-20 18:48
Reporter: Christian Grothoff Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: current SVN  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version: 1.12  
    Target Version: 1.12  
Summary: implement meta data extraction using libavformat (ffmpeg library)
Description: libavformat/avformat.h clearly provides access to some interesting meta data:

 album -- name of the set this work belongs to
 album_artist -- main creator of the set/album, if different from artist.
                 e.g. "Various Artists" for compilation albums.
 artist -- main creator of the work
 comment -- any additional description of the file.
 composer -- who composed the work, if different from artist.
 copyright -- name of copyright holder.
 creation_time-- date when the file was created, preferably in ISO 8601.
 date -- date when the work was created, preferably in ISO 8601.
 disc -- number of a subset, e.g. disc in a multi-disc collection.
 encoder -- name/settings of the software/hardware that produced the file.
 encoded_by -- person/group who created the file.
 filename -- original name of the file.
 genre -- <self-evident>.
 language -- main language in which the work is performed, preferably
                 in ISO 639-2 format. Multiple languages can be specified by
                 separating them with commas.
 performer -- artist who performed the work, if different from artist.
                 E.g for "Also sprach Zarathustra", artist would be "Richard
                 Strauss" and performer "London Philharmonic Orchestra".
 publisher -- name of the label/publisher.
 service_name -- name of the service in broadcasting (channel name).
 service_provider -- name of the service provider in broadcasting.
 title -- name of the work.
 track -- number of this work in the set, can be in form current/total.
 variant_bitrate -- the total bitrate of the bitrate variant that the current stream is part of
 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017773)
Christian Grothoff   
2021-04-20 18:43   
1e64237..2332716 _removes_ all ffmpeg support, the library is just too buggy and the API too unstable to be useful.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3273 [libextractor] plugins feature N/A 2014-01-17 14:12 2021-04-20 18:48
Reporter: bratao Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: current SVN  
Product Build: Resolution: won't fix  
Projection: none      
ETA: none Fixed in Version: 1.12  
    Target Version: 1.12  
Summary: Create a libav/ffmpeg plugin
Description: I'm working on a pure libav/ffmpeg for extracting metadata.

With it, we can get valuable metadata without the GStreamer dependency.

Creating this ticket to inform about the development.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017772)
Christian Grothoff   
2021-04-20 18:41   
1e64237..2332716 _removes_ existing support on ffmpeg (opus plugin and thumbnailer). The library's API was too unstable, and the ffmpeg library code crashed a lot (when fuzzing).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5659 [libextractor] build system minor have not tried 2019-03-20 10:41 2021-04-20 18:40
Reporter: nikita 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: 1.12  
    Target Version: 1.12  
Summary: ffmpeg not found
Description: NOTICE: FFmpeg thumbnailer plugin disabled
NOTICE: FFmpeg/opus audio preview plugin disabled, It needs libav >=10, or a FFmpeg with --enable-libavresample


Since I have a ffmpeg build with this option AND it is in the build root, I think we need an option to
define the prefix of ffmpeg.
Tags:
Steps To Reproduce:
Additional Information: I'm opening these issues to reference a reason why the changes were made, instead of
committing first.
Attached Files:
Notes
(0017771)
Christian Grothoff   
2021-04-20 18:40   
1e64237..2332716 removes ffmpeg support entirely, indirectly solving this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6734 [libextractor] build system text always 2021-02-01 18:26 2021-04-20 18:39
Reporter: limb Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.11  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.12  
    Target Version: 1.12  
Summary: Tests unexpectecly succeed.
Description: PASS: fuzz_default.sh
PASS: test_dvi
PASS: test_it
PASS: test_man
PASS: test_nsf
PASS: test_nsfe
PASS: test_odf
PASS: test_ps
PASS: test_png
PASS: test_riff
PASS: test_s3m
PASS: test_sid
PASS: test_wav
PASS: test_xm
PASS: test_zip
PASS: test_archive
PASS: test_exiv2
PASS: test_flac
PASS: test_gif
PASS: test_ole2
PASS: test_gstreamer
PASS: test_thumbnailgtk
PASS: test_jpeg
PASS: test_mime
PASS: test_ogg
PASS: test_rpm
PASS: test_tiff
PASS: test_deb
============================================================================
Testsuite summary for libextractor 1.11
============================================================================
# TOTAL: 28
# PASS: 28
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[5]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src/plugins'
make[4]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src/plugins'
make[3]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src/plugins'
make[2]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src/plugins'
Making check in .
make[2]: Entering directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src'
make[2]: Nothing to be done for 'check-am'.
make[2]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src'
make[1]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/src'
Making check in doc
make[1]: Entering directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/doc'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11/doc'
Making check in .
make[1]: Entering directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11'
make[1]: Leaving directory '/home/gwyn/fedora/git/libextractor/libextractor-1.11'
+ echo 'Test succeeded unexpectedly! Revisit me!'
Test succeeded unexpectedly! Revisit me!
+ false
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017494)
Christian Grothoff   
2021-02-03 23:42   
Interesting, looks like your distribution doesn't have buggy ffmpeg libraries that are crashed by our fuzzer, which is what happens on my Debian.
Anyway, don't worry, tests passing is a GOOD thing (TM). Thanks for reporting ;-)
(0017496)
limb   
2021-02-04 15:44   
It doesn't have any ffmpeg libraries, for licensing reasons.
(0017752)
Christian Grothoff   
2021-04-16 23:46   
Ah, then that is the problem. I guess I should modify the 'expectation' to be careful about the presence of the crashy-ffpmpeg library ;-)
(0017769)
Christian Grothoff   
2021-04-20 18:37   
Fixed by removing the ffmpeg code which is what is 'expected' to fail because of ffmpeg bugs. 1e64237..2332716


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6777 [libextractor] plugins feature N/A 2021-03-01 21:36 2021-04-20 18:39
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: current SVN  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.12  
    Target Version: 1.12  
Summary: opus plugin uses obsolete library
Description: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971331 tells us that our dependency is deprecated.
1e64237ffae3c73efd864dc03ee2e3dfed29c10b updates the build system to the replacement library, alas the plugin does not yet compile.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0017770)
Christian Grothoff   
2021-04-20 18:39   
Fixed by removing support in 1e64237..2332716. ffmpeg library is too much of a mess to be supportable.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6520 [Taler] other feature always 2020-08-24 08:15 2021-04-19 19:10
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: GANA doesn't complain when error names are re-used with a new code, but it results in a compilation error
Description: GANA should try to only generate headers that actually compile!

When we repeat the name of an error code, only the C/TS/etc. compiler will catch this, but not the "make" inside the GANA repo that generates these files via templating.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016735)
Christian Grothoff   
2020-08-24 13:06   
Eh, I tested, and GANA does complain properly *if* you run 'make check'.
(0016736)
Christian Grothoff   
2020-08-24 13:07   
And 'check' is part of 'make all', so I'm not sure what you did to NOT get this error:

$ make check
recfix --check registry.rec
registry.rec:125: error: %constraint[0] violated in record
make: *** [Makefile:9: check] Error 1

[after manually introducing a problem as described]
(0016737)
Florian Dold   
2020-08-24 14:05   
I've committed a broken registry here, to a branch:

https://git.gnunet.org/gana.git/commit/?h=dev/dold/broken-registry&id=57ea691b13f689e29d66192c7c22cc2b41349e6c

For me, this happens:
$ cd gnu-taler-error-codes
$ make check
recfix --check registry.rec
(exits with status 0)

Here's my recutils version:
$ recfix --version
recfix (GNU recutils) 1.8.90
(0016738)
Christian Grothoff   
2020-08-24 14:10   
C'est bizzare! I tested with duplicate NAMEs just like you did, and 'make check' hated me as it should. But with your change, it is indeed breaking.
(0016739)
Christian Grothoff   
2020-08-24 14:11   
Contacted jemarch via IRC, let's see what he says.
(0016745)
Christian Grothoff   
2020-08-24 14:54   
jemarch says this is not supported. Maybe we'll get a feature update in the future ;-).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4960 [Taler] auditor feature N/A 2017-03-17 18:56 2021-04-19 19:09
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.1  
Summary: need tool to move historic revenues into aggregation tables and generate profit report
Description: Once the auditor has verified that the profits are done correctly, we still need a way to archive the results properly, by reporting period, and to generate the ultimate report on profitability of the exchange.

The tool should also allow the exchange operator to take out profits/expenses so that the account balance continues to match after the operator made a withdrawal outside of normal Taler operations.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0015280)
Christian Grothoff   
2020-01-16 22:34   
Marked in the code as part of the auditor's GC logic.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6821 [GNUnet] rps service minor sometimes 2021-03-29 18:57 2021-03-29 18:57
Reporter: ch3 Platform:  
Assigned To: ch3 OS:  
Priority: low OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rps fails to cancel a request
Description: From the log of running `test_rps_single_req`:
`Assertion failed at rps_api.c:1207`

Probably due to prior crash of service.
Tags:
Steps To Reproduce: run `test_rps_single_req`
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6804 [Taler] wallet (TS core) minor have not tried 2021-03-11 16:10 2021-03-29 12:17
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 wallet test case for a multi-exchange payment
Description: The test case should withdraw from two exchanges and then pay for an order with a merchant that accepts both exchanges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6427 [libeufin] sandbox minor have not tried 2020-07-09 19:41 2021-03-25 10:42
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: none OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.2  
Summary: EBICS errors need XML
Description: In some (all?) error cases related to EBICS, the sandbox responds with plain text.
Instead it should respond with the XML document that complies to the EBICS specifications.
Tags:
Steps To Reproduce:
Additional Information: Moving to 0.2 because it became a testing problem.
Attached Files:
Notes
(0016507)
MS   
2020-07-23 13:42   
(Last edited: 2020-07-23 13:44)
Mostly addressed here: c716d23073be8846d0765fa766de341dbc953a88

(0016508)
MS   
2020-07-23 13:48   
The EbicsError global catcher needs a private key to be included in the exception object,
and if that's not found, it responds with JSON (and status 500). (The private key is needed
to sign the response object.)

The current problem is that not in all the parts of the code such private key is included in
the exception object, resulting still in JSON+500 being returned.
(0016509)
MS   
2020-07-23 17:13   
After private discussion, the private key will be moved away from the exception object. But at the same time, the exception handler
must be moved in a place where it is easier to get more context (including the private key) from the current request.
(0016531)
MS   
2020-07-29 15:41   
Fixed, but this test now fails: integration-tests/test-ebics-double-payment-submission.py
(0017647)
MS   
2021-03-25 10:42   
The test mentioned in the last comment was long ago removed, and in general, corner cases will 'all' have to be implemented in the new TypeScript harness. IMO, this can be closed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6697 [libeufin] other minor have not tried 2021-01-14 00:13 2021-03-25 10:36
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create debian package for LibEuFin based on fat jar zip
Description: We can automatically generate a binary distribution zip of LibEuFin via:

$ ./gradlew dist

This creates a fat jar (in build/distributions/). That might be a good initial approach for Debian packaging, as not all dependencies of LibEuFin are packaged in Debian.

Gradle downloads dependencies from maven repositories. That's forbidden by Debian's packaging policy, but generally supported by non-official Debian packages.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017646)
MS   
2021-03-25 10:36   
Done a while ago by Christian.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6719 [libeufin] other minor have not tried 2021-01-24 14:11 2021-03-25 10:34
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create systemd units for nexus (and maybe sandbox)
Description: The main question here is how to configure database credentials.

Maybe nexus/sandbox should just support reading the DB connection string from an environment variable, and the systemd unit can expose some environment variables via the "EnvironmentFile" setting.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017645)
MS   
2021-03-25 10:33   
Done a while ago, together with the Debian packaging.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6730 [libeufin] other minor have not tried 2021-01-30 15:30 2021-03-25 10:33
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: create integration test for instructions from nexus/sandbox guide
Description: Ideally, we do this with the wallet's integration test harness, because we can do all the setup steps explicitly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017644)
MS   
2021-03-25 10:32   
Done a while ago (right after meeting with bank).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6742 [libeufin] nexus minor have not tried 2021-02-05 17:25 2021-03-25 10:30
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: (too early) scheduler routine causes exceptions due to missing table
Description: Running the Python integration tests causes many stack traces (due to missing DB table) because the scheduler routine starts _before_ the program can create the "nexus scheduled tasks" table. Ideally, that routine should wait that all the tables get created before being fired up.
Tags:
Steps To Reproduce: Run "make tests", and check integration-tests/nexus-stderr.log
Additional Information:
Attached Files:
Notes
(0017642)
MS   
2021-03-25 10:27   
Fixed here: 3ade91b..b4b71a4
(0017643)
MS   
2021-03-25 10:30   
For now, the fix was mainly to move the scheduler execution at the "latest" possible moment . If the problem persists, a more structural solution should be found.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6807 [gnunet-www] General minor always 2021-03-14 18:39 2021-03-22 20:14
Reporter: pv3lj1fv3e Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: 0.14.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Confusing or missing installation instructions for compiling gnunet-gtk from git
Description: https://gnunet.org/de/install.html says: "Alternatively, get the sources from git by entering" This can be understood that the following "git clone" gets all sources for all packages. Actually, one needs to clone gnunet-gtk.git in order to get it compiled. Therefore the manual also does not tell how to get the packages needed to fulfill the dependencies.
Tags:
Steps To Reproduce: Read https://gnunet.org/de/install.html
Additional Information:
Attached Files:
Notes
(0017632)
schanzen   
2021-03-22 20:13   
I am not sure how to address this. The dependencies are linked via the README on that page. The additional gtk dependencies and installation instructions can be found in the handbook and tarball. Would you rather not have the gnunet-gtk/fuse link on that page at all?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5916 [gnunet-www] Homepage minor have not tried 2019-10-02 14:01 2021-03-12 16:39
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: redirect script
Description: write a script to automate the creation of static redirect pages
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6800 [Taler] wallet (TS core) minor have not tried 2021-03-10 19:06 2021-03-10 19:06
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 link protocol (for double spend error recovery after restore from backup)
Description: The wallet should run the link protocol if it gets a double spend error that indicates the coin has been melted, and the new coin isn't known to the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6774 [Taler] merchant backend API (C) minor have not tried 2021-03-01 13:09 2021-03-04 11:21
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ERROR BUG: Preflight check committed transaction `pickup tip'!
Description: From the "hacker news DoS" day:

Feb 26 13:44:47-285530 taler-merchant-httpd-3049906(K371ZSR3VZ5390MTJWHMR0TJHM) ERROR BUG: Preflight check committed transaction `pickup tip'!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017591)
Christian Grothoff   
2021-03-04 11:12   
I have combed over the transaction code three times now, cannot find any path where it is not orderly aborted or committed.WTF?
(0017592)
Christian Grothoff   
2021-03-04 11:13   
We need to find a way to reproduce this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6783 [GNUnet] util library minor always 2021-03-03 21:51 2021-03-03 21:51
Reporter: thejackimonster Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: 0.14.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: anonymous key fails at ECDHE
Description: The ECDHE fails using the anonymous key pair even if all tests with randomly generated ECDSA key pairs succeed. This could be an issue caused by the util library in GNUnet, a mixture of using gcrypt and libsodium together or even an issue inside of libsodium.
Tags: bug
Steps To Reproduce: // Get the anonymous ECDSA key pair
const struct GNUNET_CRYPTO_EcdsaPrivateKey* ecdsa_priv = GNUNET_CRYPTO_ecdsa_key_get_anonymous();
struct GNUNET_CRYPTO_EcdsaPublicKey ecdsa_pub;
GNUNET_CRYPTO_ecdsa_key_get_public(ecdsa_priv, &ecdsa_pub);

// Generate a random ECDHE key pair
struct GNUNET_CRYPTO_EcdhePrivateKey ecdhe_priv;
struct GNUNET_CRYPTO_EcdhePublicKey ecdhe_pub;
GNUNET_CRYPTO_ecdhe_key_create(&ecdhe_priv);
GNUNET_CRYPTO_ecdhe_key_get_public(&ecdhe_priv, &ecdhe_pub);

// Derive hashes from the keys
struct GNUNET_HashCode h1;
struct GNUNET_HashCode h2;
GNUNET_CRYPTO_ecdh_ecdsa(&ecdhe_priv, &ecdsa_pub, &h1);
GNUNET_CRYPTO_ecdsa_ecdh(ecdsa_priv, &ecdhe_pub, &h2);

// The hashes don't match..!
GNUNET_assert(GNUNET_CRYPTO_hash_cmp(&h1, &h2) == 0);
Additional Information: Currently this is not a huge issue because ECDHE gets used only in the identity API to encrypt and decrypt data for a specific ego. So the result is that encrypting data for the anonymous ego will fail.

The functionality gets used by the messenger service but the service itself restricts encrypting messages to individually used egos (excluding the anonymous ego) in current state of development anyway.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5084 [GNUnet] other feature have not tried 2017-06-16 14:21 2021-03-03 19:23
Reporter: nikita Platform:  
Assigned To: schanzen OS:  
Priority: high OS Version:  
Status: assigned Product Version: Git master  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Make gnURL obsolete.
Description: Christian told me that there are steps which could be done so that gnURL becomes unnecessary for all things GNUnet.

Could you share what needs to be done so that someone can pick it up?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012254)
nikita   
2017-06-16 14:23   
My motivation: Even with some automation I spent about 0.5 - 2.5 hours on a release of gnURL depending on what cURL changed and introduced.
(0012255)
Christian Grothoff   
2017-06-16 22:20   
Well, it'll take a bit more than 2h to obsolete gnURL.

Basically, what it would take is to modify libcurl (!) to use dlopen to load all of its supported protocols and SSL libraries as plugins. That way, each of curls dependencies would be only required by the respective plugin, and an application would only link/load those plugins (and dependencies) it actually needs.

Daniel seemed open to this idea and thus is likely to merge such a patch, but this would be a MAJOR refactoring of the libcurl code. Not for the faint of heart.
(0012256)
nikita   
2017-06-17 00:15   
(Last edited: 2017-06-17 00:15)
Okay, so I'd say it's easier to open this as a ticket at github.com/curl/curl and see how this works out. It's difficult to address problems and new features when I am really just patching and have no substantial view inside your mind ;)

Or does this discussion already exist somewhere with some outcome?

(0012446)
Christian Grothoff   
2017-09-27 11:40   
Here is the discussion with the cURL people: https://github.com/curl/curl/issues/349 --- so we did make it onto their TODO list:

https://github.com/jgsogo/curl/commit/a60d994eb8fb4cabd627c44f4166a54aee81d725
(0017583)
schanzen   
2021-03-03 18:45   
Upgrading urgency as maintainer now inactive and we still recommend use of gnurl for gnunet.
We need to either revert to curl as-is or find/maintain gnurl.
(0017585)
Christian Grothoff   
2021-03-03 18:52   
Last I checked, libwget2 was still very far away from being able to support an event loop.
OTOH, the original conflicting dependency linker issues have also disappeared and are (AFAIK) not an issue with current libcurl.
The real fix, deploying plugins with libcurl, has also never been done.

So: we surely could abandon gnurl reasonably safely, at the expense of a significant increase in our (dead) dependency footprint. I don't see anyone stepping up to making libcurl pluggable, and also don't expect libwget2 to 'soon' be an adequate replacement for curl/gnurl. So the footprint increase might be a bullet we need to bite without nikita's maintainership.
(0017586)
schanzen   
2021-03-03 18:58   
I also recentrly triggered wget2 again: https://gitlab.com/gnuwget/wget2/-/issues/550


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5686 [Taler] wallet (WebExtensions) feature have not tried 2019-04-12 20:43 2021-03-01 13:00
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wallet feature request: silent payments.
Description: I am proposing that wallets should let customers to "silently" pay IF the merchant is trusted AND IF the amount is not more than X.

"Silently" means that the wallet accepts the contract WITHOUT showing anything to the user. And obviously, it is the customer itself that configures the trusted merchant and the amount threshold.

This helps for Web sites where the user may buy multiple times in one day, or even one session: like paid blog/news articles, photos shops, audio effects shops, and possibly more examples. It is just more practical to NOT manually accept 10-20 contracts a day, but just 'silently' pay.

This makes also up for Taler's impossibility of implementing recurring payments; in the end, one does recurring payments to NOT repeat the payment experience every time they take something from somewhere. This goes even a bit further: it saves the customer from going through the payment experience AND saves the user from paying for what they did NOT take.

Say for example you pay 10 euro / month for that news site, but only read 1 article for that particular month: waste of money. With this feature in place, you pay only for what you get.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014319)
Christian Grothoff   
2019-04-20 15:04   
This is definitively a post 1.0-feature.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5555 [GNUnet] ARM service minor have not tried 2019-02-10 22:09 2021-02-28 13:57