The 'SSL torrent' feature is not standardized. I.e. there are no BEP (BitTorrent Enhancement Proposals) associated with it, so we do not greatly encourage its usage as it will only work with libtorrent clients and derivatives. It will not work with other torrent clients that do not support the libtorrent specific implementation.
This PR aims to provide minimal support for those who need SSL torrents. Furthermore, it is intended that there will be no UI support (nor indication) of adding/creating SSL torrents.
* Prerequisites:
I omit the instructions of creating those files as the intended audience (experts & advanced users) should have no problem with it. All files are as follow:
1. Root (torrent publisher) certificate
2. Root private key
3. A .torrent file created with root certificate
5. Peer certificate (signed by the root certificate)
6. Peer private key
7. Diffie-Hellman parameters file
All files are stored in .pem format.
* Enable SSL torrent protocol in qbt
There are 2 hidden keys to put in qbt config file, under `[BitTorrent]` section:
1. `Session\SSL\Enabled`: set it to `true`.
2. `Session\SSL\Port`: set it to some unused port or omit the key entirely to let qbt pick one for you.
* Add an SSL torrent to qbt
The only way of adding an SSL torrent is via WebAPI. The `/api/v2/torrents/add` endpoint will support 3 additional parameters. You must provide them for an SSL torrent.
1. `ssl_certificate`: Contents of the peer certificate file (in PEM format).
2. `ssl_private_key`: Contents of the peer private key file.
3. `ssl_dh_params`: Contents of the Diffie-Hellman parameters file.
* Change the SSL parameters to a torrent
In case you provided wrong SSL parameters when adding a torrent, there is a new endpoint `/api/v2/torrents/setSSLParameters` that you can update the SSL parameters. The parameters (`ssl_*`) are the same as `/api/v2/torrents/add` endpoint.
* Query the SSL parameters of a torrent
There is a new endpoint `/api/v2/torrents/SSLParameters` that you can query the SSL parameters of a torrent.
References:
* https://www.libtorrent.org/manual-ref.html#ssl-torrents
* https://blog.libtorrent.org/2012/01/bittorrent-over-ssl/
PR #20338.
---------
Co-authored-by: Radu Carpa <radu.carpa@cern.ch>
PR #19496.
* Add torrent entry status to represent tracker error
* Add torrent entry status to represent unreachable endpoint
* Display tracker entry next/min announce time
* Reset tracker entries when torrent is stopped
PR #19468.
* Use QHash to map tracker endpoints
* Don't clear numPeers unexpectedly
* Remove outdated tracker entry endpoints
* Move presentation logic from Core to GUI code
* Show all endpoints per tracker in tree structure
---------
Co-authored-by: Kacper Michajłow <kasper93@gmail.com>
Adjusting limits was made based on the belief that "forced" torrents (internally used for prefetching metadata)
are still under limits, but ignore only the queue. This is not really the case. "Forced" torrents ignore the limits
like "maximum active torrents/downloads", so adjusting limits is not required, and what's more, it really causes the
problem of unexpectedly activated previously queued torrents when adding some magnet using "Add new torrent" dialog.
PR #18503.
Fixes#18490.
Such helpers do not make practical sense, since they can be trivially implemented on top of the base interface, but at the same time they can lead to undesirable consequences when some calling code requires slightly different behavior than another.
PR #18367.
Fixes#18338.
We don't really need to get currently used settings pack in order to apply changes to session settings. It is enough to apply settings pack that contains only updated settings.
PR #17989.
Add a UI option for "Use proxy for hostname lookup" option and plumb
it into libtorrent's settings_pack.proxy_hostnames option. This is
available for SOCKS5 and HTTP proxies, and defaults to true, which
is the previous functionality. Hostname lookups can be forced to be
local by unchecking this option, which can aid compatibility with
certain non-compliant proxy servers.
Closes#17902.
PR #17904.
Co-authored-by: Nathan Lewis <saturn@saturn49.dyndns.org>
PR #17814.
Closes#17792.
Closes#929.
(Actually it should close all issues about lack of ability to stop torrent after metadata downloaded or after files are initially checked.)
Also makes explicit the temporary start of the torrent in the case when recheck of the stopped torrent is performed.
