|
When you load a FIPS DLL, the DLL must first do some integrity checking to make sure it hasn't been tampered with. Basically the DLL calculates some sort of checksum on its own memory space and ensures that the result is what it expects. I don't remember the details, but something about the way that 32-bit DLLs are loaded by 64-bit Windows caused the DLL to get that memory check wrong, and so it always thinks the DLL has been modified and refuses to load. This is OpenSSL FIPS-validated code (not ours) and so we are not allowed to change it. Thank you. Have we considered creating a 64-Bit FIPS DLL?
(08 Aug '19, 10:28)
J Diaz
Replies hidden
What do mean by that? AFAIK, there should be a 64-bit FIPS DLL in your install when you have the according license, see here...
(08 Aug '19, 10:34)
Volker Barth
OK sorry your right I'm working to many things at once.
(08 Aug '19, 10:44)
J Diaz
Replies hidden
1
I'd suggest a vacation at the beach, but that can be perilous too...
(08 Aug '19, 16:16)
Breck Carter
|
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 07 Aug '19, 18:33
question was seen: 895 times
last updated: 09 Aug '19, 11:44
That's not fully correct according to the v17 What's new docs, they state (under the "Strong encryption now achieved using OpenSSL" topic):
Well, I don't know why it is that way - but why wouldn't you want to run a 64-bit database server on 64-bit Windows?
Didn't want to ignore this question. We use some older 32-Bit external libraries and continue to have issues with these working in the external environment under a 64-Bit instance of SQL Anywhere so we are forced to revert to a 32-Bit instance. Version is 16 latest EBF.
Hm, running 32-bit external libraries with a 32-bit external C environment under a 64-bit database server has worked well for us so far... Have you tried to solve those issues via questions here?
No but I will it's an interesting issue. I'll start a new item once I get the data straight