ティージェーグレェ on Nostr: I submitted a Pull Request to update signify in MacPorts here: ...
I submitted a Pull Request to update signify in MacPorts here:
https://github.com/macports/macports-ports/pull/27046
It's a little confusing because: signify doesn't actually have "releases" as it is part of OpenBSD base; and unlike GoT not part of /usr/ports and there is no -portable distinction (as with OpenSSH and OpenSMTPD, etc.)
The previous MacPorts' signify maintainer, last updated/synced from upstream circa 2018/2019 I think?
That maintainer, hasn't touched anything on GitHub since 2022.
Quote: "Been on hiatus from open source due to draconian corporate intellectual property policies, and not wanting to expose communities I care about to undue legal risk while bound by them." (from: https://github.com/jpouellet)
There are other "forks" (for lack of a better description) of signify elsewhere on GitHub used by Linux distros by the looks of things; but it seemed as if it would be less friction, to fork jpouellet's signify-osx (renaming my branch/fork to signify-macOS since Apple changed the name of their OS yet again); tweak the Makefile slightly to point to an anoncvs mirror that wasn't timing out (yikes!) and run % make fetch to sync from upstream to pick up whatever changes have occurred in the ensuing years.
I did, for the sake of completeness, also submit a PR to jpoullet's branch here:
https://github.com/jpouellet/signify-osx/pull/9
Though, I guess that got auto-closed by GitHub? Presumably because I changed my local branch to default and renamed it from the time I submitted that Pull Request? smdh I hate GitHub.
Anyhoot. Another oddity I encountered, while I tagged a 1.5 "release" in my fork here: https://github.com/artkiver/signify-macOS/releases/tag/1.5
The tarball I grab from that?
signify-macOS-1.5.tar.gz
Has different check sums and file sizes that the tarball which MacPorts fetches which is called:
artkiver-signify-macOS-1.5-0-g3e9082b.tar.gz
And why that is, I have no idea!
Weird GitHub inconsistencies or something. I have encountered something similar in the past (with ZMap I think?), but I haven't the foggiest idea wtfh it happens, so I figured I would just update the check sums and file size in the Portfile to match the artkiver-signify-macOS-1.5-0-g3e9082b.tar.gz tarball MacPorts grabs, rather than the one that is tagged in my branch.
Anyway, I tested it and it still verifies LibreSLL's tarball OK; so yay?
No idea when that will get merged, since the previous maintainer (who hasn't had any activity on GitHub since 2022) probably won't be chiming in, so it will probably go to "maintainer timeout" and I may need to email macports-dev to have the maintainer removed like I had to do with the previous libressl and libressl-devel maintainer? sigh I will cross that bridge when I get to it I guess.
#signify #MacPorts #OpenSource #OpenBSD #CryptographicSignatures #CodeSigning #cryptography #macOS #OSX #Apple
https://github.com/macports/macports-ports/pull/27046
It's a little confusing because: signify doesn't actually have "releases" as it is part of OpenBSD base; and unlike GoT not part of /usr/ports and there is no -portable distinction (as with OpenSSH and OpenSMTPD, etc.)
The previous MacPorts' signify maintainer, last updated/synced from upstream circa 2018/2019 I think?
That maintainer, hasn't touched anything on GitHub since 2022.
Quote: "Been on hiatus from open source due to draconian corporate intellectual property policies, and not wanting to expose communities I care about to undue legal risk while bound by them." (from: https://github.com/jpouellet)
There are other "forks" (for lack of a better description) of signify elsewhere on GitHub used by Linux distros by the looks of things; but it seemed as if it would be less friction, to fork jpouellet's signify-osx (renaming my branch/fork to signify-macOS since Apple changed the name of their OS yet again); tweak the Makefile slightly to point to an anoncvs mirror that wasn't timing out (yikes!) and run % make fetch to sync from upstream to pick up whatever changes have occurred in the ensuing years.
I did, for the sake of completeness, also submit a PR to jpoullet's branch here:
https://github.com/jpouellet/signify-osx/pull/9
Though, I guess that got auto-closed by GitHub? Presumably because I changed my local branch to default and renamed it from the time I submitted that Pull Request? smdh I hate GitHub.
Anyhoot. Another oddity I encountered, while I tagged a 1.5 "release" in my fork here: https://github.com/artkiver/signify-macOS/releases/tag/1.5
The tarball I grab from that?
signify-macOS-1.5.tar.gz
Has different check sums and file sizes that the tarball which MacPorts fetches which is called:
artkiver-signify-macOS-1.5-0-g3e9082b.tar.gz
And why that is, I have no idea!
Weird GitHub inconsistencies or something. I have encountered something similar in the past (with ZMap I think?), but I haven't the foggiest idea wtfh it happens, so I figured I would just update the check sums and file size in the Portfile to match the artkiver-signify-macOS-1.5-0-g3e9082b.tar.gz tarball MacPorts grabs, rather than the one that is tagged in my branch.
Anyway, I tested it and it still verifies LibreSLL's tarball OK; so yay?
No idea when that will get merged, since the previous maintainer (who hasn't had any activity on GitHub since 2022) probably won't be chiming in, so it will probably go to "maintainer timeout" and I may need to email macports-dev to have the maintainer removed like I had to do with the previous libressl and libressl-devel maintainer? sigh I will cross that bridge when I get to it I guess.
#signify #MacPorts #OpenSource #OpenBSD #CryptographicSignatures #CodeSigning #cryptography #macOS #OSX #Apple