ca_root_nss's pkg-message claims the following:
This package installs symlinks to support root certificates discovery by
default for software that uses OpenSSL.
This enables SSL Certificate Verification by client software without manual
If you prefer to do this manually, replace the following symlinks with
either an empty file or your site-local certificate bundle.
This appears to be mostly false: only one of those files is a symlink, the others are actual data (and not hardlinked either, all different inodes). Proof:
$ ls -li /etc/ssl/cert.pem /usr/local/etc/ssl/cert.pem /usr/local/openssl/cert.pem
1926146 lrwxr-xr-x 1 root wheel 38 May 25 18:12 /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt
15168803 -rw-r--r-- 1 root wheel 789991 May 25 18:12 /usr/local/etc/ssl/cert.pem
15168805 -rw-r--r-- 1 root wheel 789991 May 25 18:12 /usr/local/openssl/cert.pem
And let's check out /usr/local/share/certs/ca-root-nss.crt for completion:
$ ls -li /usr/local/share/certs/ca-root-nss.crt
15168667 -rw-r--r-- 1 root wheel 789991 May 25 18:12 /usr/local/share/certs/ca-root-nss.crt
And the md5s of all the literal files:
$ md5 /usr/local/etc/ssl/cert.pem /usr/local/openssl/cert.pem /usr/local/share/certs/ca-root-nss.crt
MD5 (/usr/local/etc/ssl/cert.pem) = 2e98964306c1868bcabf06364514f216
MD5 (/usr/local/openssl/cert.pem) = 2e98964306c1868bcabf06364514f216
MD5 (/usr/local/share/certs/ca-root-nss.crt) = 2e98964306c1868bcabf06364514f216
So: three (3) physical copies of the same file, and one symlink to one of those copies. Let's look further:
$ pkg info -l ca_root_nss
$ ls -l /usr/local/etc/ssl/cert.pem.sample /usr/local/openssl/cert.pem.sample
lrwxr-xr-x 1 root wheel 38 May 25 18:12 /usr/local/etc/ssl/cert.pem.sample -> /usr/local/share/certs/ca-root-nss.crt
lrwxr-xr-x 1 root wheel 38 May 25 18:12 /usr/local/openssl/cert.pem.sample -> /usr/local/share/certs/ca-root-nss.crt
The .sample files are symlinks, but the non-.sample files aren't (sorry for the double negative).
Thus: either the message is wrong/incorrect, or something changed between when the message was written and present that removed use of symlinks and instead uses literal copies.
I reviewed the Makefile, target do-install, and all I see being done symlink-wise is for .sample files. I'm not even sure what's generating the non-.sample files...
what is the current status?
Does ports-secteam have to be active here?
No answer to my question from 2019-02-15. Closed
Re-opening because this problem has not gone away. I don't know why FreeBSD project members would think that. You can verify the problem yourself; the initial report contains the details.
ports-secteam@ is the maintainer of this port. I do not know if "they should be involved", as I suspect there is only 1 person in that team who actually maintains this port. No idea who that is.
To recap: the problem is explained in the description of this bug, and at the end of my initial comment:
> Thus: either the message is wrong/incorrect, or something changed between when the message was written and present that removed use of symlinks and instead uses literal copies.
> I reviewed the Makefile, target do-install, and all I see being done symlink-wise is for .sample files. I'm not even sure what's generating the non-.sample files...
So: either a) pkg-message need to be updated to reflect the truth, or b) actual symlinks need to be used everywhere and not copies.