RetroShare 歷史舊版本 Page5

更新時間：2021-11-01
更新細節：

更新時間：2021-04-12
更新細節：

更新時間：2019-02-12
更新細節：

更新時間：2018-03-14
更新細節：

更新時間：2017-08-09
更新細節：

更新時間：2017-04-24
更新細節：

What's new in this version:

- I have built a version of Vim 8.0 with all the latest patches. This is mainly interesting for MS-Windows users who download the binary. Upgrading to this version is recommended, since it fixes many problems.
- I have renamed the original Vim 8.0 files to include the patchlevel. The new files are both available as "80" and "80-586". Note that caching may cause the "80" file to still be the old one.

更新時間：2017-03-14
更新細節：

What's new in this version:

DIFFERENTIAL FILE LIST SYSTEM:
- The old system for sharing list of files had originally been designed for a totally different purpose, and was very inefficient for this particular job since it required sending the full list of files every time something changed. We have designed a new system where directories are synced independently using a passive/active system: now friend lists are both passively synchronized in the background at a rather slow speed while being interactively updated while browsing. Random IDs are used when publishing directories to neighbor nodes so that they cannot be used to figure out what a friend is not sharing with you. The whole hashing system has also been improved.
- The file sharing manager has been re-designed with less popup windows and more contextual handles. Most data (directories, virtual names, friend groups,…) can be changed in place by double clicking on it. Changes only take place when the “apply and close” button is hit.

Backward compatibility is not fully provided, mainly in order to avoid keeping complicated pieces of code, but an acceptable middle ground has been found. In summary:
- users will need to re-define their shared directories, which is a good opportunity to test the new share manager ???? and does not take long;
- hashes are recovered from the previous version. So if you share the same directories, the hashing step should be very fast. The previous hash cache “file_cache.bin” is still loaded when found, and renamed to “file_cache.bin.bak”, and then converted into the new one “file_sharing/hash_cache.bin”. If needed, you can still rename this file to force Retroshare to import it again.
- All these lists are of course stored encrypted on your disk including friends’ lists, which wasn’t the case before. There is one limitation however: the total number of shared files and directories should stay below 4,194,303 for a maximum number of friends of 1023, because of the storage encoding that has been designed for maximal efficiency (the new system removed all pointers so that Qt can access the hierarchy content both securely and rapidely).

END-TO-END FT ENCRYPTION:
- There has been a lot of discussion about both the possibility and the reason to encrypt anonymous file transfer tunnels, since anonymity guaranties that whatever the data is, it cannot be attributed to anyone in particular. There are however a number of situations where such a feature is wanted, which can be summarized as: files that are shared in private channels, private forums, or even privately sent using distant chat should not be possible to intercept by a node in the network who’s passively listening for the traffic.

Safely encrypting file transfer along anonymous tunnels is of course a chicken-and-egg problem: you would require a pre-shared secret information from which the encryption key is derived, with someone you cannot identify (by design, since the tunnels are made to be strictly anonymous), so it sounds impossible to avoid a man-in-the-middle decryption (if you’re a troll, stop reading here and think for a while). We found a middle ground strategy (Partly similar to what GnuNet does, without using asymmetric authentication keys). Let H(f) represent a hash of the file to share:
- encrypted tunnels are opened through tunnels requests based on H(H(f))
- data packets are encrypted and authenticated using Chacha20+HMAC(sha256) with a random key for each packet. That key is derived by combining a 96-bits random initialisation vector with the actual hash of the file H(f). The construction is exactly the AEAD described in the RFC7539.
- files can optionally be non search-able, which keeps their hash secret
- Consequently, files shared anonymously using private channels, forums, or securely sent using private chat are guarantied to reach destination using end-to-end encryption that is both anonymous and MITM-resistant, the secret pre-shared information being the hash of the file.
- Note that we use our own implementation of Chacha20, which passes all the tests from RFC7539 (Chacha20 is not complicated really). When OpenSSL offers Chacha20 in its mainstream version, we’ll switch to it, without backward compatibility issues.

For backward compatibility reasons, users have now the possibility to change the encryption along file transfer tunnels with two modes (accessible from options->Files):
- accepted: downloaded files will open both encrypted and clear tunnels. Uploaded files accept both modes.
- enforced: downloaded files only open encrypted tunnels.
- Obviously, only “enforced” mode totally protects the data, and unless needed, it should be used preferably.

REVISED REPUTATION SYSTEM:
- The reputation system has been improved so that (1) users that do not give any opinion can rely on their friends to rate post authors; (2) if set, your own opinion is always a priority; (3) anti-spam prevents trolls to create new identities at every post; (4) new comers can easily bootstrap the voting problem.

