search

briansmith / ring

Safe, fast, small crypto using Rust
Other
3.77k stars 708 forks source link

Transition to Apache-2.0-based version of code from OpenSSL/BoringSSL? #1318

Open joshtriplett opened 3 years ago

joshtriplett commented 3 years ago

OpenSSL just recently released a release candidate for 3.0, and the 3.0 branch is where the relicensing to purely Apache 2.0 has happened. Hopefully, BoringSSL will be able to follow suit, rebasing atop the new version of OpenSSL and incorporating the license change. And since it and ring both use ISC for new code, that would potentially allow dropping the old GPL-incompatible OpenSSL license at that point.

Given that this OpenSSL 3.0 is still in the release candidate stage, and that even once the final 3.0 release occurs it may take time for BoringSSL to transition (and I'm not sure to what degree ring depends on BoringSSL-specific changes that would prevent using code from OpenSSL), I'm definitely not expecting this to happen soon. However, I wanted to start the conversation to see if this seems like a reasonable goal to aim for. I also wanted to find out if it would make sense to adopt code from OpenSSL 3.0 (once released), or if there needs to be a hard dependency on BoringSSL making the transition first.

Thanks again for working on ring!

briansmith commented 3 years ago

One of my goals for this project from the beginning was to make it possible to use ring within the Linux kernel. At one point we even updated the license text in the files to add whatever text was needed to make that work, for the (PerlAsm) assembly files that are shared with the Linux kernel.

In the OpenSSL mailing list thread about Apache 2.0 licensing, I voiced my concern about the Linux compatibility issue but it was ignored.

I wish somebody would help sort that out.

joshtriplett commented 3 years ago

@briansmith I'd love to see that happen, but since Apache 2.0 is incompatible with GPLv2, that would require taking no code from OpenSSL or BoringSSL, except code that's also available under a GPLv2-compatible license such as the files that are shared with the Linux kernel. Is that assembly everything that ring takes from BoringSSL/OpenSSL, or does ring use additional files from BoringSSL/OpenSSL that are exclusively available under Apache 2.0?

If ring doesn't actually need anything except the files shared with the Linux kernel, I'd be happy to help sort that out and see if we can get ring entirely under a GPLv2-compatible license.

briansmith commented 3 years ago

My intent has been to gradually replace the C code that is under the OpenSSL license with new ISC-licensed Rust code and/or MIT-licensed code e.g. from Fiat-Crypto, etc. We're actually not that far from that state already. Note also that we have some code licensed under the ISC license that is under the Apache License in OpenSSL, e.g. the nistz256 code, with this in mind.

It would probably be good for somebody to assemble a spreadsheet or something of the various files and what strategy we'd use to make them Linux-compatible while getting rid of the use of the old OpenSSL license.

briansmith commented 3 years ago

BTW, is your goal to get rid of the use of OpenSSL license, or something else?

joshtriplett commented 3 years ago

@briansmith Yes, specifically because I want to be able to use ring and rustls in GPL-compatible software.

Whether that's by switching to Apache 2.0 code and being GPLv3-compatible, or switching to ISC-licensed or MIT-licensed code and being GPLv2-compatible as well, either way works for me. I'd just like to avoid the current situation, where the best available Rust crypto library can't be used from GPLed code.

joshtriplett commented 3 years ago

I reviewed every single file in the ring crate in commit 5d8dcf160cc7a0b4904bc0b07fe7be546fa1c4a1. For every file that wasn't obviously under the ISC license, I categorized the relevant licensing details for that file, to serve as a TODO list for eliminating code under the OpenSSL license from the ring crate.

OpenSSL

The following files are under the OpenSSL license, without any mitigating factors. These files could either be obtained from OpenSSL 3.0 to move to Apache 2.0 (GPLv3+ compatible), or replaced in their entirety (not incrementally) from some non-OpenSSL source under a permissive GPLv2-compatible license:

crypto/constant_time_test.c
crypto/cpu-intel.c
crypto/fipsmodule/aes/asm/vpaes-armv7.pl
crypto/fipsmodule/aes/asm/vpaes-armv8.pl
crypto/fipsmodule/aes/asm/vpaes-x86.pl
crypto/fipsmodule/aes/asm/vpaes-x86_64.pl
crypto/fipsmodule/bn/internal.h
crypto/fipsmodule/bn/montgomery.c
crypto/fipsmodule/bn/montgomery_inv.c
crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl
crypto/fipsmodule/ec/p256-x86_64.c
crypto/fipsmodule/ec/p256-x86_64.h
crypto/fipsmodule/ec/p256_shared.h
crypto/internal.h
crypto/mem.c
crypto/fipsmodule/sha/asm/sha512-x86_64.pl
crypto/perlasm/arm-xlate.pl
crypto/perlasm/x86_64-xlate.pl
crypto/perlasm/x86asm.pl
crypto/perlasm/x86gas.pl
crypto/perlasm/x86nasm.pl
include/ring-core/aes.h
include/ring-core/arm_arch.h
include/ring-core/base.h
include/ring-core/cpu.h
include/ring-core/mem.h
include/ring-core/type_check.h

OpenSSL + GPL

The following files are under the OpenSSL license, but have an additional permission that may specifically allow using them under the GPL. (Some of them have CRYPTOGAMS notices as well, but as noted in the CRYPTOGAMS section, those may not cover more recent changes and it's not obvious if some of the changes are exclusively offered under OpenSSL or GPL but not 3-clause BSD.) An OpenSSL/GPL dual license is still not ideal, and it'd be helpful to replace these files with either a permissively licensed source that's GPLv2-compatible, or if other files are being obtained from an Apache 2.0 source, these could be obtained from an Apache 2.0 source and checked to see if they're identical to allow for dual-licensing.

crypto/fipsmodule/aes/asm/bsaes-armv7.pl
crypto/fipsmodule/sha/asm/sha256-armv4.pl
crypto/fipsmodule/sha/asm/sha512-armv4.pl
crypto/fipsmodule/sha/asm/sha512-armv8.pl

Generated file with license header

The following file has an OpenSSL license header, but it's generated from ./crypto/fipsmodule/ec/make_tables.go, which is under the ISC license. make_tables.go is generating the OpenSSL license header. It's not obvious that there's anything copyrightable here that's actually under the OpenSSL license, except possibly a comment, and if necessary that comment could be removed or turned into a reference to the same information elsewhere.

crypto/fipsmodule/ec/p256-x86_64-table.h

Docs

The following documentation file is derived from OpenSSL, so it's under the OpenSSL license. It isn't compiled into the code, so it doesn't affect the license of works linked to ring, but it affects the license of the ring source. We could just remove it.

crypto/perlasm/readme

CRYPTOGAMS (but what about modifications?)

The following files contain license notices like this:

# Licensed under the OpenSSL license (the "License").  You may not use
# this file except in compliance with the License.  You can obtain a copy
# in the file LICENSE in the source distribution or at
# https://www.openssl.org/source/license.html

#
# ====================================================================
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
# project. The module is, however, dual licensed under OpenSSL and
# CRYPTOGAMS licenses depending on where you obtain it. For further
# details see http://www.openssl.org/~appro/cryptogams/.
# ====================================================================

The linked CRYPTOGAMS site offers a choice of 3-clause BSD or the (unversioned) GPL.

However, this does not seem sufficient to make these files usable. Many of these files have clearly been modified by others since their original submission, and the license notice above doesn't seem to cover subsequent modifications. I think we need to take "depending on where you obtain it" seriously, and seek to obtain compatible versions of these files from an unambiguously permissive source.

crypto/chacha/asm/chacha-armv4.pl
crypto/chacha/asm/chacha-armv8.pl
crypto/chacha/asm/chacha-x86.pl
crypto/chacha/asm/chacha-x86_64.pl
crypto/fipsmodule/aes/asm/aesni-x86.pl
crypto/fipsmodule/aes/asm/aesni-x86_64.pl
crypto/fipsmodule/aes/asm/aesv8-armx.pl
crypto/fipsmodule/bn/asm/armv4-mont.pl
crypto/fipsmodule/bn/asm/armv8-mont.pl
crypto/fipsmodule/bn/asm/x86-mont.pl
crypto/fipsmodule/bn/asm/x86_64-mont.pl
crypto/fipsmodule/bn/asm/x86_64-mont5.pl
crypto/fipsmodule/modes/asm/aesni-gcm-x86_64.pl
crypto/fipsmodule/modes/asm/ghash-armv4.pl
crypto/fipsmodule/modes/asm/ghash-neon-armv8.pl
crypto/fipsmodule/modes/asm/ghash-x86.pl
crypto/fipsmodule/modes/asm/ghash-x86_64.pl
crypto/fipsmodule/modes/asm/ghashv8-armx.pl
joshtriplett commented 3 years ago

@briansmith I'd like to suggest an incremental solution, if you're open to it:

Anything that's compatible with the OpenSSL license is going to be compatible with Apache 2.0. And it'd be much more straightforward to port replacements from OpenSSL 3.0 than from any other source. Would you be willing to accept PRs implementing the incremental step of moving from the OpenSSL license to Apache 2.0? This would not preclude later migrating again to a source under MIT/ISC/BSD-3/etc.

briansmith commented 3 years ago

@joshtriplett I think it would be good to have a call to figure this out. I suspect this is an urgent thing for you but I don't understand why so it isn't an urgent thing for me. In terms of accepting things from OpenSSL instead of BoringSSL, I usually try to avoid doing that because BoringSSL is an incredible level of quality control on top of OpenSSL's quality control. Also, BoringSSL tends to make significant, important, changes to the source code so that one can simply replace BoringSSL's same-named files with OpenSSL's same-named files. It looks like it would take many hours for me to sort out unless BoringSSL itself started doing its own license project.

joshtriplett commented 3 years ago

@briansmith I'd be happy to have a call if that would help. This isn't extremely urgent for me (and I'm not looking to take up a disproportionate amount of your bandwidth); it's just the kind of thing that takes a long enough time that I'd like to start on it sooner rather than later, and I have the bandwidth to prepare such changes now and may not later. A change like this has a long pipeline, from development to review to merge to release to downstream adoption/adaptation, and I still regularly encounter projects that haven't yet moved to the latest rustls. I'm used to this kind of thing taking more than a year.

For my part, my main rationales for this are:

If it helps, I'd be happy to do further analysis to determine which of the files in the list I gave above appears to have little to no changes between OpenSSL and BoringSSL. Also happy to provide any other information that would help reduce the amount of bandwidth this would take.

Thank you.

briansmith commented 3 years ago

If the goal is to be GPLv2 compatible as well as GPLv3 then Apache doesn't work, right? You'd only get GPLv3 compatibility, IIUC.

I think some assembly modules, I think more have been licensed with a GPLv2 exception specifically because the Linux kernel needed them, but that might not be reflected in the copy we have. So, in some cases we might be able to source/sync with the Linux kernel version of various important modules to add the GPL exception line to the license. Presumably it's a good idea for the Linux kernel and OpenSSL upstream and probably BoringSSL to sync their copies of these files, regardless of ring.

For the ones that aren't used in the Linux kernel and haven't been given the additional GPLv2 terms, we might consider different options, depending which and how many there are, and which targets are affected. For example, if we find all the x86_64 and aarch64 files can be made GPLv2 and GPLv3 compatible easily then we might consider dropping some of the assembly language optimizations for 32-bit x86 and/or 32-bit ARM. In some cases, e.g. SHA-*, I think we can replace the assembly language code with Rust code without hurting performance.

For the remaining C files, I think cpu-intel.c/cpu.h is the only one that would take more thinking to replace with Rust or alternatively-sourced/-licensed code. It's basically massaging the result of CPUID in some OpenSSL-specific way. Ideally we'd try to ensure the assembly language code is no longer depending on that massaging of the bits of the CPUID result; that may very well be the case for the assembly code that remains now.

crypto/constant_time_test.c

Not a big deal to get rid of this; we need to replace it with better testing of the constant-time primitives anyway.

crypto/fipsmodule/bn/internal.h crypto/fipsmodule/bn/montgomery.c

We should just rewrite it. I don't like that code anyway.

crypto/fipsmodule/bn/montgomery_inv.c

This is my code and it's already ISC licensed.

crypto/internal.h

What remains is originated from Google BoringSSL. Maybe it is in OpenSSL upstream now? I think there's probably a solution there.

crypto/mem.c crypto/include/ring-core/mem.h

These things are easily replaced.

briansmith commented 3 years ago

Replace with new Rust code after investigating whether it's practical:

crypto/cpu-intel.c
include/ring-core/cpu.h

Work with other users of this code to create Apache/GPLv2 dual-licensed version:

crypto/fipsmodule/aes/asm/vpaes-armv7.pl
crypto/fipsmodule/aes/asm/vpaes-armv8.pl
crypto/fipsmodule/aes/asm/vpaes-x86.pl
crypto/fipsmodule/aes/asm/vpaes-x86_64.pl
crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl
crpto/fipsmodule/sha/asm/sha512-x86_64.pl
include/ring-core/arm_arch.h

Don't worry about them since they aren't shipped in the crate:

crypto/perlasm/arm-xlate.pl
crypto/perlasm/x86_64-xlate.pl
crypto/perlasm/x86asm.pl
crypto/perlasm/x86gas.pl
crypto/perlasm/x86nasm.pl

Replace with better (probably mostly Rust) code:

crypto/fipsmodule/bn/internal.h
crypto/fipsmodule/bn/montgomery.c
crypto/fipsmodule/ec/p256-x86_64.c
crypto/fipsmodule/ec/p256-x86_64.h
crypto/fipsmodule/ec/p256_shared.h
crypto/mem.c
include/ring-core/aes.h
include/ring-core/mem.h
include/ring-core/base.h

ISC-licensed already:

crypto/fipsmodule/bn/montgomery_inv.c

Just stop shipping it in the crate:

crypto/constant_time_test.c

Ask Google to factor out what's here into a separate ISC-licensed header:

crypto/internal.h

What remains here is just a macro around static_assert/_Static_assert. Easily replaced.

include/ring-core/type_check.h
JockeTF commented 1 year ago

I'm guessing Ring still isn't compatible with GPLv3? I hadn't expected this and disabled the Rustls feature of sqlx for a personal project licensed under AGPLv3. While I don't need built-in TLS there, I'm curious if there have been any changes here over the last couple of years. Thanks a bunch for all your work!

briansmith commented 1 year ago

My goal is to get to GPLv3 compatibility. Basically the way to do that, AFAICT, is through attrition of all the OpenSSL-licensed code. I believe that's very doable and will mostly fall out naturally from the "get rid of all the C code" work.

briansmith commented 10 months ago

Issue #1827 includes details of the plans for removing the remaining OpenSSL-license-licensed C code. This issue contains some details about assembly/PerlAsm files. So I guess people interested in this should look at issue #1827, which provides hints for people who want to help move this along faster. Then we'll come back here and figure out what to do about the assembly licensing.