Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 475352 - app-misc/ca-certificates: clean old broken symlinks in pkg_postinst
Summary: app-misc/ca-certificates: clean old broken symlinks in pkg_postinst
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 245984
  Show dependency tree
 
Reported: 2013-06-30 18:07 UTC by Pacho Ramos
Modified: 2015-03-22 00:01 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2013-06-30 18:07:24 UTC
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
Comment 1 SpanKY gentoo-dev 2013-12-03 08:25:11 UTC
i recall there being a specific reason for us not doing this.  perhaps to do with user certs or something ?

Robin: do you remember ?
Comment 2 Thomas Deutschmann gentoo-dev Security 2013-12-03 17:49:00 UTC
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.
Comment 3 SpanKY gentoo-dev 2013-12-07 09:16:17 UTC
(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.
Comment 4 Daniel Robbins 2014-03-14 15:33:57 UTC
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.
Comment 5 Rick Farina (Zero_Chaos) gentoo-dev 2014-03-17 14:17:30 UTC
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.
Comment 6 Oleh 2014-03-17 17:25:52 UTC
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
Comment 7 Rick Farina (Zero_Chaos) gentoo-dev 2014-03-17 18:10:40 UTC
(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.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-03-24 16:42:12 UTC
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.
Comment 9 Rick Farina (Zero_Chaos) gentoo-dev 2014-03-24 17:56:25 UTC
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?
Comment 10 SpanKY gentoo-dev 2014-03-25 19:31:59 UTC
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.
Comment 11 Thomas Deutschmann gentoo-dev Security 2014-03-25 19:50:11 UTC
(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?
Comment 12 Rick Farina (Zero_Chaos) gentoo-dev 2014-03-27 00:55:51 UTC
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.
Comment 13 SpanKY gentoo-dev 2014-03-28 06:43:32 UTC
(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
Comment 14 Rick Farina (Zero_Chaos) gentoo-dev 2014-03-30 18:45:24 UTC
(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.
Comment 15 SpanKY gentoo-dev 2014-04-10 03:21:19 UTC
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.