'Static' 64-bit OpenSSL 3.0.9 & the current Ca-certs from Debian 'Bookworm'...

[mikewalsh]

Evening, gang.

Following a discussion earlier about running-as-root, and various other mitigations required for secure Puppy operation, I decided to do a wee bit of research.

Two things that were mentioned were the need to maintain an up-to-date OpenSSL install, along with up-to-date CA certificates. A plan began to hatch...

OpenSSL requires correspondingly up-to-date versions of libcrypto and libssl. Now, from my own past experience with these, I know for a fact that the repos of older Pups, in particular, will only ever produce the last version made available for them.......which in many cases, is hopelessly out-of-date, and long out of support. This in turn means that you can't use bang up to date CA certs, since newer releases will be expecting newer builds of libcrypto/libssl. Sometimes you can get away with a re-named sym-link, but not often. Anyways.....

Recent experience with John van Sickle's statically-compiled builds of ffmpeg has shown me the value of this type of build, since everything required by the binary is included internally at build time. These can be dropped into Pups of any age - back to at least a certain point, anyway - and still give modern capabilities in a distro that often was built before these newer capabilities were even thought of.

Which is pretty neat. Anybody see where this is heading?

----------------------------------------------

I found my way to the OpenSSL main website. Now, most mentions of OpenSSL around these parts have usually been to do with 1.1.1, the outgoing LTS release. However, it turns out that the last build of this, 1.1.1u, runs out of support in a matter of weeks. As y'all know, I usually don't worry too much about using older apps & software.....except where internet-facing stuff is concerned. Here, I am pretty strict about keeping stuff up to date.

The newest build is 3.2, but the current LTS build, v 3.0.9, is supported until April 2026.....at least another 2 1/2 years. I did some more digging, and found this site:-

https://freecoder.dev/compile-openssl-from-source/

....that gives quite comprehensive build instructions for compiling OpenSSL from the source code. AND......instructions for how to do a 'static' compile. Which for someone with my miserable compiling skills, was pretty useful, sooo....

-----------------------------------

Series 3 OpenSSL also needs libcrypto3, along with libssl3. Some more digging revealed that my test install of jrb's Jammypup64 comes with these pre-installed. So, I loaded up the Devx and kernel-sources SFSs, and set in motion a static compile of OpenSSL 3.0.9. Fingers crossed, I hit 'Enter', annnd.....blow me down if it wasn't successful. Nice one!

I searched through the Debian package listings to find the most up-to-date CA certificates in the 'Bookworm' Miscellaneous section. Accordingly, here's a 64-bit package that combines this static build of OpenSSL along with the very newest up-to-date CA certs.

I've already been running this for several hours in my recent custom Tahrpup64 install. Absolutely no 'side-effects' of any kind; it seems to be running as sweet as a nut, so far.

If anybody wants to take advantage of this 'drop-in' upgrade, y'all can find the .pet here:-

https://www.mediafire.com/folder/efcie6 ... ts+upgrade

Navigate through, and help yourselves. Use at your own risk, obviously.

The Tahr64 trial is taking place in a 'duplicate' install ATM, but I've noticed no adverse behaviour as yet. I've just installed this in Xenialpup64 on the 'new' Dell Latitude lappie, and again, it's giving zero issues.

