[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
Thank you very much for the DLL and this very interesting discussion. SQLite passes the the certification test with this version. I don't have my hands on an XP box, to test if this version runs there, but I can ship a different version for XP if that is the tall to pay. Notice that SQLite is not the only dll with problems, many libraries like Cairo graphics and pacparser for instance do not comply yet. But then like any industry, security is something we have to deal with. Best regards and thanks again. Maarten MOSTERT 28 Av Alphonse Denis 83400 Hy?res, France +33 676411296 [ http://stakepoint.com/ ]( http://stakepoint.com/ ) > "Random Coder" | > On Thu, Apr 2, 2015 at 10:58 AM, wrote: > > > > This are basically compiler switches as far as I understand. > > > > I am not a C programmer, so also quite difficult for me to link the library > statically. > > These tests basically map to the /SAFESEH, /DYNAMICBASE, and /NXCOMPAT > linker flags. Though, as I understand it, passing these tests is > recommended, and not required for Windows 8 certification. > > I have a dump of a build of sqlite from a recent internal build. I'm > not connected with the Sqlite project, I just use it, and happen to > turn on these flags in my build environment for other reasons. > > https://bucket-1f8c9d86.s3.amazonaws.com/sqlite3.zip > > You can either use my DLL, or build your own version of the DLL with > these options enabled. > > I'd recommend the SQLite team turn them on for the version of the DLL > they distribute, but I'm honestly not sure if there are negative side > effects to doing so. > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
> -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf > Sent: vrijdag 3 april 2015 01:51 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - > NXCheck - DBCheck > > > BTW, I have verified that these options all work as described and the options > are recognized and processed properly by Windows, and that BinScope is > happy: > > Failed checks > d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL ) > > Passed checks > d:\source\sqlite\sqlite3.dll - NXCheck ( PASS ) This makes all the allocated memory and stack not-executable > d:\source\sqlite\sqlite3.dll - DBCheck ( PASS ) > (Note, position independent code (PIC) is by definition loadable at any base. > Microsoft is just several decades behind in generating position independent > code.) And this makes it possible to load the DLL above 2 GB, which by default isn't enabled because too much existing legacy code still casts pointers to integers and back.. Another opt-in flag in the header, to allow existing programs to still work on bigger machines. SafeSEH is a similar flag for Structured Exception Handling. Without this flag the stack is unwound on exceptions by using debugger tricks and information stored on the stack itself. When this flag is set the compiler promises to provide all this information in a parsable format somewhere in the binary. This improves performance and reliability on these exceptions. But as far as I know Sqlite doesn't use structured exception handling at all. Perhaps MingW supports a flag of just telling that, if it doesn't support creating these tables. (In Windows x86_64 these tables are always required, so this flag doesn't apply there) Windows 8.1 and Windows 10 will add another feature like this where all callback function pointers are stored in a central table for verification if a passed callback function is really to the intended code. (As far as I know this is currently only supported by internal and pre-release versions of the MSVC compiler) Bert
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
I hate correcting myself. You do not need the --export-all-symbols Using it will cause all non-static symbols to be exported (even without a specific dllexport) just like using -shared on unices. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-Original Message- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf >Sent: Thursday, 2 April, 2015 17:51 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > > >BTW, I have verified that these options all work as described and the >options are recognized and processed properly by Windows, and that >BinScope is happy: > >Failed checks >d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL ) > >Passed checks >d:\source\sqlite\sqlite3.dll - NXCheck ( PASS ) >d:\source\sqlite\sqlite3.dll - DBCheck ( PASS ) > >(Note, position independent code (PIC) is by definition loadable at any >base. Microsoft is just several decades behind in generating position >independent code.) > >--- >Theory is when you know everything but nothing works. Practice is when >everything works but no one knows why. Sometimes theory and practice are >combined: nothing works and no one knows why. > > >>-Original Message- >>From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >>bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf >>Sent: Thursday, 2 April, 2015 17:43 >>To: General Discussion of SQLite Database >>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >>NXCheck - DBCheck >> >> >>add the following linker options with MinGW: >> >>-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all- >symbols >> >>You may or may not need -static-libgcc or the linker -Bstatic options >>unless you are also enabling things that require MingW DLL runtime >>support (such as using the -mthreads option to make the DLL thread >>exception safe). >> >>-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware >> >>Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the >>linker (so you can add them to the shell tool and other pre-built >>executables as well). Files also need to export the symbol table (hence >>the --export-all-symbols). --large-address-aware sets the (you guessed >>it) large address aware flag which basically means that you are using >>unsigned pointers and not signed pointers (that is, you understand that >>neither disk space nor memory comes in negative sizes) and don't diddle >>with your pointers (eg, assigning magical meaning to bits in the >>pointer). This allows use of more than 2GB of virtual address space per >>process on systems that support it (ie, 32-bit userland on a 64-bit >>Windows -- on 64-bit Windows windows does not co-habitate with 32-bit >>processes, instead a wee trampoline is installed in the top 100MB or so >>of the virtual space to thunk back and forth to the OS -- making it >>impossible to insert code into the OS from a 32-bit process, while 64- >bit >>processes on 64 >> -bit windows have full and complete access to the OS as it resides in >>each processes address space) or if the /3GB boot option is set on 32- >bit >>OSes (so the OS is forced to shoehorn into the top 1GB of each process). >> >>The only thing this does not fix is the Exception Handlers. But that >>particular protection is not implemented by gcc (not needed because of >>non-ill-conceived design?). However, you might still want to add - >>mthreads and the static linking options to the build so that the GCC >>threadsafe exception handlers are used. >> >>--- >>Theory is when you know everything but nothing works. Practice is when >>everything works but no one knows why. Sometimes theory and practice >are >>combined: nothing works and no one knows why. >> >>>-Original Message- >>>From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite- >users- >>>bounces at mailinglists.sqlite.org] On Behalf Of Richard Hipp >>>Sent: Thursday, 2 April, 2015 14:25 >>>To: General Discussion of SQLite Database >>>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck >- >>>NXCheck - DBCheck >>> >>>On 4/2/15, Random Coder wrote: >>>> >>>> I'd recommend the
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
This are basically compiler switches as far as I understand. I am not a C programmer, so also quite difficult for me to link the library statically. This is what I can read about it here: [ https://msdn.microsoft.com/en-us/library/windows/apps/jj657973.aspx#binscope_2 ]( https://msdn.microsoft.com/en-us/library/windows/apps/jj657973.aspx#binscope_2 ) /SafeSEH Exception Handling Protection Windows App Certification Kit error message: SafeSEHCheck Test failed An exception handler runs when the app encounters an exceptional condition, such as a divide-by-zero error. Because the address of the exception handler is stored on the stack when a function is called, it could be vulnerable to a buffer overflow attacker if some malicious software were to overwrite the stack. What to do if your app fails this test Enable the /SAFESEH option in the linker command when you build your app. This option is on by default in the Release configurations of Visual Studio. Verify this option is enabled in the build instructions for all executable modules in your app. Remarks The test is not performed on 64-bit binaries or ARM chipset binaries because they don't store exception handler addresses on the stack. Data Execution Prevention Windows App Certification Kit error message: NXCheck Test failed This test verifies that an app doesn't run code that is stored in a data segment. What to do if your app fails this test Enable the /NXCOMPAT option in the linker command when you build your app. This option is on by default in linker versions that support Data Execution Prevention (DEP). Remarks We recommend that you test your apps on a DEP-capable CPU and fix any failures you find that result from DEP. Address Space Layout Randomization Windows App Certification Kit error message: DBCheck Test failed Address Space Layout Randomization (ASLR) loads executable images into unpredictable locations in memory, which makes it harder for malicious software that expects a program to be loaded at a certain virtual address to operate predictably. Your app and all components that your app uses must support ASLR. What to do if your app fails this test Enable the /DYNAMICBASE option in the linker command when you build your app. Verify that all modules that your app uses also use this linker option. Remarks Normally, ASLR doesn't affect performance. But in some scenarios there is a slight performance improvement on 32-bit systems. It is possible that performance could degrade in a highly congested system that have many images loaded in many different memory locations. This test is performed on only apps written in managed code, such as by using C# or .NET Framework. Best regards, Maarten MOSTERT, > "Richard Hipp" | > On 4/2/15, maarten.mostert at stakepoint.com > wrote: > > > > WARNING > > Binary analyzer > > Warning: The binary analyzer test detected the following errors: > > File C:\Program Files\StakePoint\sqlite3.dll has failed the NXCheck check. > > File C:\Program Files\StakePoint\sqlite3.dll has failed the DBCheck check. > > File C:\Program Files\StakePoint\sqlite3.dll has failed the SafeSEHCheck > > check. > > > > I have no idea what the above means. > > Can you work around it by statically linking SQLite into your > application, rather than using a separate DLL? > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
Please find here under the test results. Best regards, Maarten MOSTERT 28 Av Alphonse Denis 83400 Hy?res, France +33 676411296 [ http://stakepoint.com/ ]( http://stakepoint.com/ ) == Windows App Certification Kit - Test Results Windows App Certification Kit - Test Results App name:StakePoint ?Technical-Preview? App publisher:Maarten MOSTERT App version:15.03.0019 OS Version:Microsoft Windows 8.1 (6.3.9600.0) Kit Version:3.4 Report time:31/03/2015 15:03:53 Overall result: PASSED WITH WARNINGS It is highly recommended that you investigate and root cause warnings to ensure that users of your app aren?t negatively impacted. Windows security features test WARNING Binary analyzer Warning: The binary analyzer test detected the following errors: File C:\Program Files\StakePoint\sqlite3.dll has failed the NXCheck check. File C:\Program Files\StakePoint\sqlite3.dll has failed the DBCheck check. File C:\Program Files\StakePoint\sqlite3.dll has failed the SafeSEHCheck check. Impact if not fixed: If the app doesn?t use the available Windows protections, it can increase the vulnerability of the customer's computer to malware. How to fix: Apply the SAFESEH, DYNAMICBASE, and NXCOMPAT options when you link the app. See link below for more information: [ Fixing Binary Analyzer Errors ]( http://go.microsoft.com/fwlink/?LinkId=247433 ) > "Richard Hipp" | > On 4/2/15, maarten.mostert at stakepoint.com > wrote: > > > > Hi Everyone, > > > > I am new here, and have a question. > > > > For my application that relies on Sqlite I am seeking Windows 8 > > certification in accordance with the following article. > > > > [ https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ]( > > https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ) > > > > To verify its compliance I run the installer against The Windows > > Certification KIT 3.4. > > > > This indicates that the SQLite dll I use fails the above mentioned test. > > The links you provide mention dozens of different tests. Which ones > are failing? > > > > > > Is there any SQLite binary out there that complies with the security mesures > > MS imposes for desktop app certification. > > > > Best regards, > > > > Maarten MOSTERT > > > > > > > > 28 Av Alphonse Denis > > 83400 Hy?res, France > > +33 676411296 > > [ http://stakepoint.com/ ]( http://stakepoint.com/ ) > > > > ___ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
HI, If I may... On Thu, Apr 2, 2015 at 4:25 PM, Richard Hipp wrote: > On 4/2/15, Random Coder wrote: >> >> I'd recommend the SQLite team turn them on for the version of the DLL >> they distribute, but I'm honestly not sure if there are negative side >> effects to doing so. > > That's not possible, unfortunately, We compile the published DLL > (the 32-bit DLL at least) with MinGW so that they will work on older > versions of Windows. If we used a recent MSVC then the resulting DLL > will not work on WinXP, I am told. That's not true. Recent version of MSVC has the option which allows it to build the binary that will be compatible with the older version of Windows. And this is for MSVC 2012/13. MSVC 2010 still able to build WinXP binary just fine. Unfortunately I don't have the reference at hand. Sorry. > > If the published DLL is not to your liking, it is simple to make your > own. I suggest you do so. You can start with the amalgamated source > code file "sqlite3.c". All you need is to compile that one file into > a DLL that the security checker approves of. How hard can that be? Or even better - include this file in the project solution and build the binary as statically linked with all required options. That's what statical linking means. > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
BTW, I have verified that these options all work as described and the options are recognized and processed properly by Windows, and that BinScope is happy: Failed checks d:\source\sqlite\sqlite3.dll - SafeSEHCheck ( FAIL ) Passed checks d:\source\sqlite\sqlite3.dll - NXCheck ( PASS ) d:\source\sqlite\sqlite3.dll - DBCheck ( PASS ) (Note, position independent code (PIC) is by definition loadable at any base. Microsoft is just several decades behind in generating position independent code.) --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-Original Message- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Keith Medcalf >Sent: Thursday, 2 April, 2015 17:43 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > > >add the following linker options with MinGW: > >-static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols > >You may or may not need -static-libgcc or the linker -Bstatic options >unless you are also enabling things that require MingW DLL runtime >support (such as using the -mthreads option to make the DLL thread >exception safe). > >-Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware > >Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the >linker (so you can add them to the shell tool and other pre-built >executables as well). Files also need to export the symbol table (hence >the --export-all-symbols). --large-address-aware sets the (you guessed >it) large address aware flag which basically means that you are using >unsigned pointers and not signed pointers (that is, you understand that >neither disk space nor memory comes in negative sizes) and don't diddle >with your pointers (eg, assigning magical meaning to bits in the >pointer). This allows use of more than 2GB of virtual address space per >process on systems that support it (ie, 32-bit userland on a 64-bit >Windows -- on 64-bit Windows windows does not co-habitate with 32-bit >processes, instead a wee trampoline is installed in the top 100MB or so >of the virtual space to thunk back and forth to the OS -- making it >impossible to insert code into the OS from a 32-bit process, while 64-bit >processes on 64 > -bit windows have full and complete access to the OS as it resides in >each processes address space) or if the /3GB boot option is set on 32-bit >OSes (so the OS is forced to shoehorn into the top 1GB of each process). > >The only thing this does not fix is the Exception Handlers. But that >particular protection is not implemented by gcc (not needed because of >non-ill-conceived design?). However, you might still want to add - >mthreads and the static linking options to the build so that the GCC >threadsafe exception handlers are used. > >--- >Theory is when you know everything but nothing works. Practice is when >everything works but no one knows why. Sometimes theory and practice are >combined: nothing works and no one knows why. > >>-Original Message- >>From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >>bounces at mailinglists.sqlite.org] On Behalf Of Richard Hipp >>Sent: Thursday, 2 April, 2015 14:25 >>To: General Discussion of SQLite Database >>Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >>NXCheck - DBCheck >> >>On 4/2/15, Random Coder wrote: >>> >>> I'd recommend the SQLite team turn them on for the version of the DLL >>> they distribute, but I'm honestly not sure if there are negative side >>> effects to doing so. >> >>That's not possible, unfortunately, We compile the published DLL >>(the 32-bit DLL at least) with MinGW so that they will work on older >>versions of Windows. If we used a recent MSVC then the resulting DLL >>will not work on WinXP, I am told. >> >>If the published DLL is not to your liking, it is simple to make your >>own. I suggest you do so. You can start with the amalgamated source >>code file "sqlite3.c". All you need is to compile that one file into >>a DLL that the security checker approves of. How hard can that be? >> >>-- >>D. Richard Hipp >>drh at sqlite.org >>___ >>sqlite-users mailing list >>sqlite-users at mailinglists.sqlite.org >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > >___ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
add the following linker options with MinGW: -static-libgcc -Wl,-Bstatic,--nxcompat,--dynamicbase,--export-all-symbols You may or may not need -static-libgcc or the linker -Bstatic options unless you are also enabling things that require MingW DLL runtime support (such as using the -mthreads option to make the DLL thread exception safe). -Wl,--nxcompat,--dynamicbase,--export-all-symbols,--large-address-aware Sets the NXCOMPAT and DYNAMICBASE (ASLR) flags on the output of the linker (so you can add them to the shell tool and other pre-built executables as well). Files also need to export the symbol table (hence the --export-all-symbols). --large-address-aware sets the (you guessed it) large address aware flag which basically means that you are using unsigned pointers and not signed pointers (that is, you understand that neither disk space nor memory comes in negative sizes) and don't diddle with your pointers (eg, assigning magical meaning to bits in the pointer). This allows use of more than 2GB of virtual address space per process on systems that support it (ie, 32-bit userland on a 64-bit Windows -- on 64-bit Windows windows does not co-habitate with 32-bit processes, instead a wee trampoline is installed in the top 100MB or so of the virtual space to thunk back and forth to the OS -- making it impossible to insert code into the OS from a 32-bit process, while 64-bit processes on 64-bit windows have full and complete access to the OS as it resides in each processes address space) or if the /3GB boot option is set on 32-bit OSes (so the OS is forced to shoehorn into the top 1GB of each process). The only thing this does not fix is the Exception Handlers. But that particular protection is not implemented by gcc (not needed because of non-ill-conceived design?). However, you might still want to add -mthreads and the static linking options to the build so that the GCC threadsafe exception handlers are used. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-Original Message- >From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- >bounces at mailinglists.sqlite.org] On Behalf Of Richard Hipp >Sent: Thursday, 2 April, 2015 14:25 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Windows 8.x security requirements / SafeSEHCheck - >NXCheck - DBCheck > >On 4/2/15, Random Coder wrote: >> >> I'd recommend the SQLite team turn them on for the version of the DLL >> they distribute, but I'm honestly not sure if there are negative side >> effects to doing so. > >That's not possible, unfortunately, We compile the published DLL >(the 32-bit DLL at least) with MinGW so that they will work on older >versions of Windows. If we used a recent MSVC then the resulting DLL >will not work on WinXP, I am told. > >If the published DLL is not to your liking, it is simple to make your >own. I suggest you do so. You can start with the amalgamated source >code file "sqlite3.c". All you need is to compile that one file into >a DLL that the security checker approves of. How hard can that be? > >-- >D. Richard Hipp >drh at sqlite.org >___ >sqlite-users mailing list >sqlite-users at mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
Hi Everyone, I am new here, and have a question. For my application that relies on Sqlite I am seeking Windows 8 certification in accordance with the following article. [ https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ]( https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ) To verify its compliance I run the installer against The Windows Certification KIT 3.4. This indicates that the SQLite dll I use fails the above mentioned test. Is there any SQLite binary out there that complies with the security mesures MS imposes for desktop app certification. Best regards, Maarten MOSTERT 28 Av Alphonse Denis 83400 Hy?res, France +33 676411296 [ http://stakepoint.com/ ]( http://stakepoint.com/ )
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
On 4/2/15, Random Coder wrote: > > I'd recommend the SQLite team turn them on for the version of the DLL > they distribute, but I'm honestly not sure if there are negative side > effects to doing so. That's not possible, unfortunately, We compile the published DLL (the 32-bit DLL at least) with MinGW so that they will work on older versions of Windows. If we used a recent MSVC then the resulting DLL will not work on WinXP, I am told. If the published DLL is not to your liking, it is simple to make your own. I suggest you do so. You can start with the amalgamated source code file "sqlite3.c". All you need is to compile that one file into a DLL that the security checker approves of. How hard can that be? -- D. Richard Hipp drh at sqlite.org
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
On 4/2/15, maarten.mostert at stakepoint.com wrote: > > WARNING > Binary analyzer > Warning: The binary analyzer test detected the following errors: > File C:\Program Files\StakePoint\sqlite3.dll has failed the NXCheck check. > File C:\Program Files\StakePoint\sqlite3.dll has failed the DBCheck check. > File C:\Program Files\StakePoint\sqlite3.dll has failed the SafeSEHCheck > check. > I have no idea what the above means. Can you work around it by statically linking SQLite into your application, rather than using a separate DLL? -- D. Richard Hipp drh at sqlite.org
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
On Thu, Apr 2, 2015 at 10:58 AM, wrote: > > This are basically compiler switches as far as I understand. > > I am not a C programmer, so also quite difficult for me to link the library > statically. These tests basically map to the /SAFESEH, /DYNAMICBASE, and /NXCOMPAT linker flags. Though, as I understand it, passing these tests is recommended, and not required for Windows 8 certification. I have a dump of a build of sqlite from a recent internal build. I'm not connected with the Sqlite project, I just use it, and happen to turn on these flags in my build environment for other reasons. https://bucket-1f8c9d86.s3.amazonaws.com/sqlite3.zip You can either use my DLL, or build your own version of the DLL with these options enabled. I'd recommend the SQLite team turn them on for the version of the DLL they distribute, but I'm honestly not sure if there are negative side effects to doing so.
[sqlite] Windows 8.x security requirements / SafeSEHCheck - NXCheck - DBCheck
On 4/2/15, maarten.mostert at stakepoint.com wrote: > > Hi Everyone, > > I am new here, and have a question. > > For my application that relies on Sqlite I am seeking Windows 8 > certification in accordance with the following article. > > [ https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ]( > https://msdn.microsoft.com/en-us/windows/desktop/hh749939.aspx ) > > To verify its compliance I run the installer against The Windows > Certification KIT 3.4. > > This indicates that the SQLite dll I use fails the above mentioned test. The links you provide mention dozens of different tests. Which ones are failing? > > Is there any SQLite binary out there that complies with the security mesures > MS imposes for desktop app certification. > > Best regards, > > Maarten MOSTERT > > > > 28 Av Alphonse Denis > 83400 Hy?res, France > +33 676411296 > [ http://stakepoint.com/ ]( http://stakepoint.com/ ) > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp drh at sqlite.org