From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D8666158013 for ; Sun, 26 Sep 2021 19:42:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8463AE09E0; Sun, 26 Sep 2021 19:41:57 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0AB2CE09CA for ; Sun, 26 Sep 2021 19:41:57 +0000 (UTC) From: Sam James Message-Id: <92006424-FB7A-464B-B1E0-8302203B3C0F@gentoo.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FF3A09FD-9DF1-46D1-AC3D-72B1187741DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [gentoo-dev] Guidance on distributed patented software Date: Sun, 26 Sep 2021 20:41:35 +0100 In-Reply-To: <3cae0e4a-b19d-16a2-11b5-037d8cdfe763@gentoo.org> Cc: licenses@gentoo.org, base-system@gentoo.org To: gentoo-dev@lists.gentoo.org References: <22b6bfa3-d464-4f97-f6ac-306479ae3bbf@gentoo.org> <20210924095510.6ff13620@computer> <3cae0e4a-b19d-16a2-11b5-037d8cdfe763@gentoo.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Archives-Salt: 94fd7753-4777-4ea5-b0b7-b22b1220a84b X-Archives-Hash: 99551035af66db79f60c6bd8ef7138a8 --Apple-Mail=_FF3A09FD-9DF1-46D1-AC3D-72B1187741DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Sep 2021, at 20:44, Joshua Kinard wrote: >=20 >> [snip] >>=20 >> ECDSA and the NIST curves have been around since > 20 years, so it's >> simply impossible that there are any valid patents covering those. >> (There is of course a slight possibility that there may be patents >> covering specific implementation details of ECDSA/NIST curves that = were >> only described later.) >=20 > Then we are either A) being too paranoid and should just drop bindist = from > the OpenSSL ebuilds, or B) we are not being paranoid enough and = packages > like dropbear/libtomcrypt need bindist added, no? It seems we're = stuck in > the middle here because we don't have the right information. If Red = Hat or > IBM are being non-responsive over this, then surely some other distro = out > there has already figured things out? >=20 Agreed. Furthermore, it's not clear to me that Debian or Ubuntu are "hobbling" their OpenSSL implementations. I may have missed something, but I don't see anything in: - = https://salsa.debian.org/debian/openssl/-/tree/debian/unstable/debian/patc= hes (or the rules file) - = https://git.launchpad.net/ubuntu/+source/openssl/tree/debian/patches?h=3Da= pplied/ubuntu/impish (or the rules file) The only thing I have found is an old bug report for Ubuntu = (https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/597984) referencing disabling some non-EC parts. >=20 >> I'm not entirely sure what you'd like to ask the libtomcrypt authors. >> "We think there may be patents, but we don't know. Did you consider >> that?" >=20 > No, actually, I was thinking something more along the lines of "Hey, = are you > aware of these supposed patent claims about ECC/ECDSA implementations = that > Red Hat says exist, and if so, did you do any research on them that = you > could possibly share that led you to feeling confident to release your > implementation into the public domain". I'd like to make some points about our continued use of the "hobble" = patch for at least < OpenSSL 3 too: - RH won't publicly say what they're worried about wrt EC in OpenSSL. = This could be to avoid patent trolls, but this isn't really consistent with the patch = being "enough" to protect them - or us - anyway? - We don't know what patents the Fedora patch is allegedly preventing us from infringing. - If Fedora's patch is based on legal advice, there's no reason to = believe that it necessarily applies to us. - We have no way of verifying the correctness (or completeness) of the = Fedora patch we use because it is unclear what it is protecting against. - Even the latest version of Fedora's hobble patch _script_ only = references patents expiring, at the latest, in 2020: = https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl. And, as you observed, this doesn't appear to be applied consistently = anyway. Dropbear in Fedora appears to allow EC. Right now, I'm far more concerned about the possible security impact of applying patches whose correctness is not vouched for, nor do we truly understand their purpose. In addition, some of the changes in our current OpenSSL 1.1.x patches = are fragile and easily mis-applied or mis-rebased. Here's an example of such a = possibly problematic hunk: @@ -2026,9 +1945,9 @@ int speed_main(int argc, char **argv) # endif # ifndef OPENSSL_NO_EC - ecdsa_c[R_EC_P160][0] =3D count / 1000; - ecdsa_c[R_EC_P160][1] =3D count / 1000 / 2; - for (i =3D R_EC_P192; i <=3D R_EC_P521; i++) { + ecdsa_c[R_EC_P224][0] =3D count / 1000; + ecdsa_c[R_EC_P224][1] =3D count / 1000 / 2; + for (i =3D R_EC_P256; i <=3D R_EC_P521; i++) { ecdsa_c[i][0] =3D ecdsa_c[i - 1][0] / 2; ecdsa_c[i][1] =3D ecdsa_c[i - 1][1] / 2; if (ecdsa_doit[i] <=3D 1 && ecdsa_c[i][0] =3D=3D 0) @@ -2040,7 +1959,7 @@ int speed_main(int argc, char **argv) } } } -# ifndef OPENSSL_NO_EC2M +# if 0 By not using easy macros where possible, we're making it far easier to = have compile-time or even runtime errors. >=20 > But I am open to better language. I just don't wanna sit here not = knowing. > Someone out there has to have the right information to settle this. >=20 Yep. We consult legal advice or stop using half-measures. Best, sam --Apple-Mail=_FF3A09FD-9DF1-46D1-AC3D-72B1187741DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmFQzPBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDv8kwf+JeEFv91XhX/LkqpartD/xR4ydt9y2Go302fsZD+A6C9ybOceHP3LqqDB YTGe1eSqj5s0LvkGw1wqFNaiLr5sH00tzIL8ZXOayWHdtNf9Xa5o8ysTsR34l1hc IlK9TR9S4VRwJdy+bEfPk4lSzxoWKp5SVqBkW1jqUxJMVoBZRMHlye2Ajlf3CNBu vaHdcGN/Rw5Q7DNLhZ3f2xjGvA2+aCW7jPF74f1OPccl9/r3ZYtDi35s/sgj5/oF c4GAJ0/Yyuty60WBPbNWmikI9DIWRS+VR2mEoRfJqR8rwDULqD4Ty8Wvf3td9YkZ S7uR4vxYINUyxeHQXb+4WNxnGqrwmw== =W4xR -----END PGP SIGNATURE----- --Apple-Mail=_FF3A09FD-9DF1-46D1-AC3D-72B1187741DF--