Charles Oliver Nutter wrote:
Ola Bini wrote:
OK guys,
I think that the approach of using BC directly is not the right one.
Instead, I've just committed all that's needed for us to avoid
globally registering a Provider.
Now, in this process I also found out the reason why I had it like I
did earlier - namely, many of the methods in the BC CMS package takes
a provider String, but not a Provider instance. And there is in fact
a few places in java.security that does the same thing. Very
annoying. The problem is - for the string to work, the provider named
needs to be globally registered.
I have taken a fairly brute force approach to this problem - namely
implementing a method that will insert the provider, run the code in
question, and the remove the provider directly after that. It works
and all tests pass (except for the Cipher one, and I think we might
just revert that).
Is it possible for us to implement those pieces that require a
registered provider using BC APIs directly?
Not really. They seem to be implemented directly that way.
If the approach of passing in a provider for everything works for most
cases, what about modifying BC to accept provider where it doesn't
now? I would agree that if we can get everything working using JCE
interfaces passed an explicit provider, we'd be better off than any
other solution. I do not particularly like temporarily registering the
provider since it won't be thread/app safe and it's almost certain to
bite us at some point in the future.
Well, possibly. On the other hand, all the problems caused by
registering a provider is safe for this temporary registration. The
actual provider list is obviously synchronized by the JVM. I don't see
any practical threading issues with it.
--
Ola Bini (http://ola-bini.blogspot.com)
JRuby Core Developer
Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
Practical JRuby on Rails (http://apress.com/book/view/9781590598818)
"Yields falsehood when quined" yields falsehood when quined.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
