http: fix intermittent startup SIGSEGV (and broken HTTPS) by using libcurl - #455

Fixes the intermittent startup SIGSEGV tracked in upstream PR amule-project#455.
The crash happens on Linux when a startup HTTP download redirects to
https://, which wxHTTP cannot speak: wxHTTP::Destroy() schedules the
current handler for deferred deletion, the redirect handler throws,
and before the deferred delete runs an epoll event fires on the
still-registered fd — invoking a method on a socket mid-teardown.
Reproducible on stock origin/master (~1-in-27 runs of amuled in a
tight startup loop); the crash-hunt.sh script from PR amule-project#455 passes
>115 iterations clean on Linux/ARM64 with this rewrite. The fault
is inside libwx_baseu_net so it cannot be fixed inside aMule's code
paths — the only reliable remedy is to avoid the wxSocket-based HTTP
path entirely.

The fix is to stop doing HTTP on a worker thread with wxSocket under
the hood. CHTTPDownloadThread now:

* Inherits wxEvtHandler instead of CMuleThread. No worker thread, no
  wxSocket, no wxEpollDispatcher on the download path.

* Owns a wxWebRequest from wxWebSession::GetDefault(), kicks it off
  from the constructor on the main thread, binds wxEVT_WEBREQUEST_STATE
  on the same handler, and lets state transitions drive everything:
  Active → progress event to the optional dialog, Completed → rename
  wx's storage temp file into the caller-supplied path, Failed /
  Cancelled → clean up, Unauthorized → treat as failure. On every
  terminal state the object posts wxEVT_CORE_FINISHED_HTTP_DOWNLOAD
  to the existing dispatcher (CamuleApp::OnFinishedHTTPDownload,
  unchanged) and CallAfter()s its own destruction, so wxWebRequest's
  internal socket is already torn down by the time the handler dies.

* Keeps Create() / Run() / Stop() / OnExit() / Entry() as stubs, so
  the six call sites (new + Create + Run) compile unchanged. When
  wx 3.3's wxWebRequestSync becomes a reasonable floor on distro
  defaults those stubs can be made real and the event-driven
  plumbing collapsed into a synchronous call on a worker thread with
  no wxSocket anywhere.

Reentrancy: no nested event loops anywhere on the fix path. No
ShowModal (the existing progress dialog has always been modeless).
No blocking wait on the request. Cancellation via the dialog's
Cancel button or the app-wide StopAll() is fire-and-forget — it
calls Cancel() on the request, returns immediately, and State_Cancelled
arrives later on the main loop. Avoids the class of bug that would
come from a "sync wrapper = nested wxEventLoop" trick on wx 3.2.

Redirects (including HTTP→HTTPS) are handled by wxWebRequest
transparently, which removes the ~110-line recursive GetInputStream
redirect handler — the actual seat of the upstream race.

Proxy: a static ApplyProxyToDefaultSession() helper maps the existing
CProxyData prefs onto wxWebSession::SetProxy, applied from the ctor.
wxWebProxy / SetProxy are wx 3.3+ only, so the body is guarded with
wxCHECK_VERSION(3,3,0); on wx 3.2 the libcurl backend still honours
http_proxy / https_proxy / all_proxy env vars, so env-driven proxy
keeps working. The legacy wxHTTP path never honoured aMule's Proxy
prefs either (it only called SetProxyMode(bool) with no URL ever
registered via wxURL::SetProxy / SetDefaultProxy anywhere in the
codebase), so this is not a regression. SOCKS is intentionally
skipped even on 3.3+ — wxWebProxy is HTTP-only. A libcurl-direct
backend would be needed if SOCKS support matters, out of scope here.

macOS App Transport Security opt-out
------------------------------------

wxWebRequest on macOS is backed by NSURLSession, which enforces ATS
and blocks plaintext http:// by default. The legacy wxHTTP/wxSocket
path bypassed ATS because it used raw BSD sockets; the rewrite
inherits NSURLSession's policy instead. Without the opt-out every
startup download to an http:// URL fails at the OS level —
reproducible on the first server.met update:

    HTTPDownload.cpp: HTTP download failed for
      http://upd.emule-security.org/server.met: The resource could
      not be loaded because the App Transport Security policy
      requires the use of a secure connection.

Inject NSAppTransportSecurity:NSAllowsArbitraryLoads=true via plutil
as a POST_BUILD step on the `amule` target in src/CMakeLists.txt.
Matches the legacy path's behaviour, not a new policy choice.

macOS exit-time crash work-around
---------------------------------

wx 3.3.2 has a bug in wxWebSessionURLSession::~wxWebSessionURLSession:
it releases the NSURLSession and the delegate separately without
first calling -invalidateAndCancel. NSURLSession retains its delegate
strongly, so the session's dealloc already drops the delegate ref —
wx's subsequent release hits a freed object and the process aborts
with "pointer being freed was not allocated". This fires in wx module
cleanup / atexit / __cxa_finalize on any Mac build after any HTTP
download (version check, server.met, …).

By the end of CamuleApp::OnExit we have saved state, joined threads,
and flushed logs — nothing aMule-owned remains to clean up. std::_Exit
bypasses atexit and static destructors, so the buggy wx dtor never
runs and the process terminates cleanly. Linux / Windows continue
through wx's normal cleanup; this macOS-only block can be dropped
once the upstream wx fix lands in a release we depend on.

