sysutils/msktutil: Update to 1.2.2

[michaelo]

Summary

Approved by: jrm (mentor), otis (mentor)

[jrm]

lgtm assuming all the necessary poudriere runs pass and @pi has no objections.

[michaelo]

In D46643#1063059, @jrm wrote:

lgtm assuming all the necessary poudriere runs pass and @pi has no objections.

Builds for me just fine with Heimdal and MIT Kerberos.

[michaelo]

Will wait for the maintainer timeout.

[diizzy]

Any reason as to why we're not using upstream release archive?
https://github.com/msktutil/msktutil/releases/download/1.2.2/msktutil-1.2.2.tar.bz2
That will also likely get rid of USES= autoreconf

Other notes:
Remove GNU_CONFIGURE_MANPREFIX

sysutils/msktutil/Makefile

2

PORTVERSION --> DISTVERSION :-)

[michaelo]

In D46643#1063864, @diizzy wrote:

Any reason as to why we're not using upstream release archive?
https://github.com/msktutil/msktutil/releases/download/1.2.2/msktutil-1.2.2.tar.bz2
That will also likely get rid of USES= autoreconf

Other notes:
Remove GNU_CONFIGURE_MANPREFIX

Well, although I am the upstream maintainer, I am not the port maintainer. I wanted to change as little as possible. GNU_CONFIGURE_MANPREFIX was actually added explicitly.
I can provide these changes in a separate PR.

[diizzy]

Hi,

GNU_CONFIGURE_MANPREFIX isn't needed as of https://cgit.freebsd.org/ports/commit/?id=9fd7ee1cdf6cbd5528159b58a966e1a40e2909a9

Best regards,
Daniel

[michaelo]

Incorporate @diizzy's comments

Note: I will handle the autoconf stuff separately, I guess it is there for historic reasons.

[jrm]

In D46643#1063864, @diizzy wrote:

Any reason as to why we're not using upstream release archive?
https://github.com/msktutil/msktutil/releases/download/1.2.2/msktutil-1.2.2.tar.bz2

There is a good reason to prefer auto-generated archives. As the xz fiasco demonstrated, manually generated archives may not precisely match the code. For instance, as you note, authors of projects that use autotools may generate the configure script so users don't need autotools installed. While this simplifies installation, it also creates an opportunity for bad actors to insert malicious code that is less straightforward to audit. GitHub's automatic tarballs, generated with git archive, should be an accurate reflection of the code. Given the risk, we should reconsider this warning in the Porter's Handbook.

[diizzy]

Autogenerated archives changes over time which will break any kind of checksum verification and aren't necessarily reproducable so that doesn't add much if any value. Not to forget that there were also source commits in the repo which neither tarball generation solution would've convered. We already spend "excessive amounts" of cpu cycles on running Autotools as it is and adding autoreconf etc (which may also barf) doesn't help the cause if it can be avoided. Additionally we don't have the manpower to keep up with thousounds of packages that breaks randomly.

[jrm]

In D46643#1064092, @diizzy wrote:

Autogenerated archives changes over time which will break any kind of checksum verification and aren't necessarily reproducable so that doesn't add much if any value.

They do, but GitHub has now guaranteed they won't randomly change for no good reason for at least a year, so the situation is better than it used to be.

Not to forget that there were also source commits in the repo which neither tarball generation solution would've convered. We already spend "excessive amounts" of cpu cycles on running Autotools as it is and adding autoreconf etc (which may also barf) doesn't help the cause if it can be avoided. Additionally we don't have the manpower to keep up with thousounds of packages that breaks randomly.

You asked if there were *any* reasons to use the manually generated archive. I guess it comes down to picking your poison. Do we want to deal with changing hashes over time and the "excessive amounts" of CPU cycles required to generate configure scripts, or do we want to (in an ideal world) unpack all the manually generated archives to confirm nothing malicious has snuck in that's not observable in the repository? There are reasonable points for both approaches.

[michaelo]

Guys, can we focus on the actual change. I agree with @jrm, that is makes little sense to waste cycles for ./configure. I will provide this change with a separate PR.
There is only one way to make sure that an artifact ist authentic either X.509 or GPG.

[diizzy]

Friendly reminder that you need a PR in bugzilla for maintainer timeout to apply.

[michaelo]

In D46643#1064388, @diizzy wrote:

Friendly reminder that you need a PR in bugzilla for maintainer timeout to apply.

Thanks for the pointer. Completely forgot about it. Will do.

[michaelo]

Weird, the maintainer picked up PR, but totally ignored this review....closing.