colord-0.1.11 and below runs as root and automatically probes for color profile files in external volumes. Since this is hardly an example of great security practices, in 0.1.12 upstream added the ability to run the colord daemon as a non-root user and to prevent the colord process from reading external volumes. I believe that we should follow Debian's example and make use of both of these security features. One potential issue is that users who ran colord-0.1.11 (as root) and modified their systemwide color management settings will have various color management configs in /var that belong to root:root. Fortunately, due to an oversight about how colord configure interprets $localstetedir, our <=colord-0.1.11 packages used /var/lib/lib/colord and /var/lib/lib/color as the config directories. We can thus switch to /var/lib/colord and /var/lib/color for 0.1.12 and direct the user to cp and chown his customized settings from /var/lib/lib by a message in pkg_postinst(). See http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=tree;f=x11-misc/colord for the colord-0.1.12 ebuild currently in the overlay.
+*colord-0.1.12 (28 Sep 2011) + + 28 Sep 2011; Pacho Ramos <pacho@gentoo.org> +colord-0.1.12.ebuild: + Version bump that also runs as a different user than root. Thanks a lot to + Alexandre Rostovtsev for doing all the work (bug #384607). +
