Created attachment 273456 [details] Migrate dependency from security/cryptopp to security/cryptopp-modern Hello! We would like to suggest a transition from the legacy security/cryptopp (whose original upstream development has been inactive for a while) to its active and modernized fork, security/cryptopp-modern. Main Benefits: * Say goodbye to legacy Makefiles: It uses CMake out of the box, making building, packaging, and integration much smoother and cleaner. * Modern toolchain compatibility: It resolves those persistent headaches with newer versions of Clang, LLVM, and libc++. * Active maintenance: The project is actively maintained, ensuring timely security fixes and great compatibility with modern C++ standards. This is a friendly recommendation and encouragement for consumer ports to update their dependencies, helping keep our ecosystem healthy and up-to-date! WWW: https://github.com/cryptopp-modern/cryptopp-modern \ https://cryptopp-modern.com/ --- NOTES: - tests are fixed upstream - net-p2p/amule is already using cryptopp-modern - exp-run: OK
% portgrep -d cryptopp -o archivers/ccmix filesystems/securefs archivers/urbackup-client archivers/urbackup-server graphics/gdal multimedia/kvazaar net/megacmd graphics/zeno
I'm fine with it, but as the maintainer of security/cryptopp, I've had users wanting bin/cryptest installed by default. The current security/cryptopp-modern does not provide this binary even optionally.
(In reply to Jason E. Hale from comment #2) I see a reference to cryptest in latest version changelog: "2026.8.1 is a patch release fixing BLAKE3 multi-chunk hashing, malformed DEFLATE header handling, and cryptest shared-library compatibility." Could you point me to some PRs about it and why is it important having cryptest installed as a binary? With good info gathered, I could open an PR and see what upstream thinks about it. Thanks
bug#222930, for example. I'm just trying to save you some headaches if you want to take over cryptopp.
(In reply to Jason E. Hale from comment #4) Thanks for pointing that PR. I can understand now that cryptest was installed by default in the past and at some point upstream disabled it. I see that TOOLS option fixes that. Soon I will open a cryptopp-modern PR and link it here.
(In reply to Nuno Teixeira from comment #5) It wasn't upstream. *I* decided to stop installing the cryptest binary and accompanying data because I thought they were only useful for regression testing purposes. I was wrong. Some people have uses for cryptest outside of regession testing, however. That's why I hammered it into a tool option to make regression testing still work in the original port using gmake. Even the "modern" upstream CMake implementation looks sound, but there is some hammering to do. It's really not their problem, though.
Another thing to consider is who is https://github.com/Coralesoft? Are they another Jia Tan? With cryptographic software, it just raises big red flags for me without a deep code audit.
(In reply to Jason E. Hale from comment #7) > Are they another Jia Tan? +1. After the XZ incident (and even before FWIW, but that had greatly amplified the issue) my first reaction would be "no, why should I switch?" I don't see much reason to pivot away from a working dependency onto some "modern" fork without sufficient evidence that the old project is 100% abandoned, broken, repo archived, author resigning with a clear statement/explanation, things like that. Just that something is self-described as new or modern doesn't mean it's actually better.
(In reply to Jason E. Hale from comment #7) > Another thing to consider is who is https://github.com/Coralesoft? (...) Yes, that is a good question that needs to be clarified and that's why I've opened this PR. I see that Fedora 45 switched to -modern: https://src.fedoraproject.org/rpms/cryptopp
(In reply to Alexey Dokuchaev from comment #8) > (...) "no, why should I switch?" I was expecting something like this from you :) Thanks
Hi all, Nuno asked me to join the discussion. I'm Colin, the maintainer of cryptopp-modern, based in New Zealand. To answer the question about CoraleSoft directly, it isn't a company or organisation. CoraleSoft is the name I use for my public software work and GitHub organisation name. cryptopp-modern is my work and I am responsible for every change that lands. The questions about trust are fair, particularly for a cryptographic library. I didn't originally set out to replace Crypto++. In October 2025 I contacted Jeffery Walton (noloader) and offered to help with upstream maintenance. I also reached out through the upstream mailing list and repository. There had been very little upstream activity through 2025 and I wasn't able to get a response at the time, so I started maintaining and modernising the code independently. I have treated Crypto++ as the upstream project rather than as a competitor. When security or correctness issues are raised there, I generally triage them against cryptopp-modern, fix the fork where applicable, and submit fixes upstream as well. Two recent examples have been reviewed and merged upstream: * weidai11/cryptopp#1363: ChaCha SIMD feed-forward carry * weidai11/cryptopp#1371: invalid DEFLATE HLIT handling Several others are open upstream, including #1365 and #1367, and Jeff and I are currently discussing #1355. My upstream contributions can be seen here: https://github.com/weidai11/cryptopp/pulls?q=author%3ACoralesoft On the Jia Tan comparison, I understand the concern. I don't think the useful answer is for me to say that I can be trusted. What I can provide is provenance that can be independently checked. cryptopp-modern starts from Crypto++ 8.9.0 and its history is public. Every change since can be reviewed against that baseline, FORK.md documents the relationship with upstream, and release archives are signed using the key published in KEYS. Security and correctness fixes are tracked publicly, including cases where a cryptopp-modern release itself has been wrong. I should also be clear that cryptopp-modern has not undergone a complete independent security audit. Upstream review of individual fixes, distribution testing and external test vectors are useful independent checks, but I don't consider any of those a substitute for an audit. (In reply to Alexey Dokuchaev from comment #8) I think that position is reasonable. Crypto++ 8.9.0 is not archived and upstream development has not stopped completely. If a FreeBSD port is working well with it and has no reason to change, staying there is a perfectly reasonable choice. cryptopp-modern exists for consumers who need newer algorithms, current toolchain and build support, security and correctness fixes, or a more predictable release cadence. Whether those differences justify moving is a decision for each consumer and port maintainer. On the cryptest request from comment #2: that's reasonable, and I'm happy to add an install option for cryptest and its test data so the port doesn't have to patch around it. If you open an issue for this on cryptopp-modern I'll pick it up from there. If there are CMake changes that would make the FreeBSD port cleaner, I'm also happy to take that feedback and fix what makes sense in cryptopp-modern. Colin Brown cryptopp-modern / CoraleSoft
(In reply to Jason E. Hale from comment #2) >I've had users wanting bin/cryptest installed by default. The current security/ >cryptopp-modern does not provide this binary even optionally. cryptest.exe is builded when cmake option CRYPTOPP_BUILD_TESTING is set to true and it can be found at .build: (tests run on poudriere jail) ./cryptest.exe v All tests passed! Seed used was 1786453623 Test started at Tue Aug 11 13:07:03 2026 Test ended at Tue Aug 11 13:08:20 2026 ./cryptest.exe tv Tests complete. Total tests = 18540. Failed tests = 0. This means that required data are correctly found. I see that cryptest.exe have other usefull utilities to users so I will take a closer look at cryptopp TOOLS port option and check if it should be imported to -modern. I feel that something is missing, maybe an upstream cmake option to build/install cryptest along with their data? Thoughts?
I took a closer look at this and tested the installed layout on FreeBSD 14.3. CMake already installs cryptest.exe, TestData and TestVectors when CRYPTOPP_BUILD_TESTING is enabled. The earlier poudriere run used cryptest from the build directory, so it did not exercise that layout. From an unrelated working directory, the installed cryptest passes both v and tv, and v also passes after installation to a relocated prefix. What is missing is a way to package cryptest without enabling the CTest suite. I'll add a CRYPTOPP_INSTALL_CRYPTEST option that builds and installs the binary and full test data independently. It will default to CRYPTOPP_BUILD_TESTING, preserving the current behaviour while giving the FreeBSD TOOLS option a clean upstream setting. The FreeBSD testing also exposed a CMake ordering bug in the compiled-in data path. This prevents an installed cryptest invoked by name through PATH on FreeBSD from finding its data. I'll fix that as part of the same change. I'll keep the existing cryptest.exe install name upstream. The FreeBSD port can package it as bin/cryptest. I'll link the change here once it is ready.
The change is ready: https://github.com/cryptopp-modern/cryptopp-modern/pull/76 It adds a separate CRYPTOPP_INSTALL_CRYPTEST option for installing cryptest.exe and its TestData and TestVectors. This can be enabled while CRYPTOPP_BUILD_TESTING is off, so the port does not need to enable the CTest suite just to ship the tool. The option follows CRYPTOPP_BUILD_TESTING by default, so the existing install behaviour does not change. The FreeBSD port can use it for TOOLS and package cryptest.exe as bin/cryptest. The same change fixes the CMake ordering bug in the compiled-in data path. I retested on FreeBSD 14.3 with both the default and cryptest-only configurations. The v and tv runs pass from an unrelated working directory in both cases, and an installed cryptest run by name through PATH now finds its data. This will be included in the next release.