This module tries to restrict the ability of other processes to access the memory of our process.
Traditionally, on Linux, one process can access the memory of another arbitrary process
if both are running as the same user (uid). (Root can ofc access the memory of ~any process)
Programs can opt-out from this by setting `prctl(PR_SET_DUMPABLE, 0);`
also see https://man.archlinux.org/man/PR_SET_DUMPABLE.2const.en
-----
Also, from https://unix.stackexchange.com/a/518452 :
In a terminal window:
```
% echo $$ # show our pid
6744
% read -sp 'secret password: '; echo
secret password:
%
```
Then in another terminal window:
```
% grep heap /proc/6744/maps
01bb7000-01c3e000 rw-p 00000000 00:00 0 [heap]
% dd if=/proc/6744/mem bs=1 skip=$((0x01bb7000)) count=$((0x01c3e000-0x01bb7000)) status=none |
strings | less
...
% dd if=/proc/6744/mem bs=1 skip=$((0x01bb7000)) count=$((0x01c3e000-0x01bb7000)) status=none |
strings | grep obiwan
obiwan_kenobi # "secret password"
```
The password should not be an empty string.
Traceback (most recent call last):
File "/opt/electrum/electrum/gui/qt/__init__.py", line 377, in start_new_window
wallet = self._start_wizard_to_select_or_create_wallet(path)
File "/opt/electrum/electrum/gui/qt/__init__.py", line 446, in _start_wizard_to_select_or_create_wallet
wallet = self.daemon.load_wallet(wallet_file, d['password'], upgrade=True)
File "/opt/electrum/electrum/daemon.py", line 461, in func_wrapper
return func(self, *args, **kwargs)
File "/opt/electrum/electrum/daemon.py", line 474, in load_wallet
wallet.unlock(password)
File "/opt/electrum/electrum/wallet.py", line 3418, in unlock
self.check_password(password)
File "/opt/electrum/electrum/wallet.py", line 3069, in check_password
raise InvalidPassword("password given but wallet has no password")
electrum.util.InvalidPassword: password given but wallet has no password
Accepting a PSBT opens the Tx dialog and pauses receiving additional PSBTs until the Tx dialog is closed.
Rejecting a PSBT will start a cooldown and accept all pending PSBTs into the history for later inspection.
- both internal and external plugins require GUI install
(except internal HW plugins, which are 'auto-loaded' and hidden)
- remove init_qt hook
- in Qt, reload wallet windows if plugin enabled/disabled
- add 'uninstall' button to PluginDialog
- add 'add plugins' button to wizard hw screen
- add icons to the plugin list
This change modifies create_trampoline_onion to only include as many
available r_tags as there is space left in the trampoline onion payload.
Previously we tried to include all passed invoice r_tags of legacy
trampoline payments into the payload which caused an user facing
exception and payment failure as the onion can only store a max of 400
bytes.
A single, single hop r_tag is around 52 bytes and the payload
without r_tags is already at ~280 bytes. So usually there is enough
space for 2 r_tags.
The implementation shuffles the r_tags on each call
so the payment will try different route hints on the attempts (fee level
increase or user retry).
I have logged the following byte sizes of the trampoline onion with a 2
trampoline onion hop and changing amounts of r_tags:
3 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 440 (hop size: 295) ( 52 bytes/rtag )
payload size [2]: 550 (hop size: 78)
2 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 386 (hop size: 241) ( 52 bytes/rtag )
payload size [2]: 496 (hop size: 78)
1 rtag:
payload size [0]: 113 (hop size: 81)
payload size [1]: 334 (hop size: 189) ( 52 bytes/rtag )
payload size [2]: 444 (hop size: 78)
0 rtags:
payload size [0]: 113 (hop size: 81)
payload size [1]: 282 (hop size: 137)
payload size [2]: 392 (hop size: 78)
As can be seen in the data, using 2 trampoline hops there is not enough
space for even a single r_tag which is why this option is being removed
too.
The Qt lupdate tool that extracts translatable strings from .qml files
writes paths relative to its output .ts file into the .ts file.
These paths are then retained as-is when converted to .pot format.
The last few commits moved around the working directory of the lupdate tool
(from electrum/locale to electrum/locale/build), which resulted in a change
of all relative paths in the final messages.pot we upload to crowdin.
E.g. from:
```
#: ../gui/qml/components/Addresses.qml:64
```
to:
```
#: ../../gui/qml/components/Addresses.qml:64
```
I think a change like this does not invalidate the translations. Still, it is annoying.
This commit adds an extra processing step to "fix" these strings to:
```
#: electrum/gui/qml/components/Addresses.qml:64
```
- this merges `contrib/deterministic-build/locale` and `electrum/locale`
- it is now once again possible have translations when running from a local git clone
- which was already possible in the past before crowdin removed their unauthenticated APIs
- see https://github.com/spesmilo/electrum/issues/9531
- however, the translations available are the often-old frozen strings from electrum-locale
- while previously one could just download the latest strings from crowdin
The option to add a 2nd trampoline hop to legacy trampoline payments requires too much space in the trampoline onion.
Because the trampoline onion has only limited space of 400b and the payload with 2nd t hop and no r_tags already requires 392b it is essentially unusable for payments that require routing hints to be included in the onion
(because the receiver has no direct channel to the 2nd trampoline node)
as there is no space left to include them (1r_tag == ~52b).
Make path calculation check if channel is not in our sending channels but still uses our nodeID as starting node of the path.
I noticed an assertion error when trying to pay an invoice from a seed i have opened channels with in different wallet instances (same seed, different wallet).
Because the channel seemed suitable for sending the payment path finding included the channel for sending in the first position of the route but then
in pay_to_route the channel for route[0] could not be found as it is not included in our channel list, causing the assert and payment to fail.
- Allow plugins saved as zipfiles in user data dir
- plugins are authorized with a user chosen password
- pubkey derived from password is saved with admin permissions
