pass @1.6.3 update to 1.6.5

[edwin@…]

patch-getopt-path.diff

and

patch-use_apple_mktemp.diff

seem to have become unnecessary

also the post-patch instruction

[john@…]

Thanks for this! I'll take a look shortly.

[john@…]

It looks as though upstream has changed to use a hard-coded prefix of /opt/local for getopt if Macports is installed. That'll work for a default installation, but not if Macports has been relocated to a different directory. patch-getopt-path.diff & the associated post-patch instruction are therefore still necessary, but will need to be updated to work with the new version.

patch-use_apple_mktemp.diff was never required on a vanilla system, but is necessary if the unqualified mktemp invocation gets you the GNU version (say, from /opt/local/libexec/gnubin/mktemp) rather than the Apple provided /usr/bin/mktemp. I've not checked in detail, but from a quick glance that hasn't changed in the new version of pass.

I'll prepare and upload a revised portfile & associated patches shortly. Thanks again for your help!

[john@…]

So in fact upstream has fixed the issues with GNU mktemp (​ages ago it turns out), so the workaround there is no longer necessary.

I'm a little nervous because upstream doesn't use absolute paths for anything, which I naively imagine means it would be easy for something incompatible (or even malicious) to sneak its way onto your $PATH and cause havoc. I think that's a problem for upstream, though, not something I want to address in a Macports-specific way.

[john@…]

I've provided an updated Portfile which reinstates patch-getopt-path. I've also taken the opportunity to introduce a bin dependency on gpg2, thereby addressing #47051 in the process.

Hopefully somebody with commit privileges will take care of this soon. Thanks for your help!

[ryandesign (Ryan Carsten Schmidt)]

Replying to john@…:

I'm a little nervous because upstream doesn't use absolute paths for anything, which I naively imagine means it would be easy for something incompatible (or even malicious) to sneak its way onto your $PATH and cause havoc.

MacPorts sanitizes PATH and other environment variables. The only way something weird could get into PATH is if the user deliberately modifies the binpath setting in their macports.conf, and there's a comment in that file discouraging that practice.

[john@…]

Note that pass is invoking mktemp, gpg2, srm, etc at run-time, and will pick whatever happens to come first in the user's $PATH. This could be a problem if there's something unexpected in there that happens to share a name with one of the above, either maliciously or just through unfortunate coincidence.

I don't think there's anything that MacPorts can do about this; as far as I know the 'sanitization' you refer to only happens at install-time.

[ryandesign (Ryan Carsten Schmidt)]

That's right, MacPorts' precautions only help at build time. I didn't realize we were talking about runtime behaviors.

[ryandesign (Ryan Carsten Schmidt)]

To guard against a weird PATH at runtime (and this can help at build time too), use the absolute path to each program, making sure to take the user's MacPorts prefix into account.

[Ionic (Mihai Moldovan)]

Committed in r138163. Thanks!