tustvold commented on issue #413:
URL:
https://github.com/apache/arrow-rs-object-store/issues/413#issuecomment-3160703614
Given there are varying compliance requirements, and the nature of such
requirements is that they're often unrelated to the quality of the
implementations in question, I wonder if we might instead explore a mechanism
by which alternative crypto implementations can be provided out of tree? This
would allow users to bring along whatever crypto implementation their
cybersecurity team happens to have been approved, without burdening us with
maintaining multiple parallel implementations. Perhaps we could introduce some
generic `CryptoProvider` trait that would use ring by default, but allow
specifying something different?
> I get your point but if you have mutually exclusive features and you have
transitive dependencies on object store with different crypto providers enabled
then my understanding is you will not be able to compile which is why it's
discouraged. Not sure if it's going to be a problem in practice but sounds like
a risk.
I agree that mutually exclusive features are best avoided and go against
established best practices (cargo cannot handle them very well).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
