Crise

I wonder if anyone expected to see this, ApexDC++ 1.6.5, that is?
Notably this version focuses on keeping the client in its current state, well current by updating various dependencies including OpenSSL, the compiler used has also been updated to the latest version. Otherwise some time has been taken to incorporate some changes from DC++, including a high priority fix and a change long overdue to default settings.
Update: an obsolete build was accidentally uploaded to SourceForge very briefly, in case you experience any issues with your installation then downloading the 1.6.5 version again should fix it. To find out if you are on the correct release version you may check Help > About > Git commit, it should be the following:
47d5052582fd424d3a54edc33307607d1e87eb2b (if it is listed as something else you are running the outdated 1.6.5 binary)
A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.5 as soon as possible.
Download: ApexDC++ 1.6.5
Happy Holidays and have a good New Year

It has been quite a while again.
We are pleased to announce the immediate availability of 1.6.3 a maintenance update continuing in the same vein as the two before it. This time the focus is on updating third party dependencies and build tools with the latest security updates and patches. Notably the binaries distributed for the Windows XP operating system had a configuration issue for the previous version and this has now been addressed for our friends still in the past.
A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.3 as soon as possible, regardless of which version of Windows you happen to be running. For the people who need the XP compatible binaries, we would like to give this remainder about changes introduced in release packaging with the previous version.
Download: ApexDC++ 1.6.3
Update: 1.6.3 has an issue with compressed transfers, that affects connectivity, turning off the setting "Enable safe and compressed transfers" should avoid this issue on 1.6.3. Alternatively you can hold off upgrading until a fix is available.

I have updated the first post with instructions for a workaround for the time being. New version will be made available as soon as there is a verified fix for the problem.
Relevant link: https://bugs.launchpad.net/dcplusplus/+bug/1656050

How to compile ApexDC++

Download the attached text file and follow instructions.
 
Compile.txt
 
How reproduce a release version

For this manually creating the appropriate version file (second approach in the attached file) is recommended. The necessary build id is the fourth version digit that can be seen in the about box or update check dialogs.
 
Creating redistributable binaries (with modifications)

To get a redistributable binary out of the source code distribution we recommend that you set up an svn repository with services such as http://code.google.com/ and use that. Additionally you must change the version check url in the version-template.h (as your assigned build id will be 1 initially which is much lower than ours) and then proceed to digitally sign a new version file with a private key (generated by a toolset such as openssl).

There is a small tool built into ApexDC itself that will do the signing for you, a windows batch file similar to the one below may be used to generate the necessary signature file (version.xml.sign).
 
@echo off ..ApexDC-x64.exe /sign "%CD%version.xml" "%CD%private.key" ..ApexDC-x64.exe /sign "%CD%beta.xml" "%CD%private.key" There is also an additional switch you will need to specify the first time signing version file with a new key which is -pubout. When this switch is present ApexDC will generate a pubkey.h file corresponding to your private key which should then be used to replace our pubkey.h so that verification will work against your version file pair.

After you have a signed xml, the trick is to make it discoverable by your compiled version of ApexDC by uploading both the .xml and .sign files side by side to the location you specified inside version-template.h (remember to recompile with the correct pubkey.h file).
 
Recompiling ApexDC as a replacement for the release versions on ApexDC.net (for personal use) is not recommended or otherwise supported.

ZPK: First of all your link was wrong and second, you can't download those files without a password anyways.
 
Also there is a reason why these builds are not generally available. Past experience has shown us that once a build is sent out there it stays out there. Because these versions are early and have a considerable amount of issues, some more severe than others. We would rather not find them hanging out in the open year down the line.
 
Another reason is that it is more practical, because our version control is not public currently and we are not prepared to keep a full source archive of every uploaded build (for multitude of reasons server resources being one of them) it is currently more manageable to handle GPL on per request basis (ie. make a source archive available when someone with access to said binary requests it, see the GPL, version 2, FAQ or license text for more details).
 
For the record, currently for non-windows systems access is generally given for anyone requesting it... just that it might take some time .

ZPK: First of all your link was wrong and second, you can't download those files without a password anyways.
 
Also there is a reason why these builds are not generally available. Past experience has shown us that once a build is sent out there it stays out there. Because these versions are early and have a considerable amount of issues, some more severe than others. We would rather not find them hanging out in the open year down the line.
 
Another reason is that it is more practical, because our version control is not public currently and we are not prepared to keep a full source archive of every uploaded build (for multitude of reasons server resources being one of them) it is currently more manageable to handle GPL on per request basis (ie. make a source archive available when someone with access to said binary requests it, see the GPL, version 2, FAQ or license text for more details).
 
