On Jun 24, 2016, at 3:35 PM, Dan S <danc...@rebelbase.com> wrote: > less headache static linking to SSLEAY32 and LIBEAY32 :), depending on how > many windows versions you want to support, static linking to WS2_32 and > CRYP32 may also be useful (though linking all 4 nearly tripled the binary for > what we needed to have included), but don't have to worry about what version > or SP is on the target machine and not bother with redistributables that may > otherwise be needed on some installations... Also, lib dependencies in > manifests may be treated differently between platforms and I am not sure if > dependencies can be separated by the platform (for example 7 will accept abs > paths, vista will expect paths to be relative to the location of the manifest > file (embedded or near the .exe) and XP wants them relative to the exe > (placing the dlls, the manifest and the exe in the same could avoid that, > however lunching from different user accounts may again be a headache (ex. > SUBSTed or hard linked paths on current user may differ from those of the run > as user as in launching an app from SUBSTed (at login) path, for example, > will fail to find the DLLs in current folder on vista and xp if you run as > administrator that never had the startup script SUBST any drives) > > > On Thu, Jun 23, 2016 at 12:50 PM, Russ Loucks <r...@mnmicro.net> wrote: > > On Jun 23, 2016, at 1:44 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > >> On 23/06/2016 18:25, Russ Loucks wrote: >>> We have an application running on Windows 8.1 (HP) tablets that is mostly >>> statically linked except for a few libraries, including the SSLEAY32 and >>> LIBEAY32 libraries. >>> >>> We're using version 1.0.2 of the OpenSSL libraries. >>> >>> We ship our executable and these two libraries and then set a PATH entry in >>> the registry that points to our 'lib' directory so the system/library >>> loader can find the libraries at load/run time. >>> >>> There are two other packages on these tablets we ship that include older >>> versions of the OpenSSL libraries - Intel TXE Components/TCS (OpenSSL >>> version 1.0.0g) and HP Registration service (1.0.0d). >>> >>> Works well. >>> >>> Until the user runs Windows updates.... >>> >>> Then, when our application starts we get a 'The ordinal 3905 could not be >>> located in the dynamic link library 'C:\program Files\<our >>> installdir>\lib\SSALEAY32.dll'. >>> >>> I've tried the following - all to no avail: >>> removing the HP and Intel OpenSSL libraries (but safe-keeping them for >>> later re-installation) >>> Re-installing our application and OpenSSL libraries >>> Interestingly, the OpenSSL libraries in the HP and Intel installations do >>> not change after the Windows update - they're the same versions as before >>> the update.... >>> >>> I'm stumped. Any clues? >>> >>> I'm guessing the best course of action is to statically link the OpenSSL >>> libs into our app. Is that a good plan? >>> >>> Thanks for the help. >>> >>> >> Over the past few years, Microsoft has been phasing in a security >> improvement (and it is an improvement) to protect against remote >> attackers dropping trojanized replacement DLLs in an unsecured >> (document) directory which they have reason to believe will be >> the current directory when the attacked program is loaded. >> This change consists of a change in the default search order >> for DLLs where no explicit directory is passed to LoadLibrary/ >> LoadLibraryEx, and a very similar change to the search order for >> DLLs that are named (with no path obviously) in the import tables >> in programs and other DLLs. >> >> The recommended best practice for DLLs loaded by linking to an >> import library (which contains the needed entries for the import >> table) is to leave OS owned standard DLLs in System32 (SysWoW64 >> for 32 bit programs on Win64), use explicit manifest version >> references in the calling EXE/DLLs linked in manifest (don't trust >> the manifest generator in Visual Studio, it tends to get details >> wrong), and put application specific DLLs (including private >> copies of stuff such as SSLEAY32.DLL) in the same directory as the >> referencing EXE/DLL file. >> >> Playing around with the PATH environment variable when installing >> programs is generally considered worst practice due to the risk of >> affecting other programs by inflicting your own DLLs etc. on them. >> >> As a side effect of all this, having a dedicated lib/dll subdir in >> your install dir will generally not work unless you load all those >> DLLs via your own calls to LoadLibrary/LoadLibraryEx with >> explicitly computed full pathnames, thus such a dir is now only >> good for plugins and other on-demand loaded components. With a >> little tweaking it could also be useful for OpenSSL engine plugin >> DLLs. > > Thanks much for the info. I’ll work on two options - statically linking the > libs and, if that doesn’t work, augmenting our existing app manifest to bind > the app to the DLLs. > > I’ll let you know what I find. > > ----Russ Loucks > mailto: r...@mnmicro.net > Winter is coming > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Got this to work on the HP tablets by statically linking the OpenSSL libraries into our app. Interestingly I have a Toshiba Encore tablet running Windows 8.1 and applied all the upgrades and our app didn’t break like it did on the HP. Oh, well, I like the solution. ---- Russ Loucks mailto: r...@mnmicro.net “Until you teach someone calculus, they can’t even walk finite distances. But they can get reallllllly close.” - Saturday Morning Breakfast Cereal
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
