Is there any reason why telling people that they MUST run: find -L /etc/ssl/certs/ -type l -exec rm {} + and not running it by ebuild itself? Thanks a lot :) Reproducible: Always
i recall there being a specific reason for us not doing this. perhaps to do with user certs or something ? Robin: do you remember ?
Please could you also explain while looking into this why you call "update-ca-certificates" multiple times (i.e. in src_compile only for "$S" and later in pkg_postinst)? Why not just call update-ca-certificates once in pkg_postinst without the "--root" parameter so that /etc/ssl/certs will be updated with data from "/usr/share" and "/usr/local/share"? Maybe we can use the "--fresh" parameter too so we don't need to check for broken links at the end. If the user has installed his/her own certificates the right way (e.g. placed them somewhere in "/usr/local/share/ca-certificates" there shouldn't be a problem. People who put certificates into "/etc/ssl/certs" may lose them (that's maybe be the reason why we are currently call update-ca-certificates within src_compile, so that emerge won't replace any not proper installed certificates from /etc/ssl/certs), but they didn't do it right. Not sure if we should care about such setups.
(In reply to Thomas D. from comment #2) src_* funcs must never utilize ROOT variables the normal situation is to not have any local ca certs which means the script only gets run once -- at build time. thus deploying binpkgs is light weight.
This is just silly. This ebuild is way too high-maintenance. Regular users should not need to manually prune broken symlinks from their certificate directory. Bad and unreasonable user experience. I can understand some manual maintenance required if you are actually *using* your own certificates, but if you're just using the supplied ones, then upgrades should "just work". The "find" command can run from pkg_postinst and move broken symlinks to a back-up directory where they won't interfere, if you want to be ultra-anal. *Then* print a warning saying "I moved all these broken symlinks out of the way, please review them to ensure that this is okay." But ideally, ca-certificates would just take care of things for you without any warnings.
QA opinion: This is causing breakage on user systems. The problem is this, older ebuilds ran update-ca-certificates in pkg_postinst which created file which are not owned by the ebuild, and not removed on uninstall/upgrade. Newer ebuilds still run this conditionally, if the user has a folder /usr/local/share/ca-certificates/. No matter what, it seems to make sense to remove the broken symlinks as the last step of pkg_postinst *instead of simply warning the user that their system is broken*. Optionally the running of update-ca-certificates in pkg_postinst could be changed to a message, but if we are actively removing broken symlinks (which are caused by running update-ca-certificates in pkg_postinst) then it's really a maintainer choice. Either way, tl;dr please remove the warning to remove dangling symlinks and just do it.
moving old certs to backup directory looks like a good idea, as per comment 4. It's crucial for production environments not to play games with it
(In reply to Oleg from comment #6) > moving old certs to backup directory looks like a good idea, as per comment > 4. It's crucial for production environments not to play games with it Nothing on this bug is discussing old certs, we are discussing broken symlinks.
spanky: the historical reason for not running it automatically, was when Debian previously removed certs, they was no visibility about it, and we had at least one bug from a user due to that prior cert removal (it was a weird cert origin as well). The proposal to move the broken symlinks out of the way is much more sound to me, so users can see the broken ones if needed, whilst not having them break the system.
Although I believe it's entirely pointless to preserve broken symlinks, it seems I'm in the minority. that said, it's easy enough to preserve them in a new folder and then warn when it happens. Is the location /etc/ssl/certs/broken_symlinks okay with everyone for this preservation?
alternatively, do nothing and the situation will fix itself over time :P as noted, this has been fixed in >=ca-certificates-20110502-r2, it's just the symlinks that were generated by versions older than that that slowly degrade over time. if you install a system that started at that version, you should never see this issue.
(In reply to Rick Farina (Zero_Chaos) from comment #9) > Is the location /etc/ssl/certs/broken_symlinks okay with everyone for this > preservation? Should be fine. Tools using "-CAPath /etc/ssl/certs" should keep working (=the subfolder shouldn't cause any trouble). (In reply to SpanKY from comment #10) > as noted, this has been fixed in >=ca-certificates-20110502-r2, it's just > the symlinks that were generated by versions older than that that slowly > degrade over time. if you install a system that started at that version, > you should never see this issue. Mh? How do you mean that? I am seeing the problem with broken symlink with # grep 'Broken' /var/log/portage/elog/*ca-cert* /var/log/portage/elog/app-misc:ca-certificates-20130610:20130715-022347.log:Broken symlink for a certificate at /etc/ssl/certs/656b3e35.0 /var/log/portage/elog/app-misc:ca-certificates-20130610:20130715-022347.log:Broken symlink for a certificate at /etc/ssl/certs/b097d71d.0 /var/log/portage/elog/app-misc:ca-certificates-20130906:20130923-192011.log:Broken symlink for a certificate at /etc/ssl/certs/656b3e35.0 /var/log/portage/elog/app-misc:ca-certificates-20130906:20130923-192011.log:Broken symlink for a certificate at /etc/ssl/certs/b097d71d.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/ce026bf8.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/2cfc4974.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/20d096ba.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/55a10908.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/03f0efa4.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/5f267794.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/9af9f759.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/99d0fa06.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/c692a373.0 /var/log/portage/elog/app-misc:ca-certificates-20140223:20140317-130100.log:Broken symlink for a certificate at /etc/ssl/certs/590d426f.0 /var/log/portage/elog/app-misc:ca-certificates-20140223.3.15.5:20140321-140801.log:Broken symlink for a certificate at /etc/ssl/certs/03f0efa4.0 /var/log/portage/elog/app-misc:ca-certificates-20140223.3.15.5:20140321-140801.log:Broken symlink for a certificate at /etc/ssl/certs/590d426f.0 /var/log/portage/elog/app-misc:ca-certificates-20140223.3.16:20140323-205640.log:Broken symlink for a certificate at /etc/ssl/certs/03f0efa4.0 /var/log/portage/elog/app-misc:ca-certificates-20140223.3.16:20140323-205640.log:Broken symlink for a certificate at /etc/ssl/certs/590d426f.0 ...and the system was build in 2013 and has never seen an app-misc/ca-certificate package from 2011. PS: I also disagree with https://bugs.gentoo.org/show_bug.cgi?id=475352#c3 - For me it is wrong to run update-ca-certificate in/on the image, because the user may have something in /usr/local or a modified /etc/ca-certificates.conf update-ca-certificates should honor. Yes it saves time, because most people won't have modifications, but it is still wrong. You get my point?
Changed warning of broken symlinks to: ewarn "Removing the following broken symlinks:" ewarn "$(find -L "${EROOT}"/etc/ssl/certs/ -type l -printf '%p -> %l\n' -delete)" This was done with a revbump due to the user reports of breakage. Sorry if I wasted ~20 seconds for anyone.
(In reply to Thomas D. from comment #11) (1) if you read the ebuild, you'll already see /usr/local is handled (2) users already cannot modify the /etc config file, so that's not an issue (In reply to Rick Farina (Zero_Chaos) from comment #12) we can probably mitigate this further by only running the auto-deletion logic when upgrading from an old version
(In reply to SpanKY from comment #13) > (In reply to Rick Farina (Zero_Chaos) from comment #12) > > we can probably mitigate this further by only running the auto-deletion > logic when upgrading from an old version I simply put the removal logic in place of the previous warning logic. As such, this already only runs when broken symlinks are detect afaict. Upgrading or not, we need to fix the broken symlinks. You are the maintainer and are welcome to further optimize, but it looks fine to me as is.
the broken symlinks most likely originate from the openssl ebuild (bug 333069). i wonder if we can change the ca-certificates script to preserve symlinks. or have openssl not rewrite things. hmm.
