I recently noticed some breaking bugs in https://github.com/XboxDev/xbedump/issues/9 which affect giant.c; a variation of that code has found its way into src/common/crypto/EmuRSA.cpp (initially contributed to Cxbx-R by @ergo720).
@ergo720 took the code without the license text or copyright mentions. The license, however, is rather restrictive: it affects monetary payout rules, so it's risky actually.
The code only claims that it came from XQEMU and that it's GPLv2 - which is false. The repository was only hosted / archived on the XQEMU GitHub, but we never (to my knowledge) put a GPL on it.
Although the source project itself doesn't have that explicit copyright header on the files, it has a generic README:
Copyright (c) 1996-2014, Mersenne Research, Inc. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:(1) Redistributing source code must contain this copyright notice,
limitations, and disclaimer.
(2) If this software is used to find Mersenne Prime numbers, then
GIMPS will be considered the discoverer of any prime numbers found
and the prize rules at http://mersenne.org/prize.htm will apply.THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
So if someone took your giants.c from Cxbx-R (or xbedump for that matter) and somehow managed to calculate a mersenne prime number, then they'd not be eligble for payout, which also means you might get sued for the losses.
More importantly, the license restriction also make the code incompatible with the GPL.
This is not an issue for xbedump (which is in an unknown copyright state anyway), but it does affect Cxbx-R (which explicitly labels this file as GPL and depends on it in other GPL code).
@Cxbx-Reloaded
Sorry, that copyright notice wasn't present in the xbedump tool I took the code from, so I didn't notice it. I'll remove all the relevant code than.
A replacement is preferred over removal: we鈥檙e currently working on System Link/Network support which requires working crypto to function.
Let鈥檚 investigate alternative implementations and get this resolved as soon as possible.
A few replacement candidates:
Also, here an interesting remark regarding RSA and GPL : https://lists.fedoraproject.org/archives/list/[email protected]/thread/XMLZTXN7ZHCKQLKGCQ33SYQTDGL5HGOC/
@ergo720 & @PatrickvL
Would it be better to use Mbed TLS library for RSA? Since ReactOS is using it. Plus it does have cmake support.
Links:
Nope, I already tried it but it refuses to calculate the modular exponentiation when the modulus is even and errors instead (according to here https://gmplib.org/manual/Integer-Exponentiation.html, it's done for security reasons). Unfortunately, the XcModExp kernel test shows that the function gladly accepts an even modulus, so we cannot discard it.
One could send a patch to upstream mbedtls to make this a preprocessor / runtime check for RSA.
Also you can still re-use the mbedtls MPI (mbedtls_mpi_exp_mod) which does not have those requirements. I'm not sure about the RSA functions the kernel provides, but as this has no relevance to security, you could also build you own crypto based on XcModExp or the mbedtls MPI (which should be trivial for most use cases of RSA).
If mbedtls is embedded (as it currently is) then you can also just disable those checks.
EmuRSA has been cleaned up by replacing the RSA implementation with libtommath/libtomcrpt, and portions of GPL licensed bignum.h from mbtls/ReactOS.
Please create a new issue for any further problems
Most helpful comment
One could send a patch to upstream mbedtls to make this a preprocessor / runtime check for RSA.
Also you can still re-use the mbedtls MPI (
mbedtls_mpi_exp_mod) which does not have those requirements. I'm not sure about the RSA functions the kernel provides, but as this has no relevance to security, you could also build you own crypto based onXcModExpor the mbedtls MPI (which should be trivial for most use cases of RSA).If mbedtls is embedded (as it currently is) then you can also just disable those checks.