duniter issueshttps://git.duniter.org/nodes/typescript/duniter/-/issues2021-04-17T14:57:52+02:00https://git.duniter.org/nodes/typescript/duniter/-/issues/1425Honor X-Real-IP and / or X-Forwarded-For when behind a reverse proxy2021-04-17T14:57:52+02:00piniHonor X-Real-IP and / or X-Forwarded-For when behind a reverse proxyHi,
When behind a reverse proxy, the log reports the proxy's IP address instead of the client's. Please provide a way to honor the 'X-Real-IP' and / or 'X-Forwarded-For' headers to retrieve the actual client's IP address.
I guess this ...Hi,
When behind a reverse proxy, the log reports the proxy's IP address instead of the client's. Please provide a way to honor the 'X-Real-IP' and / or 'X-Forwarded-For' headers to retrieve the actual client's IP address.
I guess this is needed for the `dos` whitelist to be effective as well.
I'm aware that these headers can be spoofed by the client. Several methods exist to mitigate this. See for example how it is done for the PeerTube service, using a list of trusted proxies' CIDRs.
Thanks in advance for considering.https://git.duniter.org/nodes/typescript/duniter/-/issues/1420dockerfile ?2020-10-24T12:56:19+02:00timothedockerfile ?est ce qu'il pourrait y avoir un dockerfile afin de permettre de lancer le projet sur n'importe quel environnementest ce qu'il pourrait y avoir un dockerfile afin de permettre de lancer le projet sur n'importe quel environnementhttps://git.duniter.org/nodes/typescript/duniter/-/issues/30API lacks a method to list current WoT members2020-10-04T19:21:27+02:00Cédric MoreauAPI lacks a method to list current WoT membersIt would be nice to have a web method listing computed WoT members, instead of computing it by ourselves.
Such method could look like a Merkle URL whose leaves are packs of 1.000 members. Packs contains members' pubkey ASCII sorted, so ...It would be nice to have a web method listing computed WoT members, instead of computing it by ourselves.
Such method could look like a Merkle URL whose leaves are packs of 1.000 members. Packs contains members' pubkey ASCII sorted, so we always have:
- x, pack number, [0 ; +inf]
- y, member position in a pack, [0 ; 999]
- pack[x][y] < pack[x][y + 1]
- pack[x][999] < pack[x + 1][0]
<!---
@huboard:{"milestone_order":5.0,"order":33.0,"custom_state":""}
-->
https://git.duniter.org/nodes/typescript/duniter/-/issues/1294Upgrade `moment` library2020-10-04T19:17:25+02:00Cédric MoreauUpgrade `moment` libraryThere is a CVE on the version we use: https://nvd.nist.gov/vuln/detail/CVE-2017-18214There is a CVE on the version we use: https://nvd.nist.gov/vuln/detail/CVE-2017-18214https://git.duniter.org/nodes/typescript/duniter/-/issues/1302Migrating from wotb (C++) to wotb-rs (Rust)2020-10-04T19:15:58+02:00ÉloïsMigrating from wotb (C++) to wotb-rs (Rust)ÉloïsÉloïshttps://git.duniter.org/nodes/typescript/duniter/-/issues/1315GVA Needs as SQL requests2020-10-04T19:15:24+02:00gerard94GVA Needs as SQL requestsBlockchain
SELECT parameters FROM block WHERE number = 0 AND NOT fork
SELECT hash FROM i_index WHERE pub = '<pubkey>' ORDER BY writtenOn ASC
SELECT max(number) FROM block WHERE NOT fork
SELECT number, medianTime, time, joiners, activ...Blockchain
SELECT parameters FROM block WHERE number = 0 AND NOT fork
SELECT hash FROM i_index WHERE pub = '<pubkey>' ORDER BY writtenOn ASC
SELECT max(number) FROM block WHERE NOT fork
SELECT number, medianTime, time, joiners, actives, leavers, revoked, excluded, certifications FROM block WHERE NOT fork AND number >= <n> ORDER BY number ASC
Sandbox
SELECT hash, pubkey, uid, buid, revocation_sig, expires_on FROM idty
SELECT fork FROM block WHERE hash = '<hash>'
SELECT idtyHash, membership, expires_on FROM membership INNER JOIN block ON membership.blockHash = block.hash WHERE NOT block.fork ORDER BY blockNumber ASC
SELECT [from], [to], target, expires_on FROM cert INNER JOIN block ON cert.block_hash = block.hash WHERE NOT block.forkhttps://git.duniter.org/nodes/typescript/duniter/-/issues/1321Integrate new Docker installation2020-10-04T19:14:09+02:00Cédric MoreauIntegrate new Docker installationThe current docker installation seems to be outdated and no more works.
Someone (fabwice) proposed a new dockerfile here: https://forum.duniter.org/t/compte-g-test-a-certifier-pour-noeud/5420/48The current docker installation seems to be outdated and no more works.
Someone (fabwice) proposed a new dockerfile here: https://forum.duniter.org/t/compte-g-test-a-certifier-pour-noeud/5420/48https://git.duniter.org/nodes/typescript/duniter/-/issues/1209Create a docker image of duniter and a how to use it wiki2020-10-04T19:11:51+02:00Cédric MoreauCreate a docker image of duniter and a how to use it wiki*Created by: Kleak*
- [ ] docker image
- [ ] how to use it*Created by: Kleak*
- [ ] docker image
- [ ] how to use ithttps://git.duniter.org/nodes/typescript/duniter/-/issues/1227The `--nb-cores` option is no taken into account2020-10-04T19:11:18+02:00Cédric MoreauThe `--nb-cores` option is no taken into accountWhen I run a command like:
duniter config --nb-cores 1
The configuration is not updated with this value.When I run a command like:
duniter config --nb-cores 1
The configuration is not updated with this value.https://git.duniter.org/nodes/typescript/duniter/-/issues/1341Certification in sandbox doesn't survive its sender2020-10-04T19:08:29+02:00gerard94Certification in sandbox doesn't survive its senderIn G1, at block 202065 (07/03/2019 23:35 BCT), Pascal11 should have become member, but hasn't. One of his certifiers, Romain350, was no more member since 06/03/2019 (at ~16:15:43, BCT), but its certification was still valid until 04/04/2...In G1, at block 202065 (07/03/2019 23:35 BCT), Pascal11 should have become member, but hasn't. One of his certifiers, Romain350, was no more member since 06/03/2019 (at ~16:15:43, BCT), but its certification was still valid until 04/04/2019 18:01:21. Was the exclusion of Romain350 the reason of the non-admission of Pascal11, while its certification was still valid?https://git.duniter.org/nodes/typescript/duniter/-/issues/1345Feature Request - Private option for user transactions2020-10-04T19:07:15+02:00bpreslesFeature Request - Private option for user transactionsMost of the time when I talk about the Monnaie Libre to others, the fact that the transactions can't be hidden to others is considered as a crippling issue to adopt the Monnaie Libre.
My suggestion is to add a "hide my transactions" opt...Most of the time when I talk about the Monnaie Libre to others, the fact that the transactions can't be hidden to others is considered as a crippling issue to adopt the Monnaie Libre.
My suggestion is to add a "hide my transactions" option for users, in the user profile, so that the transactions are not visible to others in that case.
By default, transactions are hidden to all new accounts and showing them publicly is a an opt-in option.
Implementing that on Duniter level would make sure that old clients (Cesium...) are not displaying transactions of users who have asked to hide them.
I understand that adding such a feature would require that all existing nodes to be updated, as nodes using versions before the one that implements it would still expose all the transactions publicly, and so that it would take time for it to be completely spread on all the network.
An option could be that nodes not updated to the version equals or greater than the one implementing this feature will be excluded (forked) from the network after a specific date.
I know that there is the option to use an anonymizer service (like the one offered by @vincentux), but for common users this solution is too complex and obscure.
As a supporter of Free Software and its principles, I personally don't care about my transactions being exposed publicly, but if we want the Monnaie Libre to expand, we'll need to have this feature one day or another, because many people don't agree and will never agree to have their transactions exposed publicly.https://git.duniter.org/nodes/typescript/duniter/-/issues/1346Incoherent BR_G992020-10-04T19:04:00+02:00Pascal EngélibertIncoherent BR_G99The condition in BR_G99 seems to be incoherent: if block<sub>0</sub>.currency is null, then block<sub>1</sub>.currency (and all blocks) is null too. In g1, the block 0 currency is g1, not null.
> ###### BR_G99 - HEAD.currency
>
> If `H...The condition in BR_G99 seems to be incoherent: if block<sub>0</sub>.currency is null, then block<sub>1</sub>.currency (and all blocks) is null too. In g1, the block 0 currency is g1, not null.
> ###### BR_G99 - HEAD.currency
>
> If `HEAD.number > 0`:
>
> ```
> HEAD.currency = HEAD~1.currency
> ```
> Else:
>
> ```
> HEAD.currency = null
> ```https://git.duniter.org/nodes/typescript/duniter/-/issues/1370Upgrade native dependencies to N-API2020-10-04T19:02:39+02:00Cédric MoreauUpgrade native dependencies to N-APISee: https://medium.com/the-node-js-collection/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06
This concerns:
* wotb
* naclb
* sqlite3?See: https://medium.com/the-node-js-collection/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06
This concerns:
* wotb
* naclb
* sqlite3?https://git.duniter.org/nodes/typescript/duniter/-/issues/1386Compilation sous Debian 102020-10-04T19:01:28+02:00Hugo TrentesauxCompilation sous Debian 10Sous Debian 10 architecture aarch64, après avoir suivi le tutoriel de compilation d'après les sources, je tombe sur le message :
```
yarn install v1.17.3
warning npm-shrinkwrap.json found. This will not be updated or respected. See https...Sous Debian 10 architecture aarch64, après avoir suivi le tutoriel de compilation d'après les sources, je tombe sur le message :
```
yarn install v1.17.3
warning npm-shrinkwrap.json found. This will not be updated or respected. See https://yarnpkg.com/en/docs/migrating-from-npm for more information.
[1/5] Validating package.json...
error duniter@1.7.19: The engine "node" is incompatible with this module. Expected version ">=8.2.1 <10". Got "10.15.2"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
```
Il semble que le fichier `npm-shrinkwrap.json` ne soit plus adapté. Je ne comprends pas grand chose à la compilation avec les outils (node/npm/yarn), mais je signale l'erreur ici, ça peut servir.https://git.duniter.org/nodes/typescript/duniter/-/issues/1391Also dist 32bit releases2020-10-04T18:57:58+02:00Daniell MesquitaAlso dist 32bit releaseshttps://git.duniter.org/nodes/typescript/duniter/-/issues/1367Display stored public key with wizard key command2020-10-04T18:56:02+02:00MoulDisplay stored public key with wizard key command1.9https://git.duniter.org/nodes/typescript/duniter/-/issues/882Do not store keypair in the conf.json file, but in an external one2020-10-04T18:53:25+02:00Cédric MoreauDo not store keypair in the conf.json file, but in an external oneIn a keypair.yml, it would be OK.In a keypair.yml, it would be OK.1.2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/970Have a common way to make requests to the network2020-10-04T18:52:10+02:00Cédric MoreauHave a common way to make requests to the networkAs far as BMA is concerned, we have 2 ways of communications:
* HTTP server listening for requests (push)
* requests made by the node itself to the network (pull)
The *push* is OK today, the server just has to listen for network reques...As far as BMA is concerned, we have 2 ways of communications:
* HTTP server listening for requests (push)
* requests made by the node itself to the network (pull)
The *push* is OK today, the server just has to listen for network requests. But the *pull* mechanism, used for pulling data from the network or to share documents (which is a *push* for other nodes, but *pull* for us even when we send documents) has no common code for doing the job.
Today the pull requests are made by request/request-promise, using an automatic HTTP connection. But some people may want Duniter to use a proxy for every pulling request a node makes. We cannot follow this behavior unless a method is defined in Duniter to make such requests, letting Duniter decide the way to make these requests.
The best place is probably in duniter-bma module for defining such methods (`bma.httpGet()` for example), because all the HTTP stuff is only due to BMA as of today.1.9https://git.duniter.org/nodes/typescript/duniter/-/issues/981multicaster should not use explicitely `request` dependency2020-10-04T18:51:17+02:00Cédric Moreaumulticaster should not use explicitely `request` dependencyInstead, it should rely on generic forwarding methods fulfilled by some module. For example, multicaster could rely on `duniter-crawler` which has the logic for making HTTP requests.Instead, it should rely on generic forwarding methods fulfilled by some module. For example, multicaster could rely on `duniter-crawler` which has the logic for making HTTP requests.1.9https://git.duniter.org/nodes/typescript/duniter/-/issues/983Have an exhaustive regex about unlock conditions2020-10-04T18:49:20+02:00Cédric MoreauHave an exhaustive regex about unlock conditionsToday the regexp applied on an oupout condition in transaction looks like this:
```js
const SIG = "[123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{43,44}";
const CLTV_INTEGER = "([0-9]{1,10})";
const CSV_INTEGER = "([0-9]{...Today the regexp applied on an oupout condition in transaction looks like this:
```js
const SIG = "[123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{43,44}";
const CLTV_INTEGER = "([0-9]{1,10})";
const CSV_INTEGER = "([0-9]{1,8})";
const CONDITIONS = "(&&|\\|\\|| |[()]|(SIG\\(" + SIG + "\\)|(XHX\\([A-F0-9]{64}\\)|CLTV\\(" + CLTV_INTEGER + "\\)|CSV\\(" + CSV_INTEGER + "\\))))*";
```
Which we can sum up like:
> « *put any combination of allowed characters, and you are allowed to repeat them* »
This is a too permissive. For example, this condition would be accepted by the regex:
```yml
)(CLTV(2000)))(CSV(1900)||&& ())()
```
No one has ever sent such a transction, but if he does the output would be locked forever. This is not a problem, but we could prevent such wrong syntax. We want an boolean expression with parenthesis, `&&` and `||` characters separated by a single space.
I have to get the correct regex. Let's say we only allow 3 levels of parenthesis (i.e. opening a parenthesis = open a level, closing it = close the level). Having a limit of 3 opened levels should be enough for most cases.1.9