[
https://issues.apache.org/jira/browse/HDDS-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-10935:
--------------------------------
Description:
As we move forward with crypto-compliance related development, in order to move
away from a direct dependency on BouncyCastle, we need to define interfaces for
those operations that rely on BouncyCastle in the base implementation.
As outlined in the proposed design under HDDS-10234, the desirable way of doing
this is to provide BouncyCastle based operations via a Service Provider
Interface that can be loaded dynamically based on the set crypto compliance
mode.
The related generic code that the rest of the codebase can rely on is good to
be moved to its own module, as with that that module can provide us our
cryptographic boundary and can help us abstract away from the actually used
crypto functions in parallel with JCE.
In parallel with the hdds-crypto module, we will need an implementation for the
Service Provider Interface, and related classes, that encapsulates our
BouncyCastle dependency and provides the default implementation for runtimes
that are running without any crypto-compliance related restrictions.
Hence this JIRA is to create the base hdds-crypto and hdds-crypto-default
modules as a first step.
was:
As we move forward with crypto-compliance related development, in order to move
away from a direct dependency on BouncyCastle, we need to define interfaces for
those operations that rely on BouncyCastle in the base implementation.
As outlined in the proposed design under HDDS-10234, the desirable way of doing
this is to provide BouncyCastle based operations via a Service Provider
Interface that can be loaded dynamically based on the set crypto compliance
mode.
The related generic code that the rest of the codebase can rely on is good to
be moved to its own module, as with that that module can provide us our
cryptographic boundary and can help us abstract away from the actually used
crypto functions in parallel with JCE.
Hence this JIRA is to create the base hdds-crypto module as a first step.
> Create hdds-crypto and hdds-crypto-default modules
> --------------------------------------------------
>
> Key: HDDS-10935
> URL: https://issues.apache.org/jira/browse/HDDS-10935
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: Security
> Reporter: István Fajth
> Assignee: István Fajth
> Priority: Major
> Labels: pull-request-available
>
> As we move forward with crypto-compliance related development, in order to
> move away from a direct dependency on BouncyCastle, we need to define
> interfaces for those operations that rely on BouncyCastle in the base
> implementation.
> As outlined in the proposed design under HDDS-10234, the desirable way of
> doing this is to provide BouncyCastle based operations via a Service Provider
> Interface that can be loaded dynamically based on the set crypto compliance
> mode.
> The related generic code that the rest of the codebase can rely on is good to
> be moved to its own module, as with that that module can provide us our
> cryptographic boundary and can help us abstract away from the actually used
> crypto functions in parallel with JCE.
> In parallel with the hdds-crypto module, we will need an implementation for
> the Service Provider Interface, and related classes, that encapsulates our
> BouncyCastle dependency and provides the default implementation for runtimes
> that are running without any crypto-compliance related restrictions.
> Hence this JIRA is to create the base hdds-crypto and hdds-crypto-default
> modules as a first step.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
