|don bright 3c77b63c3f||2 years ago|
|src||2 years ago|
|LICENSE||2 years ago|
|LICENSE.autoconf||2 years ago|
|LICENSE.automake||2 years ago|
|LICENSE.curl||2 years ago|
|LICENSE.git||2 years ago|
|LICENSE.libtool||2 years ago|
|LICENSE.mozilla.pems||2 years ago|
|LICENSE.openssl||2 years ago|
|LICENSE.pkg-config||2 years ago|
|README.md||2 years ago|
|buildy.sh||2 years ago|
lm, short for Liony McLionface, allows you to bootstrap curl and git on an old Mac running OSX 10.7.5 Lion, so that you can use curl and git again without getting weird SSL errors.
curl -k https://bootstrap.pypa.io/get-pip.py -o get-pip.py curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version git clone https://github.com/donbright/font_to_svg Cloning into 'font_to_svg'... fatal: unable to access 'https://github.com/donbright/font_to_svg/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Go to Apple menu, 'update software' until you are at 10.7.5
Install Xcode 4.3, the last version for Lion from developer.apple.com
Search for 'Xcode command line tools' on Apple's website. download+install. (Note, this doesn't work from inside of XCode itself anymore)
Get Chrome for Lion, then go to https://try.gitea.io/donbright/lm
Hit the 'download' link, arrow at the upper right of page, for tar.gz version
Open a terminal in OSX, and type this:
tar xf ~/Downloads/lm-master.tar.gz export PATH=$HOME/lm/bin:$PATH # put that export line in your ~/.profile for now... you can remove if u need later) cd lm ./buildy.sh
wait about 30 minutes
exit terminal, start new terminal
now test if it worked:
curl --version # this should now say openssl 1.0...
otool -L $HOME/lm/bin/curl # curl should link to crypto libs under $HOME/lm
git --version # this should be nice and new ish
try to git and clone stuff.
No. If you want security stop using OSX 10.7. This is a nice, warm fuzzy face of security on top of your broken, insecure old operating system that no longer gets updates from it's manufacturer.
What it actually is meant for is so that you can still download stuff from the internet using the command line.
However. It does come with a set of SSL certificates copied from Mozilla in 2018, under $HOME/lm/ssl . After the script builds, it downloads new certificates (see below for how curl deals with certificates)
No. Everything in here is under $HOME/lm and stays there. All libs, all bins, all certs, nothing else is modified or changed in any fashion whatsoever.
This is an extremely minimal, bare bootstrap of curl, and git, and little else, specifically targeted at OSX 10.7.5. This in theory should prevent 'bit rot' and random incompatabilities, just in case brew or macports doesnt work for some reason.
src Source code is under 'src' directory. versions have been chosen to balance age with compatability with Xcode's version of gcc and libs on OSX 10.7.5. There are many, many things that change between versions of programs and libraries that break the builds.
pkg-config -> needed for curl to find openssl properly
it installs a binary under bin/pkg-config and data under prefix/lib/pkgconfig the PKG_CONFIG_PATH tells config scripts where to find the data
autoconf, automake, libtool -> needed by openssl
openssl -> needed for curl to talk to modern internet sites, using https
we build version 1.0.x because it works with older build tools, newer actually lacks a certain thing that slightly old curl is looking for.
curl -> we depend on pkgconfig to tell it how to build with openssl.
curl also is what git uses to fetch https
git -> we depend on it using libcurl for https access, git is special.
git is not a binary, it is a collection of binaries. when you run git clone https://blah.org/proj/toolx it is not using 'git', it is using 'git-http-fetch', and that program is not even under 'bin/' along side git, it might be in /usr/libexec/gitcode/git-http-fetch so if you are analyzing libraries, you need to analyze that one, not just 'git'
dynamic libraries , shared libraries, mach-o, rpaths, etc
since git and curl both need to use ssl libraries, it becomes important to understand how libraries work on OSX. and first, we shall point out that both git and curl do not 'like' to be linked statically, which would avoid these problems. git and curl 'like' to be linked dynamically, but they both have issues finding and remembering where the ssl library we want to use is located.
this tells you where the system's dynamic linker looks when it tries to run your program. otool -L curl will hopefully point to prefix/lib/libssl.dylib
otool -L git wont tell you much, remember, because git is a wrapper for all the 'real' binaries, like prefix/libexec/git-core/git-http-fetch, so otool -L prefix/libexec/git-core/git-http-fetch is what will tell us which version of libcurl and in turn libssl it is linking with.
this is an environment variable we could set to force git and friends to search for curl libraries in the proper place. however it can be a problem remembering to set the variable and its nice to just be able to 'use the binary' without having to worry about the environment variable. for example if you run 'sudo programname' it will actually be run in a different enviornment, cause you are basically changeing yourself to super-user, root, to run the program. so. its an isue. a fix can be accomplished with some special tools:
this is similar slightly to 'patchelf' on Nix linux, https://nixos.org but linux typically uses ELF and OSX uses 'mach-o' format for binaries. two different things. heres a nice intro to macho:
yes you can use curl without certificates, using '-k', but lets at least try to do things semi properly. now, be advised the whole OS is insecure by definition since it no longer receives updates, but lets not be totally sloppy. if only to cut down on warnings and errors.
in order for curl and git to use SSL properly they need to know which sites are considered 'trusted'. in standard web browsers or OS installations this is built into the software or the OS. since we are dealing with an outdated OS that will never be updated, we are using raw certs of our own, downloaded from curl's website, which are originally taken from Mozilla's set of certificates that it ships with the Firefox browser.
the cert is a file under src/mozilla-ssl-certs and we split it, and install it into PREFIX/ssl/certs which is where OpenSSL likes to store things. but curl still cant find them until you 1. run c_rehash from open ssl, and 2. pass the special argument to curl at build time telling it the path to find certificates.
now even after we do that, we still have outdated certificates, which came with this program. we want new ones, so we download them, using the perl script that comes with curl itself, under src/lib/
why are there tar files inside the src path?
some packages were created in a manner that they can only built from inside of their own source tree. in other words, they dont have 'out of tree builds'. to simplify various thought processes, the way buildy deals with these folks is to tar up the original source contents, put the tar ball into the 'build' directory, untar them there into 'build', so that a 'clean' copy of src is always kept. why tar? tar is an extremely portable version of 'copy everything under a directory'
buildy.sh buildy mcbuildface builds the source into binaries to run
build this dir is created during build. all the stuff gets built here
lm/ - prefix, where under lives our little tools, under bin/ lib/ usr/ lm/buildy.sh - build script lm/src - source code for various packages downloaded from the net lm/src/mozcerts-yyyy.mm.dd - some simple ssl certificates to start with lm/build - temporary build directory (build out-of-tree from source) lm/bin - 'bin' where specially built progrms, curl, git, etc, live lm/lib lm/usr etc - miniature filesystem within our little tools world