For the record, currently for non-windows systems access is generally given for anyone requesting it... just that it might take some time .

Update: The voting period has ended, thank you for everyone who participated.

We have been, presumably randomly or based on recent activity, selected for the community choice vote for SourceForge May Project of the Month (fairly new thing they have been doing). If you have a SourceForge account look at the projects listed and vote as you will... or don't, it is really up to you. But it would be a shame for us not to say anything at all, considering this isn't likely to happen again any time soon. We have so far been a featured project (a weekly thing, for handful of projects at a time) twice within the last two or three years.

Direct Connect hasn't been prominently featured in any way in recent memory. It would be nice to make that happen, as well as an achievement for the project of course.

Some of that traffic looks extremely interesting... without looking into it, they seem to be either OP clients of some description, as Mek said, looking for particular defects, or malicious clients trying to run an exploit (although I did not check the existing public exploits against these patterns).

We have published a maintenance release available for immediate download. 1.5.13 fixes a small set of issues that can in the worst case scenario render your installation of ApexDC effectively unusable. You can check out the full changelog here. We recommend that you update your version of ApexDC as soon as possible.

Download: ApexDC++ 1.5.13

Update: The voting period has ended, thank you for everyone who participated.

We have been, presumably randomly or based on recent activity, selected for the community choice vote for SourceForge May Project of the Month (fairly new thing they have been doing). If you have a SourceForge account look at the projects listed and vote as you will... or don't, it is really up to you. But it would be a shame for us not to say anything at all, considering this isn't likely to happen again any time soon. We have so far been a featured project (a weekly thing, for handful of projects at a time) twice within the last two or three years.

Direct Connect hasn't been prominently featured in any way in recent memory. It would be nice to make that happen, as well as an achievement for the project of course.

Update: The voting period has ended, thank you for everyone who participated.

We have been, presumably randomly or based on recent activity, selected for the community choice vote for SourceForge May Project of the Month (fairly new thing they have been doing). If you have a SourceForge account look at the projects listed and vote as you will... or don't, it is really up to you. But it would be a shame for us not to say anything at all, considering this isn't likely to happen again any time soon. We have so far been a featured project (a weekly thing, for handful of projects at a time) twice within the last two or three years.

Direct Connect hasn't been prominently featured in any way in recent memory. It would be nice to make that happen, as well as an achievement for the project of course.

Update: The release of 1.5.11 has been officially rolled out. Full changelog available now. If you haven't done so yet please head on over to the download page and update your installation of ApexDC right now.

On April 7th, 2014 OpenSSL released a security advisory concerning CVE-2014-0160 also known as Heartbleed.

This is a serious security vulnerability in the SSL/TLS library that can result in your private data being compromised without leaving any trace whatsoever. You can check for more specific details from the above links. Most commonly used DC clients are affected by this issue, including ApexDC. Earlier today (April 10th) DC++ released a fixed version but all versions of DC++ from 0.799 to 0.841 and their derivatives are vulnerable. The specific ApexDC versions affected are at least 1.5.3 through 1.5.10.

It is important to note that even if the DC++ base version differs from those listed above a client may still be vulnerable as long as it uses one of affected versions of OpenSSL. There is currently, however, no easy way for users to tell what specific version of OpenSSL is used by a particular client.

Reading this you may be thinking: But, I am not using SSL/TLS at all right, because I am only on NMDC hubs. This is actually not necessarily true because a select set of clients, such as StrongDC and its derivatives, including ApexDC implement an unnamed NMDC extension that allows TLS to be used for client to client connections between supporting clients. Thus making these clients also affected by this issue outside of ADC and ADCS..

Two hours ago, version 1.5.11 of ApexDC was uploaded to SourceForge and is listed as the latest download there. Likewise the download links on this site now also point to those files. Release announcement including full changelog and all that important information will be made available sometime on the 11th, but for now suffice to say 1.5.11 will fix the issue discussed here as well as a set of other issues found in 1.5.10.

Update: The release of 1.5.11 has been officially rolled out. Full changelog available now. If you haven't done so yet please head on over to the download page and update your installation of ApexDC right now.

On April 7th, 2014 OpenSSL released a security advisory concerning CVE-2014-0160 also known as Heartbleed.

This is a serious security vulnerability in the SSL/TLS library that can result in your private data being compromised without leaving any trace whatsoever. You can check for more specific details from the above links. Most commonly used DC clients are affected by this issue, including ApexDC. Earlier today (April 10th) DC++ released a fixed version but all versions of DC++ from 0.799 to 0.841 and their derivatives are vulnerable. The specific ApexDC versions affected are at least 1.5.3 through 1.5.10.

