VAST Seaside problem at startup

I have recently installed 8.6 as a clean install. I have loaded the Seaside feature and run up my code that was working under earlier versions of 8. When I try to log into the main Seaside control web page I get the following come up.

<a href="https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png" style="margin-left:1em;margin-right:1em" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png&#39;;return true;" onclick="this.href=&#39;https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png&#39;;return true;">

I know nothing about the Seaside internals. Can anyone tell me how to get this sorted please?

I have recently installed 8.6 as a clean install. I have loaded the Seaside feature and run up my code that was working under earlier versions of 8. When I try to log into the main Seaside control web page I get the following come up.

<a href="https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png" style="margin-left:1em;margin-right:1em" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png&#39;;return true;" onclick="this.href=&#39;https://lh3.googleusercontent.com/-gSnYAgcGCfw/VzOI9DXMZ6I/AAAAAAAAADE/mECWkXP8Es0BG48gPZPFKSvcTAwV6JWggCLcB/s1600/Screen%2BShot%2B2016-05-11%2Bat%2B20.30.56.png&#39;;return true;">

I know nothing about the Seaside internals. Can anyone tell me how to get this sorted please?

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hello,

I can reproduce this.

Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.

Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger

^super keyOfLength: anInteger

-- Seth

On Thursday, May 12, 2016 at 9:57:46 AM UTC-4, Totally Objects wrote:

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hello all,

I believe I described how to "work around" the issue in my previous post and this is adequate for playing around with Seaside in the absence of OpenSSL.
However, I would NOT recommend this solution in any sort of deployment or usage as an internet web server for http (and obviously https).

EsRandom is not, and was never really intended to be, a secure RNG which means that reverse engineering its algorithm, by folks with the skills in this area, would probably not be too terribly difficult.

-- Seth

On Thursday, May 12, 2016 at 11:08:16 AM UTC-4, Seth Berman wrote:

Hello,

I can reproduce this.

Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.

Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger

^super keyOfLength: anInteger

-- Seth

On Thursday, May 12, 2016 at 9:57:46 AM UTC-4, Totally Objects wrote:

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hello,

I can reproduce this.

Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.

Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger

^super keyOfLength: anInteger

-- Seth

On Thursday, May 12, 2016 at 9:57:46 AM UTC-4, Totally Objects wrote:

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Just to let you know. This is still in 9.0. Wast it supposed to be fixed? Or should were going down the route described by John?

David

On Thursday, May 12, 2016 at 4:08:16 PM UTC+1, Seth Berman wrote:

Hello,

I can reproduce this.

Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.

Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger

^super keyOfLength: anInteger

-- Seth

On Thursday, May 12, 2016 at 9:57:46 AM UTC-4, Totally Objects wrote:

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hello David,

The preferred route is the one that John described.

-- Seth 

On Wednesday, October 11, 2017 at 3:26:10 PM UTC-4, Totally Objects wrote:

Just to let you know. This is still in 9.0. Wast it supposed to be fixed? Or should were going down the route described by John?

David

On Thursday, May 12, 2016 at 4:08:16 PM UTC+1, Seth Berman wrote:

Hello,

I can reproduce this.

Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.

Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger

^super keyOfLength: anInteger

-- Seth

On Thursday, May 12, 2016 at 9:57:46 AM UTC-4, Totally Objects wrote:

Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at <a href="http://localhost:8080" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Flocalhost%3A8080\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHe-wK21qitFTuLNvLF8GFyaOoS3w&#39;;return true;">http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

On Thursday, May 12, 2016 at 1:35:37 PM UTC+1, Louis LaBrunda wrote:

Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

On Thursday, May 12, 2016 at 7:34:26 AM UTC-4, Totally Objects wrote:

I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

On Wednesday, May 11, 2016 at 11:16:34 PM UTC+1, Seth Berman wrote:

Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Hi David,

Great, glad to hear.  Yes, for OpenSSL binaries <= 1.0.2, they retained the ‘32’ at the end.  Even many of the build flags for compiling the project still have 32 in them even though it’s a 64-bit compile.  In >= 1.1.0, they changed the names, so it’s libcrypto and libssl instead of libeay32 and ssleay32.
Our bindings are compatible with 1.0.x and 1.1.0, so we left the abt ini reference alone.
Once the last of the 1.0.x branch (1.0.2) goes out of support end of year 2019, the ini file will be changed.

- Seth