(I guess I could do a 32-bit one, too, but I'm not at all certain what, if any, 'current' 32-bitzers have the required newer builds of libcrypto & libssl...)

We'll see.

It's nowt special, but it'll help to secure at least a part of your Puppies. Hope it's useful!

Mike.

[rockedge]

@mikewalsh I remember sharing info on the ffmpeg static builds from what is now some years ago, when I was using the static ffmpeg builds for compiling Zoneminder in Tahr6.0.5 and Bionic32/64 because they used avconv and did not have actual ffmpeg onboard. Still use those static builds from John van Sickle on occasion. If I remember correctly we could drop in the static ffmpeg all the way down to Lucid 5.2.8 and UPUP Raring 3.9.9.2

It would be a big plus if we could use a statically built OpenSSL for certain builds for testing!

[mikewalsh]

@rockedge

@mikewalsh I remember sharing info on the ffmpeg static builds from what is now some years ago, when I was using the static ffmpeg builds for compiling Zoneminder in Tahr6.0.5 and Bionic32/64 because they used avconv and did not have actual ffmpeg onboard. Still use those static builds from John van Sickle on occasion. If I remember correctly we could drop in the static ffmpeg all the way down to Lucid 5.2.8 and UPUP Raring 3.9.9.2

It would be a big plus if we could use a statically built OpenSSL for certain builds for testing!

Well, here ya go, Erik. This will give you the current 3-series LTS release in static format, along with the newest CA-certs I could find. Here's hoping it'll prove to be useful!

Mike.

[ozsouth]

Well done, Mike! I usually do Curl too - compile is fairly simple. You'd be amazed at how many things use it. One does openssl first (as you have), then configures Curl --with-openssl

[mikewalsh]

Well done, Mike! I usually do Curl too - compile is fairly simple. You'd be amazed at how many things use it. One does openssl first (as you have), then configures Curl --with-openssl

@ozsouth :-

Steady on, Dave. Don't push me TOO hard!

Compiling has never been my strong suit; I usually only get anywhere near success if I have a 'recipe' to follow.....and then it needs to be nice & clear. Still, I guess it's like everything; "practice makes perfect", and the more ya do it, the easier it gets....

From experience with JvS's static ffmpeg builds, I knew this was a good way to do things.....and since OpenSSL primarily depends on libcrypto/libssl, I figured combining these together into a use-anywhere 'static' would prove to be a good way of getting up-to-date cryptographic support into some of my older Pups. Seeing as how it's working so well, I figured I'd share.

-------------------------------------

I was thinking of including the 'new' firewall_ng script that Dima modified last year to add IPv6 support, but testing it out introduced a few odd quirks I wasn't happy with.......and anyway, like you I, too, found that

Code: Select all

ip a

....returned no mention of IPv6. I believe I looked at this last time I had to go into the router's control panel, and from what I recall it's disabled there anyway, so I'll just stick with what I'm using, I think. In all honesty, until Dima mentioned it I'd never taken much notice of it; I've always used IPv4 - which works fine for me - and shall probably continue in that vein.

Mike.

[mikewalsh]

@ozsouth :-

You might be interested in these, mate:-

Fully 'static' builds of Curl

Not sure about the latest one - 8.2.1 - but the previous one, 8.2.0, is linked against the same version of OpenSSL I've just created the static build of...

Shall be trialling this, too!

EDIT:- Just used it to download Chrome from the URL in my updater script. Works flawlessly! It's a 'keeper'....

Looks like I may have found myself another 'ongoing' project.....trying 'static' builds of other stuff. Sheesh....

Mike.

[ozsouth]

@mikewalsh - you're on a roll! BTW if you want to know your actual ip, in a terminal run: curl ifconfig.me

[mikewalsh]

@ozsouth :-

Ah. Thanks for the tip. I'll take a look at that....

Mike.

[dimkr]

If it's a static library, you'll need to start recompiling applications that use OpenSSL against this static library, otherwise they won't use it.

(And you'll need to repeat everything when you update to 3.0.10)

[ozsouth]

@dimkr - which is why I normally compile in the puppy I'm going to use. Mike is experimenting.

[mikewalsh]

If it's a static library, you'll need to start recompiling applications that use OpenSSL against this static library, otherwise they won't use it.

(And you'll need to repeat everything when you update to 3.0.10)

@dimkr :-

Heh. See, you're automatically assuming that I'm going to keep updating it, aren't you? As Oz says, I'm playing around & experimenting ATM.....although I do hear the advice, and it IS appreciated. Point taken, despite that I don't even know where I'm going with this yet; by & large, this is alien territory for me..!

Obviously, it makes more sense to build stuff in the location where it will be used.....but if you're going to do that, there would never be a need for 'static' versions of anything, would there? Your dependencies would always be on hand, so it would make more sense to use them.

Do I take it, then, that whenever anything is compiled to use other stuff, that there is ALWAYS a link to an exact, specified version? (This stuff is probably old-hat to you, but for me we're still very much at the 'baby-steps' stage!)

One is NEVER too old to learn. Hell, life itself IS a continuous learning process.....

I'm afraid I've never been one for dotting every last 'i', and crossing every single 't'. Life's too short for all that. I sometimes have a job remembering who I am when I wake up in t' mornings.......and I'm definitely a 'bumbler' when it comes to putting software together. I've never pretended otherwise.

I've found a way of doing things that works for me. It may work for others.....it may not. No harm in offering it.

For me, Puppy has only ever been a hobby, but I do try to contribute wherever possible. (*shrug...*)

Mike.

[dimkr]

Do I take it, then, that whenever anything is compiled to use other stuff, that there is ALWAYS a link to an exact, specified version?

Every application linked against a shared (= not static) openssl will use the shared library and you'll be able to update the library without recompiling the application only if the two versions are compatible with each other (so can't update from 1.1.x to 3.0.y).

When you build a static library, you can't replace the shared library with it, because shared libraries and static libraries are not the same thing. To use the static library you built, you'll need to rebuild applications against it. However, a static library becomes part of the applications and it's not a separate file you can replace later (like a shared library), so you'll need to rebuild the applications each time you want to update this static library.

(If you use an old distro that ships 1.1.x, you'll need to update all applications to newer versions that support openssl 3.0.x, so updating openssl like this can't be a small and easy change)

[mikewalsh]

@dimkr :-

Well, thanks for the explanation, Dima. I certainly wouldn't argue the point. You definitely know more about this stuff than I ever shall, having been at it for quite some time from what I can see.......and you certainly appear to know what you're talking about. That's the whole point of fora like ours, after all; community members share knowledge, and help each other out with stuff they either can't figure out or don't understand.

Damn..!

I thought I'd found a workaround for this issue, but it seems - from what you've said - that it's actually a double-edged sword at the end of the day. Still, I won't give up on it completely; primarily I want it for browsers, which I always keep very much up-to-date anyway. Internet-facing software is the one area where even I am strict about keeping on top of things, and I would think most browsers/email clients, etc, will be supporting the most up-to-date versions of this by now.

Appreciated, mate. It'll give me summat to chew on for a bit.....

Mike.

[mikewalsh]

In response to the above-voiced concerns, I've put together a couple of 'older' static builds.....these utilising the final 2 older LTS builds of OpenSSL; v1.1.1t, and v1.1.1u. These were compiled in Fossapup64-9.5, which is a bit of an 'odd duck'; it comes with libssl3, but the corresponding libcrypto3 is missing.......so it wouldn't have supported the new LTS series unless this was provided.

The CA-certs part of the package is still the same one from Bookworm; the 'requirements' section states that it wants v1.1.1 OR newer. So, it should still function OK.

Y'all can find these two at the same, above-mentioned link in post #1.

Mike.