It is important to note that even if the DC++ base version differs from those listed above a client may still be vulnerable as long as it uses one of affected versions of OpenSSL. There is currently, however, no easy way for users to tell what specific version of OpenSSL is used by a particular client.

Reading this you may be thinking: But, I am not using SSL/TLS at all right, because I am only on NMDC hubs. This is actually not necessarily true because a select set of clients, such as StrongDC and its derivatives, including ApexDC implement an unnamed NMDC extension that allows TLS to be used for client to client connections between supporting clients. Thus making these clients also affected by this issue outside of ADC and ADCS..

Two hours ago, version 1.5.11 of ApexDC was uploaded to SourceForge and is listed as the latest download there. Likewise the download links on this site now also point to those files. Release announcement including full changelog and all that important information will be made available sometime on the 11th, but for now suffice to say 1.5.11 will fix the issue discussed here as well as a set of other issues found in 1.5.10.

Welcome to what is hopefully the first of many blog style articles here at ApexDC.net. This time I hope to give a bit more depth to the new version that is literally just around the corner, especially since it has been a while.

Taking one of the new changes under the magnifying glass. This involves a bit of history and hopefully gives an entirely new meaning to one of the pretty meaningless looking lines that from time to time appear in our list of changes despite Lee's best efforts at writing it out so they would not appear.

Those who have followed the ApexDC project for a longer time period, might remember that with 1.1.0 we introduced automatic update system in ApexDC. However, if you remember that you must also remember how relatively quickly afterwards we stopped deploying updates in this manner. At that time making the choice to move away from the (then) newly implemented system seemed like clear regression to me, but looking back on it now I know the correct choices were made back then.

The reasons for not automatically update our users anymore and revert back to the infinitely more annoying (for you) method of handling updates can be covered by three key points (not in any particular order):

Automated updates gave the users one less reason to visit the web page, reducing overall activity on site and in the community.
Automatically replacing users binaries has several security considerations that were not really properly handled back then. For example consider the domain being taken over and a malicious individual could feed unknown code to users that then get executed on the users system as a part of the update process.
The implementation back then wasn't very flexible and was also somewhat prone to unnecessary failures.

All of this is history, from a few years back, but it seems good ideas die hard - this one in particular has come up on multiple occasions since then and, like those of you who have been paying attention to our recent public testing know, we recently decided to revisit the idea of automated updates.

Needless to say I wouldn't be writing this if the above concerns were still valid, but why am I do it then exactly. It all comes down to one thing really. Every time we release a new version, we have to lay out the changes in that version and more often than not the list of changes has some entries that bear little to no significance to an actual user, so we decided to elaborate a bit on one such change in the 1.5.0 release. The change involving the update check got chosen especially because it involves not an entirely new feature but most likely a forgotten one.

So yes, automated updates will be a prominent sight in the future of ApexDC as we keep thriving for better user experience. Sometimes it may take a while and be long time coming, like in this case, but it will be coming now and in the future. ApexDC is an important project for everyone involved and when we make decisions concerning it a great deal of discussion and thought always goes into them. However, when the decisions get made initially we don't always go into great detail about the reasons behind them, but usually those reasons are in fact good.

As we come to a close here, I would like to take a moment to thank all of you who participated in our public beta test and stuck through it with us. Based on the feedback from this time, I think we can safely say that it is more than likely that we will do something like this in the future as well. In the mean time, while we do not know how often we will be making posts like this in the future if you have topics that you'd like us to cover feel free to leave them in the comments below, even if you just want us to voice our opinions about something, I am sure as long as the topic inspires us to write about it we will find the time to put something down. I intentionally avoided many technical details this time around but if that is what you want to read about it can be arranged.

Comment, discuss, criticise the word is free, see you next time.

While back I went through my "development directory" and found some pieces of work that could potentially be useful for other people, if shared, but were either used only by us internally or just to collect dust.

So I put in some effort and packaged a few different files for public consumption, if you find them useful then great... if not then it is no-ones loss. I would ask you to comment below if you find something interesting in the stuff listed below, but seeing as our previous blogs haven't been big on comments (which is why there haven't been any more), who am I kidding.

Check the full post, after the break for more details.

1. Inno Setup Scripts (partial code dump)

This file contains a collection of auxiliary scripts used by our installer, please see the enclosed readme, and the script files themself, for further details.

2. PHP Utilities (Tiger and TTH hashing, Base32 encoding)