Dialog / thread lifetime fix
----------------------------

CHTTPDownloadDialog holds a raw pointer (m_owner) to the owning
CHTTPDownloadThread. On successful download the ordered flow is:

  FinishAndDestroy posts wxEVT_HTTP_SHUTDOWN to the dialog, posts
  wxEVT_CORE_FINISHED_HTTP_DOWNLOAD to the app dispatcher, then
  CallAfter()s `delete this`.
  Main loop: dialog OnShutdown → Destroy() (queues the dialog in
  wxPendingDelete), then app dispatcher runs, then CallAfter runs
  and deletes the thread. Later, idle → DeletePendingObjects runs
  the dialog dtor — which used to dereference the now-freed m_owner
  via StopDownload → ~vtable lookup → crash.

Null the dialog's m_owner inside OnShutdown, so its dtor (which runs
later from wxPendingDelete) no longer touches the already-deleted
thread. Equivalent cleanup on the reverse direction (dialog closed
before download completes) was already handled via
DetachCompanion + Stop in StopDownload.

Scope
-----

No CMake build-flag changes. wxWebRequest is in wxBase_net since
wx 3.2.0 (our floor since PR amule-project#459).

* src/HTTPDownload.{h,cpp} — class becomes wxEvtHandler, legacy
  wxThread-style method stubs with a wx 3.3 / wxWebRequestSync TODO,
  DetachCompanion() on the owning side + m_owner nulling on the
  dialog side to make the handshake safe from both directions.
* src/amule.cpp — macOS-only std::_Exit at end of OnExit.
* src/CMakeLists.txt — macOS-only POST_BUILD plutil to inject ATS
  opt-out into the CMake-generated Info.plist.
* Six call sites (version check, server.met, auto-update, IP filter,
  nodes.dat, GeoIP) compile unchanged.

Fixes the intermittent startup SIGSEGV tracked in upstream PR amule-project#455.
The crash happens on Linux when a startup HTTP download redirects to
https://, which wxHTTP cannot speak: wxHTTP::Destroy() schedules the
current handler for deferred deletion, the redirect handler throws,
and before the deferred delete runs an epoll event fires on the
still-registered fd — invoking a method on a socket mid-teardown.
Reproducible on stock origin/master (~1-in-27 runs of amuled in a
tight startup loop); the crash-hunt.sh script from PR amule-project#455 passes
>115 iterations clean on Linux/ARM64 with this rewrite. The fault
is inside libwx_baseu_net so it cannot be fixed inside aMule's code
paths — the only reliable remedy is to avoid the wxSocket-based HTTP
path entirely.

The fix is to stop doing HTTP on a worker thread with wxSocket under
the hood. CHTTPDownloadThread now:

* Inherits wxEvtHandler instead of CMuleThread. No worker thread, no
  wxSocket, no wxEpollDispatcher on the download path.

* Owns a wxWebRequest from wxWebSession::GetDefault(), kicks it off
  from the constructor on the main thread, binds wxEVT_WEBREQUEST_STATE
  on the same handler, and lets state transitions drive everything:
  Active → progress event to the optional dialog, Completed → rename
  wx's storage temp file into the caller-supplied path, Failed /
  Cancelled → clean up, Unauthorized → treat as failure. On every
  terminal state the object posts wxEVT_CORE_FINISHED_HTTP_DOWNLOAD
  to the existing dispatcher (CamuleApp::OnFinishedHTTPDownload,
  unchanged) and CallAfter()s its own destruction, so wxWebRequest's
  internal socket is already torn down by the time the handler dies.

* Keeps Create() / Run() / Stop() / OnExit() / Entry() as stubs, so
  the six call sites (new + Create + Run) compile unchanged. When
  wx 3.3's wxWebRequestSync becomes a reasonable floor on distro
  defaults those stubs can be made real and the event-driven
  plumbing collapsed into a synchronous call on a worker thread with
  no wxSocket anywhere.

Reentrancy: no nested event loops anywhere on the fix path. No
ShowModal (the existing progress dialog has always been modeless).
No blocking wait on the request. Cancellation via the dialog's
Cancel button or the app-wide StopAll() is fire-and-forget — it
calls Cancel() on the request, returns immediately, and State_Cancelled
arrives later on the main loop. Avoids the class of bug that would
come from a "sync wrapper = nested wxEventLoop" trick on wx 3.2.

Redirects (including HTTP→HTTPS) are handled by wxWebRequest
transparently, which removes the ~110-line recursive GetInputStream
redirect handler — the actual seat of the upstream race.

Proxy: a static ApplyProxyToDefaultSession() helper maps the existing
CProxyData prefs onto wxWebSession::SetProxy, applied from the ctor.
wxWebProxy / SetProxy are wx 3.3+ only, so the body is guarded with
wxCHECK_VERSION(3,3,0); on wx 3.2 the libcurl backend still honours
http_proxy / https_proxy / all_proxy env vars, so env-driven proxy
keeps working. The legacy wxHTTP path never honoured aMule's Proxy
prefs either (it only called SetProxyMode(bool) with no URL ever
registered via wxURL::SetProxy / SetDefaultProxy anywhere in the
codebase), so this is not a regression. SOCKS is intentionally
skipped even on 3.3+ — wxWebProxy is HTTP-only. A libcurl-direct
backend would be needed if SOCKS support matters, out of scope here.

macOS App Transport Security opt-out
------------------------------------

wxWebRequest on macOS is backed by NSURLSession, which enforces ATS
and blocks plaintext http:// by default. The legacy wxHTTP/wxSocket
path bypassed ATS because it used raw BSD sockets; the rewrite
inherits NSURLSession's policy instead. Without the opt-out every
startup download to an http:// URL fails at the OS level —
reproducible on the first server.met update:

    HTTPDownload.cpp: HTTP download failed for
      http://upd.emule-security.org/server.met: The resource could
      not be loaded because the App Transport Security policy
      requires the use of a secure connection.

Inject NSAppTransportSecurity:NSAllowsArbitraryLoads=true via plutil
as a POST_BUILD step on the `amule` target in src/CMakeLists.txt.
Matches the legacy path's behaviour, not a new policy choice.

macOS exit-time crash work-around
---------------------------------

wx 3.3.2 has a bug in wxWebSessionURLSession::~wxWebSessionURLSession:
it releases the NSURLSession and the delegate separately without
first calling -invalidateAndCancel. NSURLSession retains its delegate
strongly, so the session's dealloc already drops the delegate ref —
wx's subsequent release hits a freed object and the process aborts
with "pointer being freed was not allocated". This fires in wx module
cleanup / atexit / __cxa_finalize on any Mac build after any HTTP
download (version check, server.met, …).

By the end of CamuleApp::OnExit we have saved state, joined threads,
and flushed logs — nothing aMule-owned remains to clean up. std::_Exit
bypasses atexit and static destructors, so the buggy wx dtor never
runs and the process terminates cleanly. Linux / Windows continue
through wx's normal cleanup; this macOS-only block can be dropped
once the upstream wx fix lands in a release we depend on.

Dialog / thread lifetime fix
----------------------------

CHTTPDownloadDialog holds a raw pointer (m_owner) to the owning
CHTTPDownloadThread. On successful download the ordered flow is:

  FinishAndDestroy posts wxEVT_HTTP_SHUTDOWN to the dialog, posts
  wxEVT_CORE_FINISHED_HTTP_DOWNLOAD to the app dispatcher, then
  CallAfter()s `delete this`.
  Main loop: dialog OnShutdown → Destroy() (queues the dialog in
  wxPendingDelete), then app dispatcher runs, then CallAfter runs
  and deletes the thread. Later, idle → DeletePendingObjects runs
  the dialog dtor — which used to dereference the now-freed m_owner
  via StopDownload → ~vtable lookup → crash.

Null the dialog's m_owner inside OnShutdown, so its dtor (which runs
later from wxPendingDelete) no longer touches the already-deleted
thread. Equivalent cleanup on the reverse direction (dialog closed
before download completes) was already handled via
DetachCompanion + Stop in StopDownload.

