signify: update to 1.5; synced from upstream Dec 12th 2024, jpouellet last synced from upstream in 2019?

[artkiver]

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 15.2 24C101 arm64
Command Line Tools 16.2.0.0.1.1733547573

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@jpouellet for port signify.

[neverpanic]

I guess that means we should also update our bundled copy in base?
Were there significant changes upstream?

[artkiver]

I guess that means we should also update our bundled copy in base? Were there significant changes upstream?

Ah, I didn't realize MacPorts dependent on signify more deeply. Maybe?

I don't think the changes over the intervening years have been too significant.

e.g. https://cvsweb.openbsd.org/src/usr.bin/signify/

Shows that a lot in that directory is unchanged for years.

signify.c has only had a handful of changes in the last five years:

https://cvsweb.openbsd.org/src/usr.bin/signify/signify.c

zsig.c removed a spurious error 19 months ago:

https://cvsweb.openbsd.org/src/usr.bin/signify/zsig.c

And signify.c and zsig.c were both modified 4 years 11 months ago to change how they handle base64:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.c.diff?r1=1.133&r2=1.134&f=h
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/zsig.c.diff?r1=1.17&r2=1.18&f=h

The manpage saw the most changes:

https://cvsweb.openbsd.org/src/usr.bin/signify/signify.1

Has a lot of OpenBSD related release version bumping commit messages, and some changes to examples (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.1.diff?r1=1.58&r2=1.59&f=h) fw_update which is OpenBSD specific (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.1.diff?r1=1.53&r2=1.54&f=h) a change to how -C and -t flags interoperate (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.1.diff?r1=1.48&r2=1.49&f=h) a sysupgrade related change also specific to OpenBSD (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.1.diff?r1=1.46&r2=1.47&f=h) a wording change (https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.1.diff?r1=1.45&r2=1.46&f=h)

One of the manpage changes corresponds to changes in signify.c such as the -C and -t flags: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/signify/signify.c.diff?r1=1.134&r2=1.135&f=h

But overall? It doesn't seem as if anything major has transpired as far as I know?

I mostly stumbled across this while noticing that the version of signify tracked by repology.org seemed substantially different from other distros and was trying to figure out where they were getting their version numbers from and then noticed that @jpouellet has been inactive for years.

For reference the repology.org link: https://repology.org/project/signify-openbsd/versions most of which actually seems to be tracking downstream from https://github.com/aperezdc/signify/tags

Skimming those for completeness, many of the aperezdc tagged release Notes are impertinent to MacPorts and on occasion highlight some of the changes mentioned earlier in this reply.

Of one potential concern are the Notes for that branch's v24 but that seems as if it is a difference in libc choices (they're presumably relying on glibc?) so again I don't think that is something MacPorts needs to worry about.

Even if it were from upstream, the last release jpouellet tagged is from December, 2018 some months after that September 2018 v24 branch was tagged.

TL;DR I don't think this Pull Request has any big deal changes? It was more done to "scratch an itch" as seemed as if it was maybe still a good idea to try to keep things in a slightly more maintained state and in closer sync to upstream.