yubico-piv-tool: new port

[lbschenkel (Leonardo Brondani Schenkel)]

This port installs command line tools to manage the PIV applet which is included in the YubiKey NEO. It also contains a PKCS#11 module to make the keys/certs usable by PKCS#11-aware programs (plus I'm including the necessary glue to make it auto-discoverable by p11-kit).

I'm volunteering to maintain this port.

Unfortunately the latest official release has some annoying bugs (including a build bug that prevents it from being built properly) that were later fixed in Git, so for now I'm building the a hash from master (and calling it 1.2.5-pre) but I intend to stop tracking master and stick to official releases once 1.2.5 is out.

[lbschenkel (Leonardo Brondani Schenkel)]

The license was wrong, I have fixed it.

[ryandesign (Ryan Carsten Schmidt)]

The openssl dependency should be written path:lib/libssl.dylib:openssl

There should not be a / in ${destroot}/${p11kit_module_configs}

New port submissions should be made by submitting the Portfile, not a diff that creates the Portfile.

[lbschenkel (Leonardo Brondani Schenkel)]

(Correction to description: I meant 1.4.3, not 1.2.5.)

I am attaching the Portfile with the suggested corrections. Apologies for the patch, force of the habit. I have the following questions:

1. When a Portfile has additional files, should it be submitted as a .patch or something else (.zip)?
2. Since the port is linking to libcrypto why am I checking for libssl?
3. Why are you suggesting to change the dependency from lib:... to path:...?

[neverpanic (Clemens Lang)]

Replying to leonardo.schenkel@…:

1. When a Portfile has additional files, should it be submitted as a .patch or something else (.zip)?

If it's only a file or two, just attach them directly.

2. Since the port is linking to libcrypto why am I checking for libssl?

path:lib/libssl.dylib:openssl allows libressl to satisfy the dependency; it doesn't matter whether you use libssl or libcrypto here, since both are provided by the same port. You can change it, but AFAIK we have all openssl dependencies written in this way.

3. Why are you suggesting to change the dependency from lib:... to path:...?

See above.

Thanks for doing this. Ping me if this gets stuck for too long.

[lbschenkel (Leonardo Brondani Schenkel)]

I understand that both OpenSSL and LibreSSL provide the library. What I don't understand is that I was asked to change from:

lib:libcrypto:openssl

which as I understand means "install OpenSSL if libcrypto.dylib is not available" to:

path:lib/libssl.dylib:openssl

which not only should be equivalent to the above in a more verbose syntax, but I'm checking a different library than the port is linking to. (I know that OpenSSL/LibreSSL provide both libraries, but I do think the point is to check the library the port actually links to, not a different one that happens to be provided by the same dependency.)

[larryv (Lawrence Velázquez)]

Replying to leonardo.schenkel@…:

I understand that both OpenSSL and LibreSSL provide the library. What I don't understand is that I was asked to change from:

lib:libcrypto:openssl

which as I understand means "install OpenSSL if libcrypto.dylib is not available" to:

path:lib/libssl.dylib:openssl

which not only should be equivalent to the above in a more verbose syntax

​They are not equivalent. lib:libcrypto:openssl would also find /usr/lib/libcrypto.dylib, which is not acceptable.

[lbschenkel (Leonardo Brondani Schenkel)]

Oh, that is the part that I was missing. Thanks for the clarification.

Regarding libcrypto/libssl, since the port wants to link to libcrypto.dylib shouldn't this be the library that I am checking? It is still puzzling to me why I was asked to change to verify the presence of libssl.dylib if the port doesn't link to it.

[lbschenkel (Leonardo Brondani Schenkel)]

Could I get another review for this submission, please?

[neverpanic (Clemens Lang)]

Committed in r154025. I took the liberty of adding the missing pkg-config dependency.

[lbschenkel (Leonardo Brondani Schenkel)]

Thank you, but I think the dependency should have been path:lib/libcrypto.dylib:openssl instead.

I have asked multiple times for clarification regarding why I was previously asked to change from libcrypto to libssl (the lib: to path: part is clear now) but there was no reply. I don't understand why the port should look for the existence of a library that it does not link against.

Could you please shed some light on the matter, cal@…?

[neverpanic (Clemens Lang)]

The truth is, it doesn't really matter. Any file installed by the openssl and libressl ports would do. Previously we've used paths to pkg-config files, files in $prefix/share or binaries. I've kept it as-is because it doesn't make a difference and because somebody running a grep for these kind of dependencies might expect all path-style dependencies on openssl/libressl to be written in the same way.

[lbschenkel (Leonardo Brondani Schenkel)]

OK, then. I thought the whole point was to check for the needed library, and if it is not present then specify which port provides it so it gets installed. I just find it strange to check for a file that's not required by the port.

[larryv (Lawrence Velázquez)]

You might consider the opposite situation: a port that uses several files from a dependency. In that case, the dependent cannot list every file that it needs, so the author must pick one and assume that the rest are provided by whatever dependency is chosen.

The mindset is always “some file installed by the dependency”, not necessarily one that is used. Many ports look for the dependency’s pkgconfig files, even though they don’t use them at all.

[lbschenkel (Leonardo Brondani Schenkel)]

Sure, but in this case you are choosing one among the multiple files that you depend and are provided by the dependency. But here we're choosing one of the files the port *does not* need that happens to be provided by a dependency that provides files that the port does need. That simply seems wrong to me.

Imagine that tomorrow there's a new crypto library that provides a compatible implementation of libcrypto (but not SSL/TLS); if that port was installed it would satisfy the requirement for this port, but this Portfile would still install openssl even though that's unnecessary (and would cause a conflict).

Anyway, I'm not asking for any change to be made. I'm just asking/discussing for the intellectual exercise (and I like to understand the reasoning behind certain decisions). I just think that if you need to pick an arbitrary file to declare a dependency on, it makes more sense to pick a file that you actually depend on than one random one that you don't. But it's a matter of opinion, I guess.