1

I want to compile new versions of openssl, bash, and similar unix tools in the same way that Apple would. I want to link against the OS's built-in libraries where possible, and I want to copy the resulting binaries into /usr/bin, replacing what Apple ships with OS X.

I am aware that this is usually a terrible idea, for two reasons:

  1. An OS X update might reinstate Apple's binaries, undoing your work and leaving your system in an unknown state.
  2. Some software may depend on the specific behavior of Apple's binaries.

Instead, it is generally recommended that mac users install custom binaries alongside Apple's system binaries. Both homebrew and MacPorts operate under this principle.

However, I'm running Mavericks, which will never receive another software update from Apple. The Apple binaries on my system have known security vulnerabilities, which IMO outweighs theoretical compatibility concerns.

Is there a standard way to go about this, or would it be different for every program? Can I somehow leverage parts of e.g. the MacPorts project to make the process easier, or do I need to install all compilation dependencies from scratch?

If this just isn't realistically feasible, I'd like to know that too.

Improve this question
12
  • 1
    @Seamus I just read the thread - I think you're just coming from two opposites view points, so something that sounds "trivial" for him might look very different for you, and vice versa. From reading it, it sounds like you're used to how software versions work in for example Windows - here we're using to upgrading to new versions number (i.e. version 5 is better than 4 is better than 3 etc.). So when something happens, like a security issue, you upgrade from version 4 to version 5. However, that's not how versioning usually works on Unix systems - so if [...]
    – jksoegaard
    Commented Feb 26, 2020 at 23:09
  • 1
    [...] he comes from a Unix or server background, that world view will seem very foreign. Instead on Unixoid systems you're very used to seing version 3, version 4 and version 5 as essentially being different programs offering different features. Here it is customary to NOT upgrade from version 4 to version 5 when something like an security issue comes up. Instead a new build version of version 4 is made that includes a small change that solves the relevant issue. This means that manuals, user experience, existing integrations, etc. all keeps working like before - it is essentially a [...]
    – jksoegaard
    Commented Feb 26, 2020 at 23:11
  • 1
    [...] non-breaking change. You're not getting new features, but you are getting a new version of the software. So for example the bash version includes in macOS might still read 3.2, but it is definitely not the same 3.2 version that's in the latest Catalina as is in Mavericks in this case for example. The two programs are different in that the Catalina version is a 2020-version of bash 3.2 that contains various changes and fixes that are not in the 2016 (or older) Mavericks version. If you're mainly concerned about maintaining compatibility and "not rocking the boat", this is the optimal way.
    – jksoegaard
    Commented Feb 26, 2020 at 23:13
  • 1
    Ofcourse if you're looking for new features, you will be sorely disappointed by this method. In that case, you would be better off installing bash 5 (for example) in /usr/local/bin, so that you can use it yourself for your own uses, while keeping the 3.2 version for system supplied scripts, etc.
    – jksoegaard
    Commented Feb 26, 2020 at 23:13
  • 1
    @Seamus Sure, almost every type of Unix system out there does maintaining of "old" versions. Just to take a random example of software that many would be familiar with. PHP is a well known web programming language that had a very popular 5.6 series, which went out of support from the vendor back in 2018. At that point they had been supporting it for 4 years, so it was really an "old version" at that point. However, Debian still includes PHP 5.6 in some of their still supported releases - so they are themselves creating new versions of PHP 5.6 to fix various issues - as a matter of fact [...]
    – jksoegaard
    Commented Feb 26, 2020 at 23:57

1 Answer 1

Reset to default
2

You will need to individually check and build every program, although the process for most programs is fairly similar.

You might be able to take some inspiration from MacPorts/Homebrew in their recipes, but I doubt that you can use them 1:1 as they typically feature versions that differ greatly from the Apple supplied utilities. For example by offering GNU versions of supplied BSD utilities, or by offering something that is a completely different major version.

As an example of this, I saw that you received a comment on your question recommending you to install "openssl" for example. This can be quite tricky, as if you install "openssl", you actually get something substantially different than what Apple actually supplies with macOS today. If you run the command "openssl" on a modern Mac, you'll actually be running something called LibreSSL. You'll have to make an individual choice for each and every software package such as this to determine if you want to go with Apple's choice (LibreSSL), or a new major version of OpenSSL.

I think the most feasible route is to go to Apple's open source web site:

https://opensource.apple.com

Here'll you find the source for the utilities that came with your 10.9 system. Using that list, I would go through the sources for 10.15 and find the same programs.

This will often give you security patched versions of the same major version or at least very similar programs to the ones that came with your 10.9 system. If you're lucky, they compile without problems. In some cases, you'll run into stuff that is only supported on newer operating systems, and then you'll have to work around it by modifying the program, or going back to an older version.

All in all, it is going to be a lot of work!

Improve this answer
7
  • 1
    This was actually the point - i.e. to get the same major versions. If you upgraded bash to 5.0, you would expect all sorts of weird stuff and things not working anymore. It would not be drop-in compatible. By keeping bash at 3.2, you would get something which is highly likely to be drop-in compatible, but with security fixes.
    – jksoegaard
    Commented Feb 26, 2020 at 23:02
  • 1
    Whether or not you consider the changes substantial is a matter of your opinion. When I diff the two versions of bash 3.2 (build 92 and 118) there's 1334 lines of difference. The change notes mentions at least two CVE's fixed (i.e. security vulnerabilities).
    – jksoegaard
    Commented Feb 26, 2020 at 23:03
  • 1
    Sure, Apple is making lots of changes to these utilities. You'll find many commands that has options that only exist on macOS, or does stuff that is only possible on macOS (for example in using macOS specific OS services). An easy way to diff a full program like that is to download and unpack each version into their own folder. So you'll have a "bash_old" and "bash_new" folder for example. Then run this command in the terminal: "diff -r bash_old bash_new"
    – jksoegaard
    Commented Feb 27, 2020 at 0:05
  • 1
    What makes the opensource.apple.com route difficult is they're all xcode projects without standard makefiles. And I can't open those new xcode projects in Mavericks's older xcode. I think I'm better off going with the upstream BSD utilities...
    – Wowfunhappy
    Commented Feb 27, 2020 at 0:06
  • 1
    Perhaps it's easier to copy over a newer version of xcodebuild? Or simply cross compile them, if you have access to a newer Mac (or perhaps run such a newer macOS version in a virtual machine). Going with the upstream BSD utilities will require you to more close compare the Apple version with the upstream version to see what you're missing out on. Some of it might be vital.
    – jksoegaard
    Commented Feb 27, 2020 at 0:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .