This release comes with multiple changes and bug fixes, resulting of 2 years of development. A lot of effort has been made to get this release really stable.
Web Interface
We ship Retroshare v0.6.7 with a new Web interface, which has been developed over 2-3 rounds of Google Summer of Code. It is mostly useful for controling a Retroshare node running on a remote/headless server. In order to start the web interface,
- in preferences => Web interface, check the “Enable Retroshare WEB interface”, enter a passphrase, then click “Apply settings”. Note the port here (9092 by default).
- open your web browser and go to http://localhost:9092/index.html (note: the “index.html” is mandatory)
- enter your web interface passphrase.
Installing Retroshare+Web interface to control a headless node:
- configure a new node on your server (either copy an existing data directory, or start retroshare Qt interface in remote and create a node), then quit;
- launch retroshare-service (See option -h for alternative options). Option “-W” asks for the web interface to run, “-U list” is optional and will ask you to select which node to start if you have multiple nodes available:
./retroshare-service/src/retroshare-service -W -U list
- enter a chosen password for the web interface (this is asked at every start), then choose the node you want to run (if using “-U list”), enter your profile passphrase, and wait for it to start;
- the web interface is only published locally. So in order to securely access the interface from a client machine, you need to create a ssh tunnel to your server, so that the web interface port will be forwarded to your server. The following line (that will not terminate) just forwards localhost:9092 of the headless server, to localhost:9092 on your client machine:
ssh [IP of the running Retroshare node] -L 9092:localhost:9092 -N
- now you can access the web interface at http://localhost:9092/index.html on the client machine.
Under the hood the interface is implemented in Javascript, and uses libretroshare Json API to communicate with a running instance of the software using a secured token system.
Note: it is possible to leave retroshare-service in the background, as soon as it displays the “Retroshare core started” message. On Linux, using “Ctrl+z” and “bg” will leave the program running in the background. Do not launch it in the background right away, since the passphrase input will probably not work.
Note: the web interface is a new feature, which lacks some components of the Qt interface. It offers however the essential tools to control a headless node. It also runs with automatically configured Tor nodes.
Qt UI improvements
Lots of minor bugs have been fixed in the graphical user interface. The Qt interface is however quite dense with lots of options, although we try as much as possible to remove duplicate functionalities. Significant improvements have been made to the interface in Mail, Channels, advanced file search,… The stability of the software has also been improved quite a lot.
Running with Tor
Tor support has been moved to libretroshare. This allows retroshare-service to use Tor as well and therefore it is now possible to run headless hidden nodes. Although seamless in the Qt interface, this change needed quite a lot of development effort, since the original Tor communication system was based entirely on he Qt signal/slot system, which we decided to not depend on in libretroshare.
Retroshare moved to Tor v3 addresses, since the old v2 addresses are now deprecated. Consequently, if you have a Tor-v2 node, you’ll need to change your Tor node address to v3. This is easily done the following way:
- delete (or rename) the hidden service directory, [data directory]/HID06_[your ID]/hidden_service
- restart Retroshare. If will fail to find your missing Tor key, and will automatically generate a new one.
- send your new address to friends. Although you will keep your friends, your friends will not be able to contact you since your Tor address changed. This step is only mandatory when friends are clear nodes.
Also, an existing retroshare node will likely not start if using a version of Tor that is incompatible with the v3 address, and will keep displaying “Checking for hidden services:New service acquired. Status is 2: not ready yet.” in the console. In this case, upgrade Tor, or supply a v3-compatible version of Tor to the commandline using -t.
As usual, Retroshare+Tor is an incredibly powerful combination: it allows you to safely add unknown friends, and traverses NATs and firewalls much more efficiently than Retroshare alone, thanks to the network transport layer being entirely left to Tor, without a significant drop in speed.
Embedded friend server (Tor nodes only)
Retroshare+Tor now comes with an embedded friend server. The friend server is a standalone executable that accepts Tor connections on a hidden address to exchange friend certificates. It is designed to run without parameters, from the command line. In can be started as follows (on Linux. Not tested yet on windows):
/usr/bin/retroshare-friendserver
Additional arguments may include “-c [some directory]” so as to setup the place where the friend server will store its internal data (Default is “FSData/” in the current directory). Use also “-h” to get more help about parameters. After letting it start (the console will show quite a few output lines that may be used for reporting bugs), it will display the following information
======== Retroshare Friend Server as properly started ======= = = = Address:Port tfv2z5hquq...ytpviaod7pjeid.onion:9878 = = = =============================================================
That address and port should be communicated to friends who may want to use the friend server. In their own node, the information needs to be filled in the Network/Friend server tab, as shown below:
Once the address+port are entered, Retroshare will check them. If the friend server is online, it will be found and the led gets green (assuming Tor finds a route to it, which may take a few seconds). Enter your Retroshare passphrase (this is needed for internal security checks) and then check on/off. The friend server will supply friends to you automatically, and display them in the table below.
Note: The friend server is a totally experimental feature that may not be perfectly debugged yet. So please send us feedback if anything fails.
Submodule architecture
Since libretroshare is now used in multiple projects, we had to switch to a submodule architecture. This makes a lot of interesting standalone parts of the software available for use in other softwares as well. This is the case especially for libretroshare, libbitdht, and openpgp-sdk. For developers, it’s preferable to clone from a clean directory, using the following commands:
> git clone git@github.com:RetroShare/RetroShare.git > git submodule update --init --remote --force libbitdht/ libretroshare/ openpgpsdk/
The existence of submodules implies some additional constraints when updating (e.g. submodules needs to be updated) but brings more flexibility to the developpers.
We’re currently heading toward a full cmake-based compilation. Although compiling with qmake is still possible, compiling with cmake is a new possibility that should support submodules more elegantly.
Internal improvements
A push system has been introduced into our data distribution system GXS, which allows a node to notify connected nodes when new data is available. As a result synchronization of forum posts, channel posts and votes, etc, occurs almost instantly, whereas it used to take at most 2 minutes in previous versions.
The internal storage for Mail has been improved in ways that allows the interface to be more consistent. The interface can now display the full list of destinations for each email and allows a proper “reply all” function.
The graphical user interface has been switched to using a blocking API with asynchronous calls everywhere, in replacement for the old token system. This makes the code more compact, and more elegant, and the API easier to use. The old token system is still used internally in libretroshare in order to avoid internal locking events.
The internal image storage format has been switched from PNG to JPEG, which severely reduces the data size of channel and board posts. Existing posts are not automatically converted, but new posts now use JPEG.
SSL security level
In most operating systems, OpenSSL recently switched to a default security level of 2, which forbids certificates with a SHA1 signature. Although Retroshare tries to start with a lower security level, this is not always accepted by OpenSSL. The side effect is that retrohare 0.6.7 may fail to start and ask you to create a new node (with the same profile). In this case, you’d lose friends and identities.
Identities cannot be exported, but friends can. A new identity will need to be created and signed by the same profile in the new node. In order to start the old SHA1-based node, it is possible to trick OpenSSL by creating a configuration file as containing:
# put the text below into new file as .retroshare/openssl_temp.cnf # then run the app as normal user from console using: openssl_conf = default_conf [ default_conf ] ssl_conf = ssl_sect [ ssl_sect ] # temporarily enable this system_default = system_default_sect_old # after migrating you could check by enabling new default section: # system_default = system_default_sect [ system_default_sect_old ] # SSL_CONF_CMD for abouts of CipherString # man openssl-ciphers CipherString = DEFAULT:@SECLEVEL=0 [ system_default_sect ] # SSL_CONF_CMD for abouts of CipherString # man openssl-ciphers #MinProtocol = TLSv1.2 #CipherString = DEFAULT:@SECLEVEL=1 # or use the current default level: CipherString = DEFAULT:@SECLEVEL=2
Then start Retroshare using
$ OPENSSL_CONF=".retroshare/openssl_temp.cnf" retroshare
This should allow you to export your friend list (Right-click in Network tab => Export friend list), and import it again in the new node.
Future Work
One major step forward will be to fully get rid of HTML for encoding messages. In addition to taking an unacceptable amount of space, HTML brings unnecessary security risks. Qt however uses HTML natively for displaying decorated text, possibly mixing images, text, links, etc. Consequently we’re aiming for a markup language which would only be converted to HTML for display purpose.
Another important future step is to refactor the internal chat system so as to allow private chat group discussions. The plan is currently to abstract the algorithm used for chat rooms (which works pretty reliably) and use it both in chat rooms and in distant chat using virtual peers provided by GXS tunnels. This way a separate component will take care of keeping distant tunneled connections while the routing method will distribute data among all participants.
Finally we want to get rid of openpgp-sdk, which is an old and unmaintained library. A number of possible replacements are available. The switch will be facilitated by the fact that the code in libretroshare uses an abstract class to interact with the PGP library. This may also offer opportunities for additional cryptographic primitives such as ECC (Elliptic Curve Cryptography) which are faster than RSA at comparable security levels.
Known bugs
On some linux systems (e.g. Debian 11), Retroshare used to crash when selecting the gtk2 style in preferences => Appearence. The crash can be prevented by defining the environment variable QT_QPA_PLATFORMTHEME=gtk2. Consequently, we removed the gtk2 entry from the styles list, unless this environment variable is defined when Retroshare is started. In other words, if you want gtk2 style, define the variable above in your environment.
Final word
As usual, we would like to stress that Retroshare is quite a powerful tool. It should be used wisely and in the full respect of the laws in your country.
Many thanks to Google Summer of Code and Freifunk for their incredible support, to the students and mentors who participated in the program, and to all testers and devs who contributed to this release.
RetroShare Team