This page is a wiki. Please login or create an account to begin editing.


26 posts / 0 new
Last post
Maximum R.I.S.C.'s picture
Joined: 2017 Oct 18
CALL TO ARMS! - any Tiger/Leopard Devs Here? Let's Fix OpenSSL in Tiger!!!

Uncle Steve Wants You! ;0p

But seriously, I've been maintaining a few apps for several years (like PPC Media Center - http://ppcluddite.blogspot.com/2016/06/new-ppc-media-center-version-6.html) and am currently working on a GUI for the WAY-COOL PianoPPC port of PianoBar Pandora client (that can actually run in a G3!! - http://desktopecho.com/pianoppc/)

But on every front we are hitting a wall with this TLS/OpenSSL-pocolypse hitting our old systems.
There IS a newer version that will install in Tiger (v1.0.2 - http://sevan.mit.edu/packages) but it has issues. It will report back, but then not really do anything more than that - despite having apparently full library support, curl, wget and whatever other backend internet protocols just can't use it.

Is there anyone on the Garden with a reasonable current Dev system and/or better understanding of backend network systems in Tiger and Leopard?

Am currently Patching PPC Media Center, but it is only a bandaid - as long as video servers like youtube will talk to insecure clients. TenFourFox has it's own solution, but it lives within the browser and can't really help the system.

The next thing to go will likely be network time support, and once that happens, unless TenFourFox finds a new rout, that will mean internet security certificates will start failing and then even with it's superior TLS will not be able to operate.

Much like the 2038/2040 date problem in OSX/OS9, this is a potential system-breaker for any real-world usage.

Won't be easy but for anyone interested in helping out this might well give your systems years more life.

Anyone interested in helping us fix this please email me avalbrec (@) gmail (DOT) com.

Thanks!!

Comments

nil0bject's picture
Offline
Joined: 2012 Nov 14

have you tried contacting those who are also(in a the past) working on it?
http://openssl.6102.n7.nabble.com/Building-OpenSSL-and-OpenSSH-on-Mac-OS...
https://curl.haxx.se/mail/lib-2017-02/0035.html

is openssl necessary. could you try something like libressl?

melomac's picture
Offline
Joined: 2018 Feb 26

I don't have Mac OS X 10.4 at hand but, what if you build from source one of the latest legacy build of the same openssl version:
https://github.com/openssl/openssl/releases/tag/OpenSSL_0_9_8zh
https://github.com/openssl/openssl/releases/tag/OpenSSL_0_9_7m
https://github.com/openssl/openssl/releases/tag/OpenSSL_0_9_6m

Don't forget to enable the shared library and try to use /usr as a prefix.

This may overwrite Apple's OpenSSL (libssl.dylib and libcrypto.dylib) or you could also:
- update the sym links in /usr/lib to point to new build
or:
- update faulty binaries linked libraries using install_name_tool

This is highly theoretical, but that should do.

Maximum R.I.S.C.'s picture
Joined: 2017 Oct 18

Thanks so much Guys - that is exactly the type of info I was hoping for. Also, Sevan (the gentleman who compliled the OpenSSL 1.0.2) has agreed to discuss possibly working with me on this.

Wish us all luck.

Maximum R.I.S.C.'s picture
Joined: 2017 Oct 18

UPDATE: So Sevan (@ sevan.mit.edu) thinks one of the things are up against is python. We are now testing a new setup (fortunately would run from existing packages and setup can be automated), that would create new replacements for:

• OpenSSL
• Python (3.4 if possible, otherwise 2.7)
AND most importantly • NTP (network Time Protocol).

He suspects we will be able to use existing frameworks from that point, if we can get apps that need the enhanced TLS to use these in /usr/pkg instead of the normal versions (can be hand-coded into the apps easily - like PPC Media Center).

The big trick is THIS. Network Time Protocol is critical for everything because it maintains the clock. Even TenFourFox with it's higher-level OpenSSL support is at the mercy of time-sync when validating security-certificates. So a big part of the upgrade will take the shape of making an hourly time-sync package.

If there are ANY applications currently being maintained that require networking (like say PianoPPC) that you'd like to see survive, please get them in touch with me on this so we can come up with a standardized upgrade/patch framework.

This could literally give us another 6 years of largely trouble-free use in Tiger and Leopard, if projects go on being maintained.

Maximum R.I.S.C.'s picture
Joined: 2017 Oct 18

UPDATE:

Well we have a pulse on Python 3.4 and NTP, but OpenSSL, while alive isn't talking to Python yet. THE GOOD NEWS is how many tools are
available in "The Real World" (PC/Mac & LINUX), once we get to this
point.

Debugging today - I suspect the issue is with Curl in OSX.

Here's to getting this fixed soon.

adespoton's picture
Offline
Joined: 2015 Feb 15

Curl should be fine except for the fact that the OpenSSL version it requires doesn't support the most recent versions of TLS. So someone will need to backport.

Once there's a copy of LibSSL that supports the latest TLS, everything else should just be able to use it.

Maximum R.I.S.C.'s picture
Joined: 2017 Oct 18

OpenSSL is updated to 1.0.2 but isn't being used by system curl - will likely have to update it as well.

adespoton's picture
Offline
Joined: 2015 Feb 15

How about curl from http://www.finkproject.org/download/index.php?phpLang=en ?

Philgood's picture
Offline
Joined: 2013 Jun 10

Any update on this ?

donbright's picture
Offline
Joined: 2020 Mar 9

I am not sure how relevant this will be. But, I have built OpenSSL 1.1.0 on OSX 1.5.8 Leopard. I used it to build curl 7.5.6 and git 2.23. It was a bit tricky as it also required building an upgraded version of gcc and some other tools. This has got rid of the TLS problems with curl and git.

New certificates were also downloaded from curls website and put under OpenSSL ssl/certs directory. (curl runs fine using -k but you can get rid of the warnings by downloading new certs)

I have done something similar for 10.7 Lion.

My goal is to eventually build something similar for 10.4 and 10.3, but it takes a long time. I don't have a 10.4 machine at the moment and my 10.3 machine needs more RAM.

rbshep's picture
Offline
Joined: 2020 Mar 5

Wow, you really need to post this somewhere - even if it's not ready for 'prime time' (no install scripts, install notes sketchy, ugly hacks to build ?) the binaries and notes that you have made will doubtless be EXTREMELY useful!

donbright's picture
Offline
Joined: 2020 Mar 9

i was kind of under the impression Tiger Brew and others had already done a bunch of this? (i suspect TenFourFox did something like this to continue operating on https?)

rbshep's picture
Offline
Joined: 2020 Mar 5

The problem with the Tiger Brew versions is that they are not installed to the OSX-style location of somewhere under /Library.

So existing software won't find them to be able to use them. Also, any libraries they themselves refer to won't be pointing to /Library either, rather somewhere in /usr/local IIRC.

Also, if anyone knows of a tool to edit the paths to dylibs within a mach-o executable i'd be most interested Wink

TFF bundles it's own OpenSSL framework - it is in theory possible to copy this out of it's app bundle into the appropriate place in the system, but i haven't tried this, so can't comment on if it works or not!

donbright's picture
Offline
Joined: 2020 Mar 9

Thanks for the information. My system of building openssl 1.1 also has the same problem. Everything in mine is under $HOME/bk. And anything that uses the openssl 1.1.0 under $HOME/bk would have to be rebuilt on top of it from source (which is how I get curl and git to work. like many other open source projects, they allow to specify where to locate the SSL library and headers to build upon).

In my experience it is generally extremely difficult to swap out a system library with a higher version of the library and still have everything work correctly. I know some people have managed it but it's a bit beyond my level of knowledge.

I also seem to have completely fried my Imac G5 on this little adventure. To be honest, it can take 20 or 30 hours to do something like build gcc and the various other tools required, the CPU going at 99% the whole time with the fan at moderately good speed. So basically I have been doing this on and off for several weeks where the machine goes 99% CPU for a whole day or two at a time. (been trying to build up enough tools to build LLVM/Clang) Now today the old G5 is giving me random system crashes and reboot errors where the fan goes to 11. so I may have destroyed something through overworking it.

I actually did clean out the old fan a bit when I swapped in an SSD, but I never replaced the heat sink goo... perhaps I should have... Ah well. Such is life with old machines.

As for modifying libraries in macho execs... are you asking for something beyond what install_name_tool does?

Thanks again

rbshep's picture
Offline
Joined: 2020 Mar 5

I never knew that install_name_tool existed in the first place! So, thank you for the information Wink I don't think I gave you much information at all to be honest! Have you tried using it on your build to change the paths to the libraries it refers to? Or are they OK in the first place?

I did download the latest TFF app bundle to have a peek inside - and i can't see any dylibs with 'ssl' in the name. So i'm confused as to how it works.

That really sucks about your poor G5 Sad

Did you build produce any other object files than openssl, libssl.*.dylib, and libcrypto.*.dylib ? I just looked on Tiger, and it looks like these don't depend on anything other than libSystem... So, it might be possible to drop your versions into /usr/lib/ and /usr/bin/


/usr/bin/openssl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

/usr/lib/libssl.0.9.7.dylib:
/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

/usr/lib/libcrypto.0.9.7.dylib:
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

The hard part will then be looking for any other object on the system that links against these libraries, and re-linking against your versions...but I think this could be done using some bash voodoo and install_name_tool that your mentioned...

As long as your versions contain at least the symbols used in the system versions, and the parameters are passed the same way (otool -Iv ?) i can't personally see why it wouldn't work. But i'm an amateur at all this to be honest!!

Edit : I don't know whether re-linking updates anything else, like exported/imported symbols... but if it doesn't, a quick and dirty hack could be to backup these three files, and copy your versions in under the same names... You could always boot to single-user mode and undo the change that way... maybe try it on a different install to the one you build from though to be safe Wink

donbright's picture
Offline
Joined: 2020 Mar 9

"As long as your versions contain at least the symbols used in the system versions, and the parameters are passed the same way (otool -Iv ?)"

the functions also have to work exactly the same and return the same values in the same situations. it could be an interesting experiment. anyways here is my openssl

tree:bin don$ otool -L openssl
openssl:
/Users/don/bk//lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/Users/don/bk//lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/don/bk/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)

this is already a bit more complicated than i'd like, as its literally using two differenet libgcc

rbshep's picture
Offline
Joined: 2020 Mar 5

I'm guessing from your libSystem version that you're working on Leopard not Tiger?

Where does /usr/lib/libgcc_s.1.dylib come from? Not near a PPC to check right now. But if it's part of the system I shouldn't have thought we would need to worry - and even if not, we could bundle it as a dependency. I'm guessing from your comment this is the latter case. Curious to see the deps on /Users/don/bk//lib/libssl.1.1.dylib and /Users/don/bk//lib/libcrypto.1.1.dylib themselves too.

Would you be able to archive your built tree and post it somewhere? And any notes you have on how you got it to build in the first place? That way others could try to carry this forward.

I'm still mostly QEMU, but will look into diskimage snapshots to make for easy rollback. Though also partly waiting for Ubuntu 20.04 with a much newer QEMU in tow. I will hopefully have a powerbook running soon too.

donbright's picture
Offline
Joined: 2020 Mar 9

so anyways today i realized MacPorts is still around and still works on PowerPC, so you are probably better off just doing that for this type of work.

yes this is 10.5.8. the basic journey was autoconf-2.65 automake-1.12 perl-5.10.1 zlib-1.2.11 openssl-1.1.0 curl-7.56.0. then i used that to build gcc 4.8 something which i then used to build gcc 5.1 which then rebuilds openssl and then builds git. and cmake and xz and tar.

here is the libcrypto links
don@tree:~/src/rustc-1.41.0-src$ otool -L /Users/don/bk//lib/libcrypto.dylib
/Users/don/bk//lib/libcrypto.dylib:
/Users/don/bk//lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/don/bk/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)

libgcc is a library that is generated by gcc and basically every program built by gcc winds up having to link to it. I dont understand it that well but the web searches i did said its really hard to get away from it.

also i found this page by David Fang http://vlsi.cornell.edu/~fang/sw/llvm/ who struggled to get clang working on 10.4 many years ago, http://vlsi.cornell.edu/~fang/sw/llvm/ , apparently extremely difficult.

donbright's picture
Offline
Joined: 2020 Mar 9

so there is more to the story.

basically the LLVM decided a few years ago to remove the Darwin PPC backend as they felt it was too much trouble to maintain and they cut it out.

Someone named Kencu put up a big thread on his attempts to get some version of older LLVM working here

https://trac.macports.org/ticket/53184

then iains has a github with an attempt to makr llvm7 work

https://github.com/iains/LLVM-7-branch

the tricky thing they note is the ABI of gcc 4.2 , which is what Darwin's system libraries are built with, if i understand correctly.

but basically as far as the "modern languages" like Rust and Swift working on 10.5 PPC, its going to take a much more creative approach than simply recompilation of LLVM on a 10.5 machine. same for 10.4 . because modern LLVM (like release 9) literally will now throw an error if you try to do that.

i.e. for example, you might, in theory, create some hybrid translation machine that can take LLVM output from a modern Rust or Swift program, and instead of building assembler or object files, instead transform it into C code, but a version of C that is compatible with gcc-4.2 which is what is on 10.5. (or whatever gcc was on 10.4).

Then you take that and compile it for 10.5 , link against 10.5 system libraries, and you got yourself a program. (plus a few thousand hours of fixing minor details here and there)

i.e. 10.5 winds up being a cross-compilation target for some more modern machine. Much in the way microcontrollers like Arduino do not host programming environments - you program on a modern machine and build for the target, then load the code onto the target.

(this is not actually a terrible problem, it's the way DOOM was built for MSDOS back in the day - it was developed on a NeXT machine IIRC)

OpenSourceMac's picture
Offline
Joined: 2019 Jan 21

I ran into these issues early on and came to the conclusion that the only thing to do is to bundle-in the fixes with whatever app needs them. Compiling on PPC is so time-consuming! Best wishes to everyone, but I'm resigning myself to letting my Mac stay useful where it can and lean on newer hardware for the internet. An 8-core Mac Pro (3,1) can go for as little as $100, so it seems silly to me to push this out of need, but my hat is off to those who are keeping after it out of love for Tiger.

cbone's picture
Offline
Joined: 2011 Sep 17

I feel it's more getting the nostalgic feel of browsing old-school, OSM. I enjoy knowing I can fire up my 68k Mac and go to macostoday.com to read articles, cornica.org to play web videos, system7today.com to download a tool or read old forum posts, and even download apps, documents or media from my own http servers at home and download a few files with iCab or Monica. And this isn't even PPC OS X!

rbshep's picture
Offline
Joined: 2020 Mar 5

I don't have a MacRumours account, but there's someone on there literally wondering what to do with a quad... perhaps we should convince him to allow ssh access? That'd make building a bit quicker Wink

Though could totally understand if they didn't want to

donbright's picture
Offline
Joined: 2020 Mar 9

i think maybe the ideal build platform would not be a quad.

it would either be a big lot of machines, like 10 of them, all running distcc (parallell distributed compilation), or running an emulator on a modern multi-cpu machine, like an AMD Ryzen with 12 cores running an G5 or G4 emulator as something like 10 cores.

adespoton's picture
Offline
Joined: 2015 Feb 15

My current build platform is QEMU-system-PPC. I've got 9.2.2 with MPW and MW CodeWarrior 7 on it, dual booting with OS X 10.4.11 with XCode 2.5 and MW CodeWarrior 10. Then in a VBox VM, I've got 10.6.8 with XCode 4.2 with the PPC and Intel SDKs going back to 10.2.

This combination allows me to compile for pretty much any target from System 6 through OS X 10.6. I haven't bothered much with 10.7 through 10.9 support, but keep the 10.10-10.15 SDKs in my Catalina XCode (not that I use it much).

system's picture
Offline
Joined: 2020 Apr 19

Luckily for you, I got more than 10. I'm rebuilding the cooling system on the (only) two quads. I'd be more than happy to provide access to build some software