When stable become really stable

DC++ 0.707 has just out. Probably this version will be the first from the 0.7xx series which will be considered as a highly stable release – also hopefully a version that many user will feel safe to upgrade to. Altough the two previous versions also marked stable, both of them have a few rather serious problem so users of all 0.70x versions are encouraged to upgrade to 0.707 as soon as possible.

As you may know our client changed a lot over the last year, switching to a new, open source compiler and GUI library was a big step forward even in the ever-changing world of DC++. Introducing segmented downloads needed a lot of additional change and… caused some side effects as well. When DC++ 0.705 and 0.706 marked stable, more and more users downloaded and started to use these new versions and they helped a lot to find and fix a few more existing problems. Some kind bugs are hard to discover when a new version is used only by small group of testers so those numerous reports and feature requests from the community was really great. Now with 0.707 we reached a point where we hope that all the major problems are solved.

Along with several minor things the current GUI changes include :

• Search results with same TTH are grouped so from now so multiple results for the same file occupy only one row in the search results list. The ‘User’ column shows how many users share the file and their nicks can be seen in the right click menu.
• The annoying problem of spamming the finished up/downloads windows with all the finished segments is gone.
• From now you can copy the elements of the hub’s userlist to the clipboard.
• There’s a new quick access to all favorite hubs by a new drop-down menu in the toolbar.
• The built-in Help (and some important FAQs in it) are improved and a Get started guide added for beginners as well.
• Translations are greatly improved (thanks to the respective translators!), even a few more languages added.

Important problems fixed :

• A possible crash when resuming downloads in non-segmented mode.
• A security problem, where a remote client could crash your DC++, without you knowing or could do anything about it. (The issue hits all DC++ versions from 0.670 !!)
• Fixed a severe bug that keeps DC++ from returning correct search results for files and returns no results at all when searched for directories (bug exists from 0.705).
• Also fixed a problem introduced with 0.706 where resumed downloads can be corrupted if the temporary file deleted or if you try to resume downloads started with an older version of DC++.

So again, its time (and safe) to upgrade! As usual, if no serious bugs are reported, 0.707 will be marked stable within two weeks.

A proposal for ADCS and secure Direct Connect

I have thought about ADCS and how we can improve the world of Direct Connect, and the ADC network.
First, I looked over to see how DC++ ( and clones) create the certificates they use for ADCS connections. The certificate doesn’t seem to be signed, and it’s granted actually to that CID ( client’s unique id ).
I want to propose something about how to make this more secure for both hubs and clients who want to connect ( mostly clients who have certain rights on the hub ). This is intented to replace password-based login.
First of all, let’s start with a hub. After the hub is being set in normal ADC mode, the user needs to switch to ADCS. In this moment, the hub makes a certificate request to a CA [1], that temporarily grants him a certificate signed by this CA, hereby making the hub authoritative for it’s own users.

[1] : I propose the CA to be somebody of trust in Direct Connect, that can also monitor hubs and even revoke certificates for the hubs that don’t respect certain rules ( moral rules, the general direct connect rules…etc ). My first suggestion is a big hublist , with great influence ( these people also monitor hubs regularly ). Once the hub has this certificate from this CA, then users can connect to it safely ( It would be nice if clients could implement the CA’s public key and check the certificate’s signature, and at least warn users on login if the hub is not signed by the CA)

The second step of this thing is to create user accounts on the hub. For this, each client creates a public and a private key. The hub should be able to have an input for a client’s public key, and create a certificate for the client signed by the hub. This way, the client can login to the hub ( in which moment the hub checks if the certificate is signed correctly by itself ) and grant the respective user with all the rights given . No password needed, and the security greatly increases since the client’s private key is never sent anywhere so he’s the only one who can use the certificate, and only the hub who signed it can actually decipher it and accept it.

Hope this post is quite clear, I await some questions if not. I would also like something from hublist developers.

After talking to Flow, I’m not sure how important the CAs for the hubs are. Perhaps someone has a better idea.

New address for DCDev Public Direct Connect Development Hub

The public hub is back up, the new address is :

adc://devpublic.adcportal.com:16591

We are sorry for the time it was down, and we hope it will not happen again too soon.