To clarify, H<>C TLS is fairly non-intrusive from protocol point of view as far as simply supporting the nmdcs URI is all it is in terms of how it exists currently if memory serves.
The C<>C TLS as it is implemented by DC++ derivatives and some other clients, on the other hand, is reliant on some pretty specific quirks in parsing of certain protocol commands. These existing quirks allowed clients such as StrongDC (being among one of the first to support this, if memory serves) to effectively brute force TLS signaling into the NMDC protocol in a way that is non destructive with most current implementations of the protocol. The problem with C<>C TLS being achieved in this way is that it is extremely brittle and it will continue to be so because NMDC commands are not designed to be extended in this or any other way. This particular implementation just happened to find a hole in command parsing and made effective use of it (I honestly don't recall the specifics off the top of my head as to whether this quirk is such that it could be re-used, or has it now been in effect "used up" by this hack). Either way, this issue perfectly demonstrates why trying to patch NMDC is an exercise doomed to fail, not only because most people can't agree on how things should be done and there is also the issue of a segment of NMDC users that essentially operate on legacy software. To put it a different way, any change to NMDC has to be a bespoke one, there is no affordance for developing the protocol built into NMDC which means you would have to have clients and servers in a consensus on set of features and behaviors which will never happen. This is why ADC's command structure is so liberating. Although, I would like to add a reminder that this is a DC++ bug tracker, and while I am unsure what the current stance of DC++ is in regards to changing the NMDC implementation if I recall correctly there is, or at least used to be, a sort of an unwritten rule not to introduce changes to NMDC (in DC++), for reasons already stated. The only exception for this in relatively recent memory is the addition of Referrer information to established connections in so far as I can recall. In short, you could always gamble by providing a patch and bringing it up with the DC++ developers, because it is fairly unlikely anything will happen otherwise because it is not guaranteed that anything would happen even then, the issue of the NMDC "specification" is somewhat off-topic for this bug tracker. -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to DC++. https://bugs.launchpad.net/bugs/841189 Title: Encryption under NMDC Status in DC++: New Bug description: Well it seems like a popular demand so lets drag this topic thru the mud once again as we all know it is possible to encrypt c-c transfers but now there is also the option to encrypt c-h traffic aswell and since nmdc is predominant on direct connect it would benefit dc++ too actually encrypt this traffic since mods already have this support again strongdc++ along with all its subclients request taken from: http://www.adcportal.com/forums/viewtopic.php?f=13&t=769 To manage notifications about this bug go to: https://bugs.launchpad.net/dcplusplus/+bug/841189/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : linuxdcpp-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