Scope
-----

No CMake build-flag changes. wxWebRequest is in wxBase_net since
wx 3.2.0 (our floor since PR amule-project#459).

* src/HTTPDownload.{h,cpp} — class becomes wxEvtHandler, legacy
  wxThread-style method stubs with a wx 3.3 / wxWebRequestSync TODO,
  DetachCompanion() on the owning side + m_owner nulling on the
  dialog side to make the handshake safe from both directions.
* src/amule.cpp — macOS-only std::_Exit at end of OnExit.
* src/CMakeLists.txt — macOS-only POST_BUILD plutil to inject ATS
  opt-out into the CMake-generated Info.plist.
* Six call sites (version check, server.met, auto-update, IP filter,
  nodes.dat, GeoIP) compile unchanged.

Fixes the intermittent startup SIGSEGV tracked in upstream PR amule-project#455.
The crash happens on Linux when a startup HTTP download redirects to
https://, which wxHTTP cannot speak: wxHTTP::Destroy() schedules the
current handler for deferred deletion, the redirect handler throws,
and before the deferred delete runs an epoll event fires on the
still-registered fd — invoking a method on a socket mid-teardown.
Reproducible on stock origin/master (~1-in-27 runs of amuled in a
tight startup loop); the crash-hunt.sh script from PR amule-project#455 passes
>115 iterations clean on Linux/ARM64 with this rewrite. The fault
is inside libwx_baseu_net so it cannot be fixed inside aMule's code
paths — the only reliable remedy is to avoid the wxSocket-based HTTP
path entirely.

The fix is to stop doing HTTP on a worker thread with wxSocket under
the hood. CHTTPDownloadThread now:

* Inherits wxEvtHandler instead of CMuleThread. No worker thread, no
  wxSocket, no wxEpollDispatcher on the download path.

* Owns a wxWebRequest from wxWebSession::GetDefault(), kicks it off
  from the constructor on the main thread, binds wxEVT_WEBREQUEST_STATE
  on the same handler, and lets state transitions drive everything:
  Active → progress event to the optional dialog, Completed → rename
  wx's storage temp file into the caller-supplied path, Failed /
  Cancelled → clean up, Unauthorized → treat as failure. On every
  terminal state the object posts wxEVT_CORE_FINISHED_HTTP_DOWNLOAD
  to the existing dispatcher (CamuleApp::OnFinishedHTTPDownload,
  unchanged) and CallAfter()s its own destruction, so wxWebRequest's
  internal socket is already torn down by the time the handler dies.

* Keeps Create() / Run() / Stop() / OnExit() / Entry() as stubs, so
  the six call sites (new + Create + Run) compile unchanged. When
  wx 3.3's wxWebRequestSync becomes a reasonable floor on distro
  defaults those stubs can be made real and the event-driven
  plumbing collapsed into a synchronous call on a worker thread with
  no wxSocket anywhere.

Reentrancy: no nested event loops anywhere on the fix path. No
ShowModal (the existing progress dialog has always been modeless).
No blocking wait on the request. Cancellation via the dialog's
Cancel button or the app-wide StopAll() is fire-and-forget — it
calls Cancel() on the request, returns immediately, and State_Cancelled
arrives later on the main loop. Avoids the class of bug that would
come from a "sync wrapper = nested wxEventLoop" trick on wx 3.2.

Redirects (including HTTP→HTTPS) are handled by wxWebRequest
transparently, which removes the ~110-line recursive GetInputStream
redirect handler — the actual seat of the upstream race.

Proxy: a static ApplyProxyToDefaultSession() helper maps the existing
CProxyData prefs onto wxWebSession::SetProxy, applied from the ctor.
wxWebProxy / SetProxy are wx 3.3+ only, so the body is guarded with
wxCHECK_VERSION(3,3,0); on wx 3.2 the libcurl backend still honours
http_proxy / https_proxy / all_proxy env vars, so env-driven proxy
keeps working. The legacy wxHTTP path never honoured aMule's Proxy
prefs either (it only called SetProxyMode(bool) with no URL ever
registered via wxURL::SetProxy / SetDefaultProxy anywhere in the
codebase), so this is not a regression. SOCKS is intentionally
skipped even on 3.3+ — wxWebProxy is HTTP-only. A libcurl-direct
backend would be needed if SOCKS support matters, out of scope here.

macOS App Transport Security opt-out
------------------------------------

wxWebRequest on macOS is backed by NSURLSession, which enforces ATS
and blocks plaintext http:// by default. The legacy wxHTTP/wxSocket
path bypassed ATS because it used raw BSD sockets; the rewrite
inherits NSURLSession's policy instead. Without the opt-out every
startup download to an http:// URL fails at the OS level —
reproducible on the first server.met update:

    HTTPDownload.cpp: HTTP download failed for
      http://upd.emule-security.org/server.met: The resource could
      not be loaded because the App Transport Security policy
      requires the use of a secure connection.

Inject NSAppTransportSecurity:NSAllowsArbitraryLoads=true via plutil
as a POST_BUILD step on the `amule` target in src/CMakeLists.txt.
Matches the legacy path's behaviour, not a new policy choice.

macOS exit-time crash work-around
---------------------------------

wx 3.3.2 has a bug in wxWebSessionURLSession::~wxWebSessionURLSession:
it releases the NSURLSession and the delegate separately without
first calling -invalidateAndCancel. NSURLSession retains its delegate
strongly, so the session's dealloc already drops the delegate ref —
wx's subsequent release hits a freed object and the process aborts
with "pointer being freed was not allocated". This fires in wx module
cleanup / atexit / __cxa_finalize on any Mac build after any HTTP
download (version check, server.met, …).

By the end of CamuleApp::OnExit we have saved state, joined threads,
and flushed logs — nothing aMule-owned remains to clean up. std::_Exit
bypasses atexit and static destructors, so the buggy wx dtor never
runs and the process terminates cleanly. Linux / Windows continue
through wx's normal cleanup; this macOS-only block can be dropped
once the upstream wx fix lands in a release we depend on.

Dialog / thread lifetime fix
----------------------------

CHTTPDownloadDialog holds a raw pointer (m_owner) to the owning
CHTTPDownloadThread. On successful download the ordered flow is:

  FinishAndDestroy posts wxEVT_HTTP_SHUTDOWN to the dialog, posts
  wxEVT_CORE_FINISHED_HTTP_DOWNLOAD to the app dispatcher, then
  CallAfter()s `delete this`.
  Main loop: dialog OnShutdown → Destroy() (queues the dialog in
  wxPendingDelete), then app dispatcher runs, then CallAfter runs
  and deletes the thread. Later, idle → DeletePendingObjects runs
  the dialog dtor — which used to dereference the now-freed m_owner
  via StopDownload → ~vtable lookup → crash.

Null the dialog's m_owner inside OnShutdown, so its dtor (which runs
later from wxPendingDelete) no longer touches the already-deleted
thread. Equivalent cleanup on the reverse direction (dialog closed
before download completes) was already handled via
DetachCompanion + Stop in StopDownload.

