linuxdcpp-team team mailing list archive

[Crise / Markus Willman <841189@xxxxxxxxxxxxxxxxxx>]

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