Reputation now has 5 levels which are figured out by Retroshare combining 2 factors: your own opinion (with absolute priority) and opinions of your friend nodes. The resulting reputation score can be:
- negative: you personally flagged that identity as bad.
- remotely negative: your own opinion is neutral, but your friends provide more negative votes than positive votes
- neutral: no information is available whatsoever for this identity
- remotely positive: your opinion is neural but your friends globally vote positively.
- positive: your own opinion is positive
- The calculation of reputation has been split into positive/negative votes, and users now have the possibility to decide what is the required balance of positive/negative votes to make an identity flagged as remotely bad or remotely positive (See Preferences->People).
- The reputation system still governs the distribution of data, but the set of rules have been improved so that distribution channels with anti-spam flag ON only distribute posts from authors with a non negative reputation. This applies differently to signed identities and identities signed by a known or friend node.
- Forums with anti-spam activated show a special “Distribution” column. The column only displays a yellow (rep. red) flag for those authors who locally have a limited ability to distribute their posts (resp. who are locally banned)
- This means in practice that a newcomer to a forum with anti-spam will only spread his posts to his direct neighbors. The posts will only travel further if the nodes around give a positive opinion to their author. This allows new users of a forum to get known and up-voted, while preventing nasty users to create new identities for each (troll) post, since their data will not go anywhere beyond their direct friends, which in turn can easily decide to fight accordingly.

IMPROVED GUI:

The UI has been cleaned up, with new icons, new design. The settings are now totally interactive, meaning that any change you make immediately takes effect. We tried to improve the first time user experience in many ways. Here’s a non exhaustive list:
- New profile creation has been simplified and all complicated options are hidden (while still here, but at least the average user won’t need to figure out what they mean). The look of it has also been improved. The profile (PGP) passphrase is now asked only once and cached for a few seconds which avoids re-asking the PGP passphrase when signing the SSL certificate;
- all explicit mention of PGP keys have been removed, which are now named “Profile” keys, while keeping the ability to see fingerprints and ascii armored key, for advanced users;
- a Home page has been added as a place to start, make friends and grab your own certificate. This should help newcomers to create their network;
- it is now impossible to supply a badly formed certificate when making friends. Some users in the past tried to supply a PGP key instead of a RS certificate, which would obviously not work. This is now automatically detected when inserting the text in the certificate box.
- Finally, a few new options will probably help a lot: GXS now auto-cleans unused groups, and offers the possibility to choose sync/storage time. It’s important to note that some of these values may require old nodes connected to your node to keep sending data. So unless you stay on the default values for GXS sync, it’s better to have your friend nodes upgraded too.

COMPATIBILITY WITH OPENSSL-1.1.0:
- This step has required some effort! OpenSSL-1.1.0 hides a few structures which where previously open. The changes have been tested successfully on Debian Stretch.
- However: at the time of writing this post, Debian Stretch continues to distribute a version of sqlcipher (3.2.0) that crashes when combined with openssl-1.1.0. We cannot do much about this beyond waiting for the patch to reach mainstream. This should apparently not take long, so be patient.

更新時間：2016-08-31
更新細節：

What's new in this version:

- Group-based privacy for channels/forums/posted:
- Forums, channels and posted threads (and any entity represented by a a “GXS group”) can now be limited in their distribution. This happens in two different ways: limitation to a group of pseudo-anonymous identities (the ones in People), or limitation of a group of friend nodes (the ones in Network). The choice is available when creating, or when editing the properties of a forum.
- Both features considerably enhance the privacy of media that uses them. They stand for the base architecture element of a future social network layer.

External circles:
- External circles represent sets of pseudo-anonymous identities. A new tab in “People” allows you to create/modify them. A lot of options and handles are available there, for maximum flexibility. The downside is that the whole thing can be a bit scary
- People need to meet two conditions in order to be a member of a circle: they need to “apply for membership” and they need to be “granted as member”. Only the administrator of a circle can grant you, by adding you in the “invitee” list. This two-way membership not only allows people to request membership, but also prevents arbitrary circles to be created in order to spam unwanted information/data through neighbour nodes
- The GUI displays circles for which you are a member (a.k.a. “Circles I belong to”) and other circles. The bullet displays information about your status. Yellow means that you’re either applied and are waiting to be accepted, or invited and have the possibility to accept to be a member
- A contextual menu in each circle and each invitee/member of a circle allows you to act appropriately. This can be used to e.g. request membership for one of your identities, or grant membership if you’re the administrator of a circle