Scope
-----

No CMake build-flag changes. wxWebRequest is in wxBase_net since
wx 3.2.0 (our floor since PR amule-project#459).

* src/HTTPDownload.{h,cpp} — class becomes wxEvtHandler, legacy
  wxThread-style method stubs with a wx 3.3 / wxWebRequestSync TODO,
  DetachCompanion() on the owning side + m_owner nulling on the
  dialog side to make the handshake safe from both directions.
* src/amule.cpp — macOS-only std::_Exit at end of OnExit.
* src/CMakeLists.txt — macOS-only POST_BUILD plutil to inject ATS
  opt-out into the CMake-generated Info.plist.
* Six call sites (version check, server.met, auto-update, IP filter,
  nodes.dat, GeoIP) compile unchanged.

Fixes the intermittent startup SIGSEGV tracked in upstream PR amule-project#455.
The crash happens on Linux when a startup HTTP download redirects to
https://, which wxHTTP cannot speak: wxHTTP::Destroy() schedules the
current handler for deferred deletion, the redirect handler throws,
and before the deferred delete runs an epoll event fires on the
still-registered fd — invoking a method on a socket mid-teardown.
Reproducible on stock origin/master (~1-in-27 runs of amuled in a
tight startup loop); the crash-hunt.sh script from PR amule-project#455 passes
>115 iterations clean on Linux/ARM64 with this rewrite. The fault
is inside libwx_baseu_net so it cannot be fixed inside aMule's code
paths — the only reliable remedy is to avoid the wxSocket-based HTTP
path entirely.

The fix is to stop doing HTTP on a worker thread with wxSocket under
the hood. CHTTPDownloadThread now:

* Inherits wxEvtHandler instead of CMuleThread. No worker thread, no
  wxSocket, no wxEpollDispatcher on the download path.

* Owns a wxWebRequest from wxWebSession::GetDefault(), kicks it off
  from the constructor on the main thread, binds wxEVT_WEBREQUEST_STATE
  on the same handler, and lets state transitions drive everything:
  Active → progress event to the optional dialog, Completed → rename
  wx's storage temp file into the caller-supplied path, Failed /
  Cancelled → clean up, Unauthorized → treat as failure. On every
  terminal state the object posts wxEVT_CORE_FINISHED_HTTP_DOWNLOAD
  to the existing dispatcher (CamuleApp::OnFinishedHTTPDownload,
  unchanged) and CallAfter()s its own destruction, so wxWebRequest's
  internal socket is already torn down by the time the handler dies.

* Keeps Create() / Run() / Stop() / OnExit() / Entry() as stubs, so
  the six call sites (new + Create + Run) compile unchanged. When
  wx 3.3's wxWebRequestSync becomes a reasonable floor on distro
  defaults those stubs can be made real and the event-driven
  plumbing collapsed into a synchronous call on a worker thread with
  no wxSocket anywhere.

Reentrancy: no nested event loops anywhere on the fix path. No
ShowModal (the existing progress dialog has always been modeless).
No blocking wait on the request. Cancellation via the dialog's
Cancel button or the app-wide StopAll() is fire-and-forget — it
calls Cancel() on the request, returns immediately, and State_Cancelled
arrives later on the main loop. Avoids the class of bug that would
come from a "sync wrapper = nested wxEventLoop" trick on wx 3.2.

Redirects (including HTTP→HTTPS) are handled by wxWebRequest
transparently, which removes the ~110-line recursive GetInputStream
redirect handler — the actual seat of the upstream race.

Proxy: a static ApplyProxyToDefaultSession() helper maps the existing
CProxyData prefs onto wxWebSession::SetProxy, applied from the ctor.
wxWebProxy / SetProxy are wx 3.3+ only, so the body is guarded with
wxCHECK_VERSION(3,3,0); on wx 3.2 the libcurl backend still honours
http_proxy / https_proxy / all_proxy env vars, so env-driven proxy
keeps working. The legacy wxHTTP path never honoured aMule's Proxy
prefs either (it only called SetProxyMode(bool) with no URL ever
registered via wxURL::SetProxy / SetDefaultProxy anywhere in the
codebase), so this is not a regression. SOCKS is intentionally
skipped even on 3.3+ — wxWebProxy is HTTP-only. A libcurl-direct
backend would be needed if SOCKS support matters, out of scope here.

macOS App Transport Security opt-out
------------------------------------

wxWebRequest on macOS is backed by NSURLSession, which enforces ATS
and blocks plaintext http:// by default. The legacy wxHTTP/wxSocket
path bypassed ATS because it used raw BSD sockets; the rewrite
inherits NSURLSession's policy instead. Without the opt-out every
startup download to an http:// URL fails at the OS level —
reproducible on the first server.met update:

    HTTPDownload.cpp: HTTP download failed for
      http://upd.emule-security.org/server.met: The resource could
      not be loaded because the App Transport Security policy
      requires the use of a secure connection.

Inject NSAppTransportSecurity:NSAllowsArbitraryLoads=true via plutil
as a POST_BUILD step on the `amule` target in src/CMakeLists.txt.
Matches the legacy path's behaviour, not a new policy choice.

macOS exit-time crash work-around
---------------------------------

wx 3.3.2 has a bug in wxWebSessionURLSession::~wxWebSessionURLSession:
it releases the NSURLSession and the delegate separately without
first calling -invalidateAndCancel. NSURLSession retains its delegate
strongly, so the session's dealloc already drops the delegate ref —
wx's subsequent release hits a freed object and the process aborts
with "pointer being freed was not allocated". This fires in wx module
cleanup / atexit / __cxa_finalize on any Mac build after any HTTP
download (version check, server.met, …).

By the end of CamuleApp::OnExit we have saved state, joined threads,
and flushed logs — nothing aMule-owned remains to clean up. std::_Exit
bypasses atexit and static destructors, so the buggy wx dtor never
runs and the process terminates cleanly. Linux / Windows continue
through wx's normal cleanup; this macOS-only block can be dropped
once the upstream wx fix lands in a release we depend on.

Windows portable install: CA bundle for libcurl HTTPS
-----------------------------------------------------

wxWebRequest on MSYS2 (MINGW64 / CLANGARM64) is backed by libcurl
built with OpenSSL. MSYS2 libcurl is compiled with an absolute
--with-ca-bundle= path (e.g. /clangarm64/etc/ssl/certs/ca-bundle.crt)
that only exists on the developer's machine. On an end-user box the
CA bundle isn't there and every HTTPS request (including the HTTP→
HTTPS redirect that hits the default startup URLs) fails with
"libcurl error 77: Problem with the SSL CA cert".