This file contains two simple classes, again the enclosed readme will shed more light on each (also explains why they are even here, since the original unmodified version of most of the code can be found on google).

"This code is namely shared because the current PHP based DC software that make use of the ADC protocol
generally uses hard coded hashes, or off loads the task of hashing to a binary dependency, for login.
While TTH is not used for that task directly the tiger and tigerfix methods, and the documentation
surrounding them, will hopefully be of use to some and lessen the number solutions reliant on static hashes."

3. phpBB based CMS system (aka. SnCMS, as in tin dioxide)

This was originally built for something we were planning for here at ApexDC then it was used for something completely different in the end, and after that it was used on the now late ADCPortal. Older version of this is still kind of in use, internally, but it only exists as a spare (though it has been particularly useful in testing the recent server moves).

I originally made it based on a concept I had long time ago, that I used on an old AirDC++ web site (yes, way back when it was still running phpBB2, I was somewhat involved in the web side of things there), now with phpBB3 as the backend.

I have bundled two styles with it, the original ADCPortal template files and a template'd version of the old layout for the system I made for the old AirDC++ site with some modernizations. I didn't release this before because I couldn't be bothered to create a style that didn't have a branding on it... but seeing as ADCPortal is dead, superseded by www.dcbase.org somewhat, and AirDC++ uses a different style now there is no longer a reason not to release it with the styles unedited.

Notably this project in its entierty is licensed under GNU GPL v2, as any phpBB modification should be (even though it doesn't modify phpBB per se). This old topic is also related (as you can see the plans to release it have existed for a while). No real installation instructions, read the comments in config.php, and figure it out from there (if someone actually seriously wants to use this, reply below and I'll give better instructions).

Downloads
Inno setup scripts PHP Utilities SnCMS - phpBB CMS

Welcome to what is hopefully the first of many blog style articles here at ApexDC.net. This time I hope to give a bit more depth to the new version that is literally just around the corner, especially since it has been a while.

Taking one of the new changes under the magnifying glass. This involves a bit of history and hopefully gives an entirely new meaning to one of the pretty meaningless looking lines that from time to time appear in our list of changes despite Lee's best efforts at writing it out so they would not appear.

Those who have followed the ApexDC project for a longer time period, might remember that with 1.1.0 we introduced automatic update system in ApexDC. However, if you remember that you must also remember how relatively quickly afterwards we stopped deploying updates in this manner. At that time making the choice to move away from the (then) newly implemented system seemed like clear regression to me, but looking back on it now I know the correct choices were made back then.

The reasons for not automatically update our users anymore and revert back to the infinitely more annoying (for you) method of handling updates can be covered by three key points (not in any particular order):

Automated updates gave the users one less reason to visit the web page, reducing overall activity on site and in the community.
Automatically replacing users binaries has several security considerations that were not really properly handled back then. For example consider the domain being taken over and a malicious individual could feed unknown code to users that then get executed on the users system as a part of the update process.
The implementation back then wasn't very flexible and was also somewhat prone to unnecessary failures.

All of this is history, from a few years back, but it seems good ideas die hard - this one in particular has come up on multiple occasions since then and, like those of you who have been paying attention to our recent public testing know, we recently decided to revisit the idea of automated updates.

Needless to say I wouldn't be writing this if the above concerns were still valid, but why am I do it then exactly. It all comes down to one thing really. Every time we release a new version, we have to lay out the changes in that version and more often than not the list of changes has some entries that bear little to no significance to an actual user, so we decided to elaborate a bit on one such change in the 1.5.0 release. The change involving the update check got chosen especially because it involves not an entirely new feature but most likely a forgotten one.

So yes, automated updates will be a prominent sight in the future of ApexDC as we keep thriving for better user experience. Sometimes it may take a while and be long time coming, like in this case, but it will be coming now and in the future. ApexDC is an important project for everyone involved and when we make decisions concerning it a great deal of discussion and thought always goes into them. However, when the decisions get made initially we don't always go into great detail about the reasons behind them, but usually those reasons are in fact good.

As we come to a close here, I would like to take a moment to thank all of you who participated in our public beta test and stuck through it with us. Based on the feedback from this time, I think we can safely say that it is more than likely that we will do something like this in the future as well. In the mean time, while we do not know how often we will be making posts like this in the future if you have topics that you'd like us to cover feel free to leave them in the comments below, even if you just want us to voice our opinions about something, I am sure as long as the topic inspires us to write about it we will find the time to put something down. I intentionally avoided many technical details this time around but if that is what you want to read about it can be arranged.

Comment, discuss, criticise the word is free, see you next time.