Tooltips on each circle tree entry give information about:
- Circle ID: This allows you to disambiguate which circle you’re dealing with.
- Visibility: who can see this circle. A circle can indeed be restricted to another circle (see “self-restricted circles” below).
- Your role: you are either a “user”, or an “admin”. The later means you created the circle, which allows you to grant membership, and invite people to be a member.
- Distribution: unlike e.g. forums, circles spread automatically. Unless restricted to another circle, they are made visible to your neighbour nodes, so that people in this node can e.g. request membership to that circle.
- Status: states whether you are a member or not.
- Security of circle-restricted forums/channels/… is ensured by encrypting the data for the message IDs, and group Meta Data (e.g. forum IDs, etc) for the set of members, using envelop encryption. Doing so, only people which are true members of the circle are able to see and handle that data, and to request and send message content. With this system, circles can contain anonymous IDs as well as signed IDs.
- Now, let’s complicate this thing a bit further: since circles are also “GXS groups”, they can be themselves restricted to other circles, including themselves. With this, we can create “self-restricted” circles, which will only be visible to people in the “invitee” list. As such, the administrator of the circle not only limits the membership of people but also who can be aware that this circle even exists. For obvious reasons self-restricted circles are propagated encrypted to the “invitee” list, instead of the list of full members.
- Many (Probably non all tested) options potentially exist in this system, including pairs of circles restricted to each other, the possibility to limit the distribution of pseudo anonymous identities to a particular circle, the possibility to limit circle distribution to a local group of nodes, etc. Not all of them are made accessible by the GUI, but can be used right away by plugins to implement a new types of media.

Groups of neighbor nodes:
- Groups of neighbor nodes are what we call “Local groups”. They have been used already for limiting the access of shared file lists. In v0.6.1, they can also be used to limit the distribution of forums/channels/posted as well.
- Since node groups are only known by the owner of the Retroshare node (they are not shared with friends), they force the node to work as a hub for message distribution. All friends in the group receive posts and information about the media, and only forward information back to the “originator” of the media, which will then share them with other nodes in the group.
- Use cases include sharing personal information with friend nodes only. This may apply to photos (yes,there is a “photo-album” plugin, currently unfinished…) and your holiday movies to share with e.g. your family members, etc.
- Groups of neighbor nodes can be managed in the Network tab, from the right-click menu in the list of friends.

Work on RTTs and packet slicing:
- We have identified two major problems causing unstable round-time-trip measurements (a.k.a. RTT) : many small packets would cause an overhead due to padding in SSL encryption, and seldom large packets would block a stream with a given friend for an arbitrary long time when the bandwidth is highly challenged. We fixed this in two ways:
- small packets (< 512 bytes) are grouped before being sent to SSL. This was easy since the data stream is anyway sliced into proper packets on the other end.
- large packets are sliced into 512 bytes chunks, in a backward compatible manner. Old peers will not accept sliced packets, which is detected on the other side and cause only entire packets to be sent. When both ends of the SSL tunnel agree, packet slicing happens.
- This optimization has been done in order to be able to provide better VOIP in the future (See below), but it also drastically impacts the whole software.

WEB Interface:
- possibility to paste of Retroshare links
- improved responsiveness
- switched WEB API from React to Mithril
- chat lobbies are available now

Identities:
- Since Identities represent users beyond friend nodes, they had to deserve special care so as to make them sufficiently SPAM-proof:
- The diffusion of forum messages (and any GXS-based group message in general) can be limited to signed identities, or even identities signed by known nodes. If not, a strictly positive reputation of the message signer is needed for the message to spread.
- The software now allows to automatically ban identities based on their node signature (“People->Person->Auto ban…”).
- These two options together (handled by the forum’s administrator) allow to severely reduce SPAM, at the expanse of a bit less anonymity. As far as reputation is concerned, each user can also change the threshold below which identities are banned (Options->People).
- Finally Retroshare now offers the opportunity to create a new signed identity when creating a new node/location, which should help newcomers to get ready to use internal forums/chat/messages right away.

Various features/improvements:
- New icon set. This is a matter of taste or course
- ability to define which instance receives system URL calls when running multiple Retroshare on the same computer
- auto-removal of messages in unsubscribed forums/channels
- separation of public/private RSA keys in GXS
- per-neighbour node bandwidth limits, to be changed in “Network->peer details” options
- improved chat widget (added new functions)
- fixed annoying crash on quit, due to faulty memory management
- fixed unit tests. Can be run using “make tests”.
- cache for sqlite3 access of group meta data, improving forum speed.
- usage of banned IPs in LibBitDHT
- Several bug fixes

更新時間：2016-02-05
更新細節：

What's new in this version:

- Updated languages from Transifex