Two-part fix so portable zips work everywhere:

* src/CMakeLists.txt (WIN32 AND MINGW install block): ship the MSYS2
  CA bundle alongside the bundled DLLs as bin/ca-bundle.crt.
* src/amule.cpp (CamuleApp::OnInit, __WINDOWS__-guarded): if
  CURL_CA_BUNDLE is not already set in the environment, point it at
  the bundled file resolved from wxStandardPaths::GetExecutablePath.

Users running from a portable directory now get working HTTPS without
any shell env setup; users who want to point at their own bundle
still can by setting CURL_CA_BUNDLE before launch.

Dialog / thread lifetime fix
----------------------------

CHTTPDownloadDialog holds a raw pointer (m_owner) to the owning
CHTTPDownloadThread. On successful download the ordered flow is:

  FinishAndDestroy posts wxEVT_HTTP_SHUTDOWN to the dialog, posts
  wxEVT_CORE_FINISHED_HTTP_DOWNLOAD to the app dispatcher, then
  CallAfter()s `delete this`.
  Main loop: dialog OnShutdown → Destroy() (queues the dialog in
  wxPendingDelete), then app dispatcher runs, then CallAfter runs
  and deletes the thread. Later, idle → DeletePendingObjects runs
  the dialog dtor — which used to dereference the now-freed m_owner
  via StopDownload → ~vtable lookup → crash.

