Skip to content

Resolve Crypto++ 8.4 vs 8.9 dependency truth

Summary

Current main still links a live Crypto++ dependency through the workspace-managed emulebb-cryptopp fork. The Crypto++ 8.9 upgrade is deferred out of beta 0.7.3 scope by release-owner decision on 2026-05-13. The recorded decision is to keep the current 8.4-based fork for now.

Follow-up release-owner clarification on 2026-05-13: this defer may remain indefinite. Treat the 8.9 update as dependency hygiene only unless a concrete issue appears in an eMuleBB call site, supported compiler/platform path, or security advisory that affects the APIs we actually use.

The beta will not be blocked on the Crypto++ 8.4 vs 8.9 dependency decision. This item remains active as deferred informational dependency hardening, not as a selected upgrade plan. Do not keep re-raising this item during beta release work merely because 8.9 is newer than 8.4.

The setup advisory report flags the upstream gap:

  • pinned baseline: CRYPTOPP_8_4_0
  • latest matching upstream release: CRYPTOPP_8_9_0

This is not an app-level crypto rewrite. The local fork delta is small and limited to cryptlib.vcxproj, but the dependency is still security-sensitive and should not stay on an older baseline indefinitely.

Current State (revalidated 2026-04-19)

  • srchybrid/emule.vcxproj still links cryptlib.lib
  • live app consumers still use Crypto++ directly for:
  • secure-ident RSA signing (ClientCredits.cpp)
  • random generation and DH math (EncryptedStreamSocket.cpp)
  • SHA1 / MD4 / MD5 wrappers (EmuleSHA.h, EmuleMD4.h, MD5Sum.cpp)
  • python -m emule_workspace still builds Crypto++ as a first-class third-party dependency and carries explicit ARM64 overrides:
  • CRYPTOPP_DISABLE_ASM
  • CRYPTOPP_NO_CPU_FEATURE_PROBES

Local fork audit against upstream CRYPTOPP_8_4_0 showed only two carried commits, both confined to cryptlib.vcxproj:

  1. d7556aba — silence checked-iterator deprecation warnings
  2. 98239c93 — add ARM64 Crypto++ build configs

If this is explicitly reopened later, the likely implementation shape is:

  1. refresh the upstream Crypto++ vendor tree to 8.9
  2. reapply or restate the local cryptlib.vcxproj fork delta
  3. rebuild and smoke-test the app paths that use Crypto++

Why This Is Worth Tracking

Crypto++ 8.9 is a real upstream release, not just moving master noise. The 8.9 notes call it a minor release with one memory-error fix and several correctness fixes around ProcessData and inString == outString behavior.

Nothing in the current eMule call sites suggests a mandatory immediate migration, so this stays Minor rather than a hotfix. Current app use is centered on RSA secure-ident, signed collections, legacy protocol hash wrappers, RNG, and Integer math for the existing obfuscation handshake; there is no known direct use of the 8.9 ProcessData-style fixes. The practical default is to leave Crypto++ 8.4 pinned unless there is a specific affected call site, compiler failure, platform failure, or security advisory.

Constraints

  • Preserve the current static-library integration model used by emulebb-build
  • Preserve the local ARM64 build path and current v143 workspace toolchain
  • Keep the current explicit Crypto++ build hardening/compat policy unless the replacement is proven safe:
  • CRYPTOPP_DISABLE_ASM
  • CRYPTOPP_NO_CPU_FEATURE_PROBES
  • Treat this as a vendor refresh plus workspace-build revalidation, not as an excuse to rewrite secure-ident or obfuscation code

Acceptance Criteria

  • [x] Beta 0.7.3 dependency decision is recorded: ship current 8.4.
  • [x] Active topology and dependency docs agree with the recorded beta decision.
  • [ ] If this is explicitly reopened, emulebb-cryptopp is refreshed from the 8.4 baseline to a reviewed 8.9-based fork.
  • [ ] The current local cryptlib.vcxproj carry set is preserved or intentionally replaced:
  • checked-iterator warning silence
  • ARM64 configurations / target machine support
  • ARM64-safe source exclusions as needed
  • [ ] build-libs succeeds for the supported active workspace targets after any topology change
  • [ ] build-app succeeds against the selected cryptlib.lib
  • [ ] secure-ident key generation / signing and encrypted socket handshake still work on current main
  • [ ] any required project-file drift against upstream 8.9 is captured in the fork instead of relying on ad hoc local edits

Notes

  • This item is narrower than REF-028 (MbedTLS) because the current app-side API surface appears stable and the local fork delta is much smaller.
  • If a future dependency-policy pass adds release-based tracking for more third-party repos, keep this item aligned with that advisory report rather than reintroducing hardcoded version knowledge elsewhere.