Skip to content

cryptopp dependency alternative #167

Description

@nunotexbsd

Hi everyone,

While working on packaging and maintaining the modern aMule codebase for FreeBSD, we've encountered recurring build friction regarding the security/cryptopp dependency.

As observed across the wider open-source packaging ecosystem (including various Linux distros and BSDs), the official Crypto++ upstream repository has become largely stagnant. This passive maintenance state causes compilation issues with modern compiler toolchains (GCC 14+, Clang 18+) and complicates SIMD/assembly flag handling across architectures like amd64 and i386.

Since aMule heavily relies on Crypto++ for core protocol features (Kademlia identification, hashing, and connection obfuscation), moving away from it completely would require a major cryptographic refactoring.

To solve this sustainably, I would like to propose a two-phase approach:

1. Immediate Solution: Support cryptopp-modern as a drop-in replacement

There is an active, community-maintained friendly fork available at https://github.com/cryptopp-modern/cryptopp-modern.

  • Zero code changes: It maintains 100% API/ABI compatibility with classic Crypto++.
  • Modern build system: It replaces legacy Makefiles with a clean CMake build system, matching aMule's current build infrastructure.
  • Toolchain ready: It actively patches compiler errors for modern C++ standards.

We could update our CMake configuration to easily detect or prefer this modern fork if available in the build environment.

2. Long-term Vision: Abstracting the Crypto Backend

In the long run, to completely future-proof aMule from single-library deprecation, it might be worth introducing a crypto abstraction layer. This would allow aMule to use more ubiquitous, actively developed backends:

  • OpenSSL: Already present in virtually every base system, ultra-fast, and universally maintained.
  • Botan: A modern C++ alternative that shares similar object-oriented design patterns with Crypto++, making a potential migration path smoother than a pure C library.
  • Libgcrypt: Highly stable and readily available in the GNU ecosystem.

I'd love to hear the maintainers' thoughts on this. If there is interest in guiding the build system toward cryptopp-modern, I can assist with testing and providing feedback from the ports/packaging perspective.

Thanks for your amazing work on keeping aMule alive and modernized!

Metadata

Metadata

Assignees

No one assigned

    Labels

    dependenciesPull requests that update a dependency filepackaging

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions