Thank you all for your opinions. Very appreciated. I finally got some time to play with the patch of Ayushi Singh.
As I am on x86 and I wanted to simulate what would happen to users on ARM, I just did it other way around - I introduced the dependency with classifier linux-aarch_64. The whole setup of that crypto provider consists of two steps. The first is the "installation". The second the is the "verification / check" that it is installed correctly by performing a "health check". Surprisingly, the installation step succeeded on x86 even the dependency was for aarch. However, the startup check went to else branch (2) and I saw that the provider was not Corretto provider but the default - SunJCE. So that tells me that it basically falls back to the default which is what we want. I think this might work, if it is available, it will use it, if not, we emit a big fat warning. We could introduce a flag into crypto_provider's "parameters" (as it is configured by ParameterizedClass) which would fail the startup if it is not installed and by default it would be turned off so for people on ARM it would just emit warning. 1) https://github.com/apache/cassandra/blob/9b0b0f03f97f0bb1d7c0295cdfa3b3da80d1c3b8/src/java/org/apache/cassandra/security/DefaultCryptoProvider.java 2) https://github.com/apache/cassandra/blob/9b0b0f03f97f0bb1d7c0295cdfa3b3da80d1c3b8/src/java/org/apache/cassandra/security/DefaultCryptoProvider.java#L64-L70 ________________________________________ From: Abe Ratnofsky <a...@aber.io> Sent: Thursday, July 20, 2023 23:59 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Using ACCP or tc-native by default NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. This feels analogous to other past discussions around prioritizing a config that enables new users to clone + build + run as easily as possible, vs. having better prod recommendations out of the box. Both are important. I personally think we should default configuration to make it just work for new users, and have a config to allow power users to fail if ACCP is not present, and warn once on startup if we tolerate missing ACCP but detect it is absent. > On Jul 20, 2023, at 14:51, Brandon Williams <dri...@gmail.com> wrote: > > I think we could special-case and default to 'auto' but allow other > more explicit options. > > Kind Regards, > Brandon > >> On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev >> <dev@cassandra.apache.org> wrote: >> >> In general I agree with Joey -- but I would prefer if this behavior is >> configurable, e.g. there is an option to get a startup failure if the >> configured fastest provider can't run for any reason to avoid a "silent" >> performance degradation as Jordan was experiencing. >> >> Thanks, >> German >> >> ________________________________ >> From: Joseph Lynch <joe.e.ly...@gmail.com> >> Sent: Thursday, July 20, 2023 7:38 AM >> To: dev@cassandra.apache.org <dev@cassandra.apache.org> >> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default >> >> Having native dependencies shouldn't make the project x86 only, it >> should just accelerate the performance on x86 when available. Can't we >> just try to load the fastest available provider (so arm will use >> native java but x86 will use proper hardware acceleration) and failing >> that fall-back to the default? If I recall correctly from the >> messaging service patches (and zstd/lz4) it's reasonably >> straightforward to try to load native code and then fail-back if you >> fail. >> >> -Joey >> >>> On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan <jeremiah.jor...@gmail.com> >>> wrote: >>> >>> Maybe we could start providing Dockerfile’s and/or make arch specific >>> rpm/deb packages that have everything setup correctly per architecture? >>> We could also download them all and have the startup scripts put stuff in >>> the right places depending on the arch of the machine running them? >>> I feel like there are probably multiple ways we could solve this without >>> requiring users to jump through a bunch of hoops? >>> But I do agree we can’t make the project x86 only. >>> >>> -Jeremiah >>> >>>> On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan >>>> <stefan.mikloso...@netapp.com> wrote: >>>> >>>> Hi, >>>> >>>> as I was reviewing the patch for this feature (1), we realized that it is >>>> not quite easy to bundle this directly into Cassandra. >>>> >>>> The problem is that this was supposed to be introduced as a new dependency: >>>> >>>> <dependency> >>>> <groupId>software.amazon.cryptools</groupId> >>>> <artifactId>AmazonCorrettoCryptoProvider</artifactId> >>>> <version>2.2.0</version> >>>> <classifier>linux-x86_64</classifier> >>>> <dependency> >>>> >>>> Notice "classifier". That means that if we introduced this dependency into >>>> the project, what about ARM users? (there is corresponding aarch >>>> classifier as well). ACCP is platform-specific but we have to ship >>>> Cassandra platform-agnostic. It just needs to run OOTB everywhere. If we >>>> shipped that with x86 and a user runs Cassandra on ARM, I guess that would >>>> break things, right? >>>> >>>> We also can not just add both dependencies (both x86 and aarch) because >>>> how would we differentiate between them in runtime? That all is just too >>>> tricky / error prone. >>>> >>>> So, the approach we want to take is this: >>>> >>>> 1) nothing will be bundled in Cassandra by default >>>> 2) a user is supposed to download the library and put it to the class path >>>> 3) a user is supposed to put the implementation of ICryptoProvider >>>> interface Cassandra exposes to the class path >>>> 3) a user is supposed to configure cassandra.yaml and its section >>>> "crypto_provider" to reference the implementation he wants >>>> >>>> That way, we avoid the situation when somebody runs x86 lib on ARM or vice >>>> versa. >>>> >>>> By default, NoOpProvider will be used, that means that the default crypto >>>> provider from JRE will be used. >>>> >>>> It can seem like we have not done too much progress here but hey ... we >>>> opened the project to the custom implementations of crypto providers a >>>> community can create. E.g. as 3rd party extensions etc ... >>>> >>>> I want to be sure that everybody is aware of this change (that we plan to >>>> do that in such a way that it will not be "bundled") and that everybody is >>>> on board with this. Otherwise I am all ears about how to do that >>>> differently. >>>> >>>> (1) https://issues.apache.org/jira/browse/CASSANDRA-18624 >>>> >>>> ________________________________________ >>>> From: German Eichberger via dev <dev@cassandra.apache.org> >>>> Sent: Friday, June 23, 2023 22:43 >>>> To: dev >>>> Subject: Re: [DISCUSS] Using ACCP or tc-native by default >>>> >>>> NetApp Security WARNING: This is an external email. Do not click links or >>>> open attachments unless you recognize the sender and know the content is >>>> safe. >>>> >>>> >>>> >>>> +1 to ACCP - we love performance. >>>> ________________________________ >>>> From: David Capwell <dcapw...@apple.com> >>>> Sent: Thursday, June 22, 2023 4:21 PM >>>> To: dev <dev@cassandra.apache.org> >>>> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default >>>> >>>> +1 to ACCP >>>> >>>> On Jun 22, 2023, at 3:05 PM, C. Scott Andreas <sc...@paradoxica.net> wrote: >>>> >>>> +1 for ACCP and can attest to its results. ACCP also optimizes for a range >>>> of hash functions and other cryptographic primitives beyond TLS >>>> acceleration for Netty. >>>> >>>> On Jun 22, 2023, at 2:07 PM, Jeff Jirsa <jji...@gmail.com> wrote: >>>> >>>> >>>> Either would be better than today. >>>> >>>> On Thu, Jun 22, 2023 at 1:57 PM Jordan West >>>> <jw...@apache.org<mailto:jw...@apache.org>> wrote: >>>> Hi, >>>> >>>> I’m wondering if there is appetite to change the default SSL provider for >>>> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our >>>> deployment as well as others I’m aware of make this change in their fork >>>> and it can lead to significant performance improvement. When recently >>>> qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies >>>> were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and >>>> also requires some amount of customization. I think it could be great for >>>> the wider community to adopt it. >>>> >>>> The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. >>>> Anything else I am missing before opening a JIRA and submitting a patch? >>>> >>>> Jordan >>>> >>>> >>>> [1] >>>> https://github.com/corretto/amazon-corretto-crypto-provider<https://urldefense.com/v3/__https://nam04.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fcorretto*2Famazon-corretto-crypto-provider&data=05*7C01*7CStefan.Miklosovic*40netapp.com*7C4d73ac88a46f4386826e08db742a82f3*7C4b0911a0929b4715944bc03745165b3a*7C0*7C0*7C638231498154472637*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=IvtqDSHL*2BOunrhagmYKTfPa8zlknIPijr8TwVvCKKQw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PbtH5S7Ebw!fuCaq60SW0zceq0aFBYG3J8ga4gAtUG5n1qZyiyRSo8X-epQfmmdXqSOXzX4tQbeAMSc5QuTXtz2W0xWyPp59OcTF5Ra$ >>>> > >>>> >>>>
