The attached patch applied to current ebuild fixes a couple of problems: - it use the right configure option to enable/disable gtk2 support, so now is possible to build pinentry without gtk support and only with qt itself; - it applies the no-hebrew-hack.patch (also attached) to allow it compile with qt support (fails elseway :/); - it applies the attached -libcap patch, that allows to disable libcap support instead of leaving it autorecognized, this also adds the caps useflag, and its dependency over sys-libs/libcap (before it was enabled if installed, and dependency was missing, it could be used with fixed libcap dependency but in that case it should be conditional to kernel_linux; - it also uses the new bindnow-flags function to get the right flags for bindnow in current linker. HTH, Diego
Created attachment 70348 [details, diff] ebuild patch.
Created attachment 70349 [details, diff] no-hebrew-hack.patch
Created attachment 70350 [details, diff] pinentry-0.7.2-libcap.patch
Disregard the no-hebrew-hack stuff, that's caused by sucky qt visibility support, I'm going to back off from it this night.
Sven can you take a look to this? :)
Created attachment 78485 [details, diff] Ebuild patch Okay I forgot about this until tonight, sorry. The attached patch is on the current ebuild; it goes a step further, it doesn't set the pinentry programs suid when using caps (as that would make useless caps anyway).
Limits and permissions In Linux 2.6.8 and earlier, a process must be privileged (CAP_IPC_LOCK) in order to lock memory and the RLIMIT_MEMLOCK soft resource limit defines a limit on how much memory the process may lock. Since Linux 2.6.9, no limits are placed on the amount of memory that a privileged process can lock and the RLIMIT_MEMLOCK soft resource limit instead defines a limit on how much memory an unprivileged process may lock. With >=2.6.9 we don't need libcap, we can disable suid and still be on the safe side as long as ulimit -l is at least 16384 bytes large. On <2.6.9 using libcap and not suid only gains us anything, if CAP_IPC_LOCK is added to the permitted set of the user at login time. Which probably isn't on a default system, hence we're still unprivileged and can't lock the memory. If we're suid, libcap doesn't gain us anything, because we're already privileged through suid, lock the memory and later drop the privilege and uid back to the user.
Thanks Diesgo, commited to CVS.
