java.security.NoSuchAlgorithmException when running RDE Staging
555 views
Skip to first unread message
bfkelsey
Dec 12, 2016, 3:22:12 PM12/12/16
to nomulus-discuss
Hi all,
I am getting "Stage reduce-5c2b3d61-c5d6-4e5a-be56-80bf92b41053 was not completed successfuly (status=ERROR, message=java.security.ProviderException: java.security.NoSuchAlgorithmException: NativePRNG SecureRandom not available)" when Running the RDE staging job. Do you know what could be causing this. This is the first time we have really looked into this so it may have never worked for us. I have added the stacktrace below.
Thanks, Ben
com.google.appengine.tools.mapreduce.MapReduceJob handleException: MapReduce job failed because of: (MapReduceJob.java:500)
com.google.appengine.tools.mapreduce.MapReduceJobException: Stage reduce-5c2b3d61-c5d6-4e5a-be56-80bf92b41053 was not completed successfuly (status=ERROR, message=java.security.ProviderException: java.security.NoSuchAlgorithmException: NativePRNG SecureRandom not available)
at com.google.appengine.tools.mapreduce.impl.pipeline.ExamineStatusAndReturnResult.run(ExamineStatusAndReturnResult.java:33)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:42)
at com.google.appengine.tools.pipeline.impl.PipelineManager.runJob(PipelineManager.java:779)
at com.google.appengine.tools.pipeline.impl.PipelineManager.processTask(PipelineManager.java:523)
at com.google.appengine.tools.pipeline.impl.servlets.TaskHandler.doPost(TaskHandler.java:58)
at com.google.appengine.tools.pipeline.impl.servlets.PipelineServlet.doGet(PipelineServlet.java:105)
at com.google.appengine.tools.pipeline.impl.servlets.PipelineServlet.doPost(PipelineServlet.java:94)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at google.registry.model.ofy.OfyFilter.doFilter(OfyFilter.java:32)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.googlecode.objectify.cache.AsyncCacheFilter.doFilter(AsyncCacheFilter.java:59)
at com.googlecode.objectify.ObjectifyFilter.doFilter(ObjectifyFilter.java:49)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:446)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:453)
at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:274)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:312)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:304)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:450)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.ProviderException: java.security.NoSuchAlgorithmException: NativePRNG SecureRandom not available
at google.registry.rde.Ghostryde.getRandom(Ghostryde.java:400)
at google.registry.rde.Ghostryde.openEncryptor(Ghostryde.java:388)
at google.registry.rde.RdeStagingReducer.reduceWithLock(RdeStagingReducer.java:125)
at google.registry.rde.RdeStagingReducer.access$000(RdeStagingReducer.java:63)
at google.registry.rde.RdeStagingReducer$1.call(RdeStagingReducer.java:84)
at google.registry.rde.RdeStagingReducer$1.call(RdeStagingReducer.java:81)
at google.registry.model.server.Lock$LockingCallable.call(Lock.java:239)
at google.registry.model.server.Lock$LockingCallable.call(Lock.java:201)
at java.util.concurrent.FutureTask.run(FutureTask.java:260)
at java.util.concurrent.FutureTask.report(FutureTask.java:106)
at java.util.concurrent.FutureTask.get(FutureTask.java:200)
at com.google.common.util.concurrent.SimpleTimeLimiter.callWithTimeout(SimpleTimeLimiter.java:130)
at google.registry.model.server.Lock.executeWithLocks(Lock.java:189)
at google.registry.rde.RdeStagingReducer.reduce(RdeStagingReducer.java:88)
at google.registry.rde.RdeStagingReducer.reduce(RdeStagingReducer.java:63)
at com.google.appengine.tools.mapreduce.impl.ReduceShardTask.callWorker(ReduceShardTask.java:56)
at com.google.appengine.tools.mapreduce.impl.ReduceShardTask.callWorker(ReduceShardTask.java:29)
at com.google.appengine.tools.mapreduce.impl.WorkerShardTask.run(WorkerShardTask.java:124)
at com.google.appengine.tools.mapreduce.impl.shardedjob.ShardedJobRunner.runAndUpdateTask(ShardedJobRunner.java:404)
at com.google.appengine.tools.mapreduce.impl.shardedjob.ShardedJobRunner.runTask(ShardedJobRunner.java:386)
at com.google.appengine.tools.mapreduce.impl.handlers.MapReduceServletImpl.doPost(MapReduceServletImpl.java:109)
at com.google.appengine.tools.mapreduce.MapReduceServlet.doPost(MapReduceServlet.java:62)
... 30 more
Caused by: java.security.NoSuchAlgorithmException: NativePRNG SecureRandom not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
at java.security.SecureRandom.getInstance(SecureRandom.java:17)
at google.registry.rde.Ghostryde.getRandom(Ghostryde.java:398)
at google.registry.rde.Ghostryde.openEncryptor(Ghostryde.java:388)
at google.registry.rde.RdeStagingReducer.reduceWithLock(RdeStagingReducer.java:125)
at google.registry.rde.RdeStagingReducer.access$000(RdeStagingReducer.java:63)
at google.registry.rde.RdeStagingReducer$1.call(RdeStagingReducer.java:84)
at google.registry.rde.RdeStagingReducer$1.call(RdeStagingReducer.java:81)
at google.registry.model.server.Lock$LockingCallable.call(Lock.java:239)
at google.registry.model.server.Lock$LockingCallable.call(Lock.java:201)
at java.util.concurrent.FutureTask.run(FutureTask.java:260)
Ben McIlwain
Dec 12, 2016, 3:25:01 PM12/12/16
to bfkelsey, nomulus-discuss
Do you have a version of that stack trace with the newlines intact? That's hard to read.
--
NOTE: This is a public discussion list for the Nomulus domain registry project.
---
You received this message because you are subscribed to the Google Groups "nomulus-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nomulus-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomulus-discuss/51ade742-4be2-4760-b5a4-9a4ca6b663f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Greg Shikhman
Dec 12, 2016, 3:42:45 PM12/12/16
to Ben McIlwain, bfkelsey, nomulus-discuss
Ben, that's an issue we've run into internally before. NativePRNG causes issues on the appengine JDK environment. We'll investigate this internally, as it should have been fixed in the runtime already.
To unsubscribe from this group and stop receiving emails from it, send an email to nomulus-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomulus-discuss/51ade742-4be2-4760-b5a4-9a4ca6b663f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
NOTE: This is a public discussion list for the Nomulus domain registry project.
---
You received this message because you are subscribed to the Google Groups "nomulus-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomulus-discuss/CACG0o06u7St-FpyrODctYQTbxLqgCJsRuMfjeUngkDTyrj0ktw%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to nomulus-discuss+unsubscribe@googlegroups.com.
Hans Ridder
Dec 12, 2016, 4:54:06 PM12/12/16
to nomulus-discuss, mcil...@google.com, bfke...@gmail.com
It seems odd to me that the AE Java runtime doesn't provide a SecureRandom named "NativePRNG" (it would seem easy enough to do). My understanding is that the only reason to specify "NativePRNG" is guarantee avoiding using SHA1PRNG, which will only be used if the Java runtime doesn't provide a "native" PRNG. Perhaps some odd Java runtimes do this but I'm not aware that any do.
And in case this discussion veers in the direction of using "blocking entropy sources" for increased security (e.g. /dev/random), such concerns can generally be safely ignored. :-)
-h
And in case this discussion veers in the direction of using "blocking entropy sources" for increased security (e.g. /dev/random), such concerns can generally be safely ignored. :-)
-h
To unsubscribe from this group and stop receiving emails from it, send an email to nomulus-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomulus-discuss/51ade742-4be2-4760-b5a4-9a4ca6b663f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
NOTE: This is a public discussion list for the Nomulus domain registry project.
---
You received this message because you are subscribed to the Google Groups "nomulus-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nomulus-discu...@googlegroups.com.
Nick Felt
Dec 12, 2016, 5:19:42 PM12/12/16
to Hans Ridder, nomulus-discuss, mcil...@google.com, bfke...@gmail.com
It's not so much that the AE Java runtime philosophically objects to providing the NativePRNG SecureRandom, it's just that they rolled out a new runtime sandboxing strategy that accidentally broke access to /dev/urandom and /dev/random, which broke NativePRNG. This happened to our apps several months ago, and they supposedly fixed the issue - so we're following up internally to see why you're getting broken by this again.
FWIW, for several of the usages in our codebase, we don't really need cryptographically secure random numbers at all, and should probably just be using Random.
For the cases where we do need cryptographically secure random numbers, I'm definitely not an expert but I think NativePRNG is somewhat preferred over SHA1PRNG, and I think within Google we may do some special-casing of NativePRNG.
Re: blocking entropy, yes, I've read articles similar to the one you linked to and we don't have any intention of trying to block on low entropy. AFAIK, NativePRNG by default (via the Sun provides) uses /dev/random for generating a seed, and then /dev/urandom afterwards. I think this is the generally recommended approach, since it ensures that you have sufficient entropy to seed the PRNG at startup but then doesn't block on low entropy during actual usage. See also:
https://tersesystems.com/2015/12/17/the-right-way-to-use-securerandom/
https://tersesystems.com/2015/12/17/the-right-way-to-use-securerandom/
To view this discussion on the web visit https://groups.google.com/d/msgid/nomulus-discuss/ea627ee7-7737-4474-b29c-3aae67593ef8%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages