- UPnP handles errors better
- it tries to bind external interface (previously sometimes it searched
on 127.0.0.1 resulting in no routers being detected)
The quick navigation key disrupted keybindings with keyboard modifiers,
like Ctrl-C for copy. This restricts the quick navigation only where no
keyboard modifiers are active.
Fixes#184
- delete key now works when message body is focused as well
- N for next message (down)
- P for previous message (up)
- R for reply
- C for compose
- F for find
- Find is now dynamic if the search text is least 3 characters long
Fixes Bitmessage#655
Addresses #155
Rows are deleted from a message list in multiple places, and this is an
attempt to refactor it so that it is done in one function. It's not used
anywhere yet.
MessageView does not currently load external resources (QTextBrowser by
default interprets all external resources as local file names and tries
to load them like that. This can, in the future, be implemented. For
example, if SOCKS (Tor) is used, the resource could be loaded through
the SOCKS too.
This commit is a skeleton for it that does not actually do anything and
can be filled with an implementation that does the loading.
Email addresses and URIs are now clickable when viewing a message in
plain text mode. Clicking an email address moves to the Send tab, while
clicking an URI has the same result as clicking an URI in html mode, it
will ask for confirmation before opening it in external handler.
HTML parser wasn't correctly handling img tags.
Now it also by defaults disabled external schemas to prevent
deanonymisation (even though the renderer actually doesn't support
external schemas at the moment)
Addresses #178
Attackers injected node addresses with port 0 into the network. Port 0
is unusable on many OSes and can't be listened on. PyBitmessage won't
accept nodes that have port 0 anymore.
- postpone initial sleep until the first getdata is received
- also sleep when received a getdata request for an object that hasn't
been advertised to the other node yet
There was a report that by quickly asking a large number of nodes if
they have an ACK object (which the attacker knows but it is injected
into the network by the recipient of the message), it can estimate how
an object propagates through the network, and eventually pinpoint an
originating IP address of the injection, i.e. the IP address of the
message recipient.
This patch mitigates against it by stalling when asked for a nonexisting
object (so that the attacker can't spam requests), and also upon
connection before sending its own inventory list (so that reconnecting
won't help the attacker). It estimates how long a short message takes to
propagate through the network based on how many nodes are in a stream
and bases the stalling time on that. Currently that is about 15 seconds.
Initial connection delay takes into account the time that already passed
since the connection was established.
This basically gives the attacker one shot per a combination of his own
nodes and the nodes he can connect to, and thus makes the attack much
more difficult to succeed.
Editing of blacklist labels affected the rerendering, because it emits
the changed signal too, and it caused an exception because the address
field was missing at that time. This works around both.
In some situations, it's not necessary to send an ACK. For example, when
the sender is blacklisted, when the message has no content, or when the
address has ACK sending disabled.
Also it's not necessary to rebroadcast empty messages into a mailing
list.
When advertising nodes and when establishing connections, private IP
range checks were not done. This could cause private IPs to be
advertised across the network. Also, some of the checks weren't
IPv6-aware.
Fixes Bitmessage#768