Null the dialog's m_owner inside OnShutdown, so its dtor (which runs
later from wxPendingDelete) no longer touches the already-deleted
thread. Equivalent cleanup on the reverse direction (dialog closed
before download completes) was already handled via
DetachCompanion + Stop in StopDownload.

Progress bar safety (wxGTK)
---------------------------

wxWebRequest::GetBytesExpectedToReceive() returns wxInvalidOffset (-1)
before Content-Length is known (or indefinitely if the server never
sends it). Forwarding -1 into CHTTPDownloadDialog::UpdateGauge ended
up calling wxGauge::SetRange(-1), which trips an assertion on the
next repaint on wxGTK (./src/gtk/gauge.cpp:90, reproducible on IP
filter updates on Ubuntu). Clamp the expected size at the event
source, and make UpdateGauge only touch the gauge when the total is
known and current <= total, so out-of-range values can never reach
the widget.

Scope
-----

wxWebRequest is in wxBase_net since wx 3.2.0 (our floor since PR amule-project#459),
so no new build dependency beyond install-time packaging of an MSYS2
CA bundle on Windows.

* src/HTTPDownload.{h,cpp} — class becomes wxEvtHandler, legacy
  wxThread-style method stubs with a wx 3.3 / wxWebRequestSync TODO,
  DetachCompanion() on the owning side + m_owner nulling on the
  dialog side to make the handshake safe from both directions,
  UpdateGauge clamped.
* src/amule.cpp — macOS-only std::_Exit at end of OnExit;
  Windows-only CURL_CA_BUNDLE fallback to the bundled ca-bundle.crt.
* src/CMakeLists.txt — macOS-only POST_BUILD plutil to inject ATS
  opt-out into the CMake-generated Info.plist; Windows-only install
  of the MSYS2 CA bundle alongside the bundled DLLs.
* Six call sites (version check, server.met, auto-update, IP filter,
  nodes.dat, GeoIP) compile unchanged.

Fixes the intermittent startup SIGSEGV tracked in upstream PR #455.
The crash happens on Linux when a startup HTTP download redirects to
https://, which wxHTTP cannot speak: wxHTTP::Destroy() schedules the
current handler for deferred deletion, the redirect handler throws,
and before the deferred delete runs an epoll event fires on the
still-registered fd — invoking a method on a socket mid-teardown.
Reproducible on stock origin/master (~1-in-27 runs of amuled in a
tight startup loop); the crash-hunt.sh script from PR #455 passes
>115 iterations clean on Linux/ARM64 with this rewrite. The fault
is inside libwx_baseu_net so it cannot be fixed inside aMule's code
paths — the only reliable remedy is to avoid the wxSocket-based HTTP
path entirely.

The fix is to stop doing HTTP on a worker thread with wxSocket under
the hood. CHTTPDownloadThread now:

* Inherits wxEvtHandler instead of CMuleThread. No worker thread, no
  wxSocket, no wxEpollDispatcher on the download path.

* Owns a wxWebRequest from wxWebSession::GetDefault(), kicks it off
  from the constructor on the main thread, binds wxEVT_WEBREQUEST_STATE
  on the same handler, and lets state transitions drive everything:
  Active → progress event to the optional dialog, Completed → rename
  wx's storage temp file into the caller-supplied path, Failed /
  Cancelled → clean up, Unauthorized → treat as failure. On every
  terminal state the object posts wxEVT_CORE_FINISHED_HTTP_DOWNLOAD
  to the existing dispatcher (CamuleApp::OnFinishedHTTPDownload,
  unchanged) and CallAfter()s its own destruction, so wxWebRequest's
  internal socket is already torn down by the time the handler dies.

* Keeps Create() / Run() / Stop() / OnExit() / Entry() as stubs, so
  the six call sites (new + Create + Run) compile unchanged. When
  wx 3.3's wxWebRequestSync becomes a reasonable floor on distro
  defaults those stubs can be made real and the event-driven
  plumbing collapsed into a synchronous call on a worker thread with
  no wxSocket anywhere.

Reentrancy: no nested event loops anywhere on the fix path. No
ShowModal (the existing progress dialog has always been modeless).
No blocking wait on the request. Cancellation via the dialog's
Cancel button or the app-wide StopAll() is fire-and-forget — it
calls Cancel() on the request, returns immediately, and State_Cancelled
arrives later on the main loop. Avoids the class of bug that would
come from a "sync wrapper = nested wxEventLoop" trick on wx 3.2.

Redirects (including HTTP→HTTPS) are handled by wxWebRequest
transparently, which removes the ~110-line recursive GetInputStream
redirect handler — the actual seat of the upstream race.

Proxy: a static ApplyProxyToDefaultSession() helper maps the existing
CProxyData prefs onto wxWebSession::SetProxy, applied from the ctor.
wxWebProxy / SetProxy are wx 3.3+ only, so the body is guarded with
wxCHECK_VERSION(3,3,0); on wx 3.2 the libcurl backend still honours
http_proxy / https_proxy / all_proxy env vars, so env-driven proxy
keeps working. The legacy wxHTTP path never honoured aMule's Proxy
prefs either (it only called SetProxyMode(bool) with no URL ever
registered via wxURL::SetProxy / SetDefaultProxy anywhere in the
codebase), so this is not a regression. SOCKS is intentionally
skipped even on 3.3+ — wxWebProxy is HTTP-only. A libcurl-direct
backend would be needed if SOCKS support matters, out of scope here.

macOS App Transport Security opt-out
------------------------------------

wxWebRequest on macOS is backed by NSURLSession, which enforces ATS
and blocks plaintext http:// by default. The legacy wxHTTP/wxSocket
path bypassed ATS because it used raw BSD sockets; the rewrite
inherits NSURLSession's policy instead. Without the opt-out every
startup download to an http:// URL fails at the OS level —
reproducible on the first server.met update:

    HTTPDownload.cpp: HTTP download failed for
      http://upd.emule-security.org/server.met: The resource could
      not be loaded because the App Transport Security policy
      requires the use of a secure connection.

Inject NSAppTransportSecurity:NSAllowsArbitraryLoads=true via plutil
as a POST_BUILD step on the `amule` target in src/CMakeLists.txt.
Matches the legacy path's behaviour, not a new policy choice.

macOS exit-time crash work-around
---------------------------------

wx 3.3.2 has a bug in wxWebSessionURLSession::~wxWebSessionURLSession:
it releases the NSURLSession and the delegate separately without
first calling -invalidateAndCancel. NSURLSession retains its delegate
strongly, so the session's dealloc already drops the delegate ref —
wx's subsequent release hits a freed object and the process aborts
with "pointer being freed was not allocated". This fires in wx module
cleanup / atexit / __cxa_finalize on any Mac build after any HTTP
download (version check, server.met, …).

By the end of CamuleApp::OnExit we have saved state, joined threads,
and flushed logs — nothing aMule-owned remains to clean up. std::_Exit
bypasses atexit and static destructors, so the buggy wx dtor never
runs and the process terminates cleanly. Linux / Windows continue
through wx's normal cleanup; this macOS-only block can be dropped
once the upstream wx fix lands in a release we depend on.

Windows portable install: CA bundle for libcurl HTTPS
-----------------------------------------------------

wxWebRequest on MSYS2 (MINGW64 / CLANGARM64) is backed by libcurl
built with OpenSSL. MSYS2 libcurl is compiled with an absolute
--with-ca-bundle= path (e.g. /clangarm64/etc/ssl/certs/ca-bundle.crt)
that only exists on the developer's machine. On an end-user box the
CA bundle isn't there and every HTTPS request (including the HTTP→
HTTPS redirect that hits the default startup URLs) fails with
"libcurl error 77: Problem with the SSL CA cert".

