Hi Job, Thanks very much for your reply. Apologies for the lateness of mine. I will ask around and get more information about Powershell and PDQ Inventory. Thanks again, Steven Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, November 23rd, 2022 at 5:36 AM, Job Cacka <job@xxxxxxxxx> wrote: > Michael's point should be asked and answered first for your environment. > > To find all of the OpenSSL bits used on a windows system you would use > Powershell or a tool that flexes its use like PDQ Inventory. There is a > steep learning curve and it is probably off topic for this group but there > are several different ways to use powershell to gain this information from > different viewpoints (Installed files, registry, event log, etc...). > > Thanks, > Job > > -----Original Message----- > From: openssl-users openssl-users-bounces@xxxxxxxxxxx On Behalf Of Michael > > Wojcik via openssl-users > Sent: Monday, November 21, 2022 4:18 PM > To: openssl-users@xxxxxxxxxxx > Subject: Re: Upgrading OpenSSL on Windows 10 > > > From: openssl-users openssl-users-bounces@xxxxxxxxxxx on behalf of > > Steven_M.irc via openssl-users openssl-users@xxxxxxxxxxx > > Sent: Monday, November 21, 2022 15:56 > > > However, I am running Windows 10, and since (unlike Linux) every piece > > of software outside of Windows itself needs to be updated > > individually, I don't know how to track down every single application that > > might be using OpenSSL and make sure that the copy of OpenSSL it uses is > up-to-date. > > You don't. There may be applications that have OpenSSL linked statically, or > linked into one of its own DLLs, or just with the OpenSSL DLLs renamed. > > > As many of you would know, under repository-based systems (such as > > most Linux distros), this would not be an issue as I could update every > > single application (system or non-system) at once. > > This is not true in the general case. There are applications which are > available on Linux which do not use the distribution's package manager. > There are applications which use their own OpenSSL build, possibly linked > statically or linked into one of their own shared objects or with the > OpenSSL shared objects renamed. Linux distributions have not magically > solved the problem of keeping all software on the system current. > > > Back to Windows: It is possible, with relatively little effort, to find all > the copies of the OpenSSL DLLs under their usual names on a system, and then > glean from them their version information. With significantly more effort, > you can search for exported OpenSSL symbols within third-party binaries, > which will detect some more instances. With quite a lot of additional > effort, you can winkle out binaries which contain significant portions of > code matching some OpenSSL release (see various research efforts on > function-point and code-block matching, and compare with alignment > strategies in other fields, such as genomics). If your definition of > "OpenSSL in an application" is not too ambitious, this might even be > feasible. > > But to what end? Each application will either be well-supported, in which > case you can find out from the vendor what OpenSSL version it contains and > whether an update is available; or it is not, in which you'll be out of > luck. > > This is true of essentially every software component, most of which are not > as well-maintained or monitored as OpenSSL. Modern software development is > mostly a haphazard hodgepodge of accumulating software of uncertain > provenance and little trustworthiness into enormous systems with > unpredictable behavior and failure modes. I'm not sure OpenSSL versions > should be particularly high on anyone's priority list. > > What are you actually trying to accomplish? What's your task? Your threat > model? > > -- > Michael Wojcik
