Adjust MacOS instructions LibreSSL -> OpenSSL

[depatchedmode]

From Brook's clean install experience:

openssl ecparam -genkey -name secp256k1 -outform DER -out secp256k1_key.der

This line from the docs succeeded, but I get this:

Failed to start runtime: failed to generate/import keypair for libp2p
Caused by:
    failed to parse DER encoded secp256k1 key: Error {
        kind: TagUnexpected {
            expected: Some(
                Tag(0x30: SEQUENCE),
            ),
            actual: Tag(0x06: OBJECT IDENTIFIER),
        },
        position: None,
    }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

$ openssl version
LibreSSL 3.3.6

Oh right, Apple uses LibreSSL

$ nix shell nixpkgs#openssl
$ openssl version
OpenSSL 3.0.12 24 Oct 2023 (Library: OpenSSL 3.0.12 24 Oct 2023)
$ openssl ecparam -genkey -name secp256k1 -outform DER -out secp256k1_key.der
$ homestar start -c ./settings.toml
ts=2024-01-30T21:42:58.413678Z level=info target=homestar message="starting with settings

Success

[depatchedmode]

How does someone address this w/o nix?

[zeeshanlakhani]

@depatchedmode so it's not about Nix. Homebrew's OpenSSL install works as well. The issue is that the default OSX OpenSSL is LibreSSL, so not OpenSSL, the latter of which is more predominant outside of OSD default installs. We could try to add some special handling of OSX in Homestar and see which variant of OpenSSL is installed, but that would involve some special-casing code, and we don't control or know how/where people generated their keys. So, that's always the difficulty too, as it may not be from the OpenSSL installed in your path.

Otherwise, with LibreSSL, this is a known issue.

TBH, All of this becomes not needed when our key init functionality within Homestar comes into place, which is being worked on right now by @QuinnWilton.

[depatchedmode]

@zeeshanlakhani So, it sounds like we just want to make sure people have OpenSSL on their machine, and then provide generic instructions to get that setup. Given that it will be obsolesced by WIP, for now I'll just at that tip to the docs "Please make sure you have OpenSSL installed. By default MacOS ships with LibreSSL, which will cause errors."

[zeeshanlakhani]

@depatchedmode is probably worth linking options to install via Homebrew, etc.

[bmann]

Yeah, I think this gets replaced with doing this with CLI and/or Homestar. So if we want to turn this into a feature, it's something like "Generate a local key with Homestar", and from discord chat, I guess @QuinnWilton is working on this feature. Yay!

[botovq]

openssl ecparam -genkey -name secp256k1 -outform DER -out secp256k1_key.der

You could add -noout. Then the instructions should work with both LibreSSL and OpenSSL:

openssl ecparam -genkey -name secp256k1 -outform DER -out secp256k1_key.der -noout

[botovq]

LibreSSL documents the flag as -noout Do not output the encoded version of the parameters.

The issue is that the output is the concatenation of the EC Parameters (only an object identifier since secp256k1 is a built-in curve) and the key. This is a long-standing bug for which OpenSSL added a workaround that introduces inconsistency between PEM and DER output.

Giving -noout short-circuits this code:

https://github.com/openbsd/src/blob/660f4b3c4ebfb5ad23635ac212012bb9d9260b3e/usr.bin/openssl/ecparam.c#L521

I inspected the keys output with -noout using LibreSSL 3.8.2, OpenSSL 3.2.1, OpenSSL 3.1.5, and OpenSSL 1.1.1w and they all look sensible. This doesn't cover LibreSSL 3.3.6 in question, but ecparam didn't change all that much over the years.

[zeeshanlakhani]

LibreSSL documents the flag as -noout Do not output the encoded version of the parameters.

The issue is that the output is the concatenation of the EC Parameters (only an object identifier since secp256k1 is a built-in curve) and the key. This is a long-standing bug for which OpenSSL added a workaround that introduces inconsistency between PEM and DER output.

Giving -noout short-circuits this code:

https://github.com/openbsd/src/blob/660f4b3c4ebfb5ad23635ac212012bb9d9260b3e/usr.bin/openssl/ecparam.c#L521

I inspected the keys output with -noout using LibreSSL 3.8.2, OpenSSL 3.2.1, OpenSSL 3.1.5, and OpenSSL 1.1.1w and they all look sensible. This doesn't cover LibreSSL 3.3.6 in question, but ecparam didn't change all that much over the years.

yeah, I remember coming across this bug/issue, though I couldn't find it again (with the workarounds).

[zeeshanlakhani]

Yeah, I used the homebrewed openssl, but we can test this cc @depatchedmode @expede.