Two-part fix so portable zips work everywhere:

* src/CMakeLists.txt (WIN32 AND MINGW install block): ship the MSYS2
  CA bundle alongside the bundled DLLs as bin/ca-bundle.crt.
* src/amule.cpp (CamuleApp::OnInit, __WINDOWS__-guarded): if
  CURL_CA_BUNDLE is not already set in the environment, point it at
  the bundled file resolved from wxStandardPaths::GetExecutablePath.

Users running from a portable directory now get working HTTPS without
any shell env setup; users who want to point at their own bundle
still can by setting CURL_CA_BUNDLE before launch.

Dialog / thread lifetime fix
----------------------------

CHTTPDownloadDialog holds a raw pointer (m_owner) to the owning
CHTTPDownloadThread. On successful download the ordered flow is:

  FinishAndDestroy posts wxEVT_HTTP_SHUTDOWN to the dialog, posts
  wxEVT_CORE_FINISHED_HTTP_DOWNLOAD to the app dispatcher, then
  CallAfter()s `delete this`.
  Main loop: dialog OnShutdown → Destroy() (queues the dialog in
  wxPendingDelete), then app dispatcher runs, then CallAfter runs
  and deletes the thread. Later, idle → DeletePendingObjects runs
  the dialog dtor — which used to dereference the now-freed m_owner
  via StopDownload → ~vtable lookup → crash.