For one, that way of doing it would involve a lot of heavy lifting on the plugins part, and does not really describe a plugin anymore... and even then plugins have no way of reacting to filelist updates naturally as it stands (ie. they will not know when your share has been updated, outside of completed downloads, beyond monitoring the filesystem on OS level).

If you want to think of it differently, the work required to make this happen is substantial enough that at that point going the extra mile to make a fully fledged bot wouldn't be that much of an undertaking. In other words it is not impossible but it is impractical, because the plugin system couldn't really help the plugin in any significant way.

The bottom line: there are very few things that are truly impossible, when it comes to programming, but a lot more that are not possible with reasonable effort. The method you described may seem simple, but in truth it is anything but that, in comparison to limiting this hypothetical plugin to only downloaded files. Now, if API changes were made the situation might change, significantly even, but typically doing API changes for a single plugin is a bad idea (any API changes made should have more than one potential use case). Regardless, as it stands creating such a plugin at present is in fact not possible.

With 1.5.5 ApexDC officially moved to using the Plugin API currently in DC++. This essentially does not change much since their plugin API is a cousin to what ApexDC (1.5.x) has had for quite sometime now.

One of our personal goals with this was to move the ScriptPlugin (formerly LuaPlugin or Lua Plugin, but hey rose by any other name and all that) to be managed by DC++ team and the people there who actually know more about Lua than yours truly. Unfortunately though, for us, DC++ doesn't provide pre-compiled 64bit binaries at all which means that we will still be providing a download of ScriptPlugin for you for the time being.

For end users the change of a vendor for this plugin means two things. There will no longer be LuaJIT flavored builds on offer, which for anyone who ever used any pre-built modules is non-issue, since you wouldn't be using this build variant anyways. However, what does impact end user is that this new flavor of ScriptPlugin uses Lua 5.2 in favor of 5.1.

For script migration please see the following links:
Language changes in Lua 5.2 Bootstrap script (startup.lua) and default scripts In comparison, although the Plugin API as it is in DC++ is still not 100% stable (as in stable API in terms of compatibility), it is significantly more likely to remain compatible for longer periods of time since it will no longer see rewrites from version to version (which before submission to DC++ was more of a rule than an exception for me).

I know, we used to as well... but we decided it is much better to advocate the use of a third party applications designed to filter network traffic globally rather than providing an application specific filter. Most firewalls even allow you to set rules specific to applications, and there are several software solutions available that can do network filtering on different levels.

We do not support the idea of blocking transfers from an individual DC user, we believe that if someone really has earned a network block on his IP, it would only make sense for that block to be system wide or at the very least unbiased (ie. not only block yourself from uploading to a user but still being able to download from them).

The valid use for a network filter is when you are paying for bandwidth outside your LAN for example, and we wholeheartedly believe there are much better solutions for that already out there that can be set up to better prevent unwanted outbound traffic than an application specific tool for just ApexDC could.

Unfortunately as far as I am aware apple has not updated the interface we use since 09, so if that is broken and there is no new update then there is little we can do (might be possible to find an alternate method though), I can have a look but no promises at this point.

Well the specifics are still unclear but you know SDC is ultimately based on DC++ core which compiles under linux, so to get the SDC core compiling under linux should be very much possible without any insane amounts of work.

This is ofcourse only the core part... but it would be a start and in the worst case scenario we can always derive from clean linuxdcpp and add our stuff on top of it.

The mention about other platforms was not so much about the who and when... but more that we still have the intention of eventually making it happen.

Event ID 4226 only applies to SP2 as far as I am aware, not SP3.

In any case it is not practical for me to keep anything below XP SP3 supported, because the best I can get in terns of XP these days is the XP mode that ships with windows 7.

Besides Microsoft will drop all support for XP in 2014, and it is already on extended support anyways. It would be increasingly troublesome to keep supporting operating systems that have been abandoned in terms of security patches and hotfixes. Because each additional operating system supported adds its own limitations to what can and can't be done with the software, within reasonable effort.

Newer is indeed not always better, however, old will always be old and will only get older... that is a fact.

More detailed info on it in here:

People, please at least read the changelog before you report a bug, thank you .

Please refer to our new jobs page regarding the Linux port.


Get current StrongDC core to compile under mingw (to resolve compiler related issues) Fix any win32 specific parts in StrongDC core to compile under linux, to list a few Certain ulitity and other functions Possibly DHT and Webserver related code [*]Rewrite UI with wxwidgets (at least code::blocks has wxwidgets related tools that can be used, might help)
Any questions/feedback can be discussed below please.