Null the dialog's m_owner inside OnShutdown, so its dtor (which runs
later from wxPendingDelete) no longer touches the already-deleted
thread. Equivalent cleanup on the reverse direction (dialog closed
before download completes) was already handled via
DetachCompanion + Stop in StopDownload.

Progress bar safety (wxGTK)
---------------------------

wxWebRequest::GetBytesExpectedToReceive() returns wxInvalidOffset (-1)
before Content-Length is known (or indefinitely if the server never
sends it). Forwarding -1 into CHTTPDownloadDialog::UpdateGauge ended
up calling wxGauge::SetRange(-1), which trips an assertion on the
next repaint on wxGTK (./src/gtk/gauge.cpp:90, reproducible on IP
filter updates on Ubuntu). Clamp the expected size at the event
source, and make UpdateGauge only touch the gauge when the total is
known and current <= total, so out-of-range values can never reach
the widget.

Scope
-----

wxWebRequest is in wxBase_net since wx 3.2.0 (our floor since PR #459),
so no new build dependency beyond install-time packaging of an MSYS2
CA bundle on Windows.

* src/HTTPDownload.{h,cpp} — class becomes wxEvtHandler, legacy
  wxThread-style method stubs with a wx 3.3 / wxWebRequestSync TODO,
  DetachCompanion() on the owning side + m_owner nulling on the
  dialog side to make the handshake safe from both directions,
  UpdateGauge clamped.
* src/amule.cpp — macOS-only std::_Exit at end of OnExit;
  Windows-only CURL_CA_BUNDLE fallback to the bundled ca-bundle.crt.
* src/CMakeLists.txt — macOS-only POST_BUILD plutil to inject ATS
  opt-out into the CMake-generated Info.plist; Windows-only install
  of the MSYS2 CA bundle alongside the bundled DLLs.
* Six call sites (version check, server.met, auto-update, IP filter,
  nodes.dat, GeoIP) compile unchanged.

Following the org-migration discussion on PR #521, point all source /
docs / packaging URLs at the new `amule-org` GitHub org that
@mrjimenez bootstrapped on 2026-05-04.

Two motivating reasons (per the thread):

1. The new active maintainer team needs proper write/admin access
   that the existing amule-project upper-level admins have been
   unreachable to grant.

2. The version-check probe added in #522 hardcodes its target URL
   into every shipped binary.  If that URL stays at amule-project
   while future releases land on amule-org, the cohort of users on
   3.0.0 will be permanently stranded querying a dead-end endpoint
   and never learn about 3.0.1+ via the in-app prompt.  Flipping
   the URL pre-3.0.0-tag is the only way to keep them informed
   without dual-publishing maintenance burden.

Seven references updated in lockstep:

- `src/amule.cpp` — version-check probe URL.
- `packaging/linux/flatpak/org.amule.aMule.yaml.in` — Flatpak
  manifest's git source URL (load-bearing — `flatpak-builder`
  clones from this URL at build time).
- `org.amule.aMule.metainfo.xml` — AppStream bug-tracker URL,
  surfaces in Flathub / GNOME Software / KDE Discover.
- `README.md` — logo image URL on raw.githubusercontent.com plus
  the Issues and Pull Requests link references.
- `docs/INSTALL.md` — upstream-issue-tracker doc reference.
- `docs/README.md` — GitHub Issues doc reference.

Left as-is:

- `src/HTTPDownload.cpp:252` — code comment referencing issue
  `#455` for historical context.  The issue
  itself stays at amule-project regardless of where future
  development happens; the comment is a citation, not a forward
  reference.
- The `amule-project.de` / `amule-project.net` mentions in
  `docs/CHANGELOG.md` 2003-era entries — those are old DNS
  domain references unrelated to the GitHub org.

Note: this commit assumes `amule-org/amule` will exist as a real
repo by the time this PR merges.  The org was created 2026-05-04
with zero repos; the Flatpak build URL change in particular will
fail the Packaging workflow until the repo is bootstrapped.

…-application

Translations update from Weblate