Bugzilla Bug 108845

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 an attachment (id=70348) [edit]
ebuild patch.

Created an attachment (id=70349) [edit]
no-hebrew-hack.patch

Created an attachment (id=70350) [edit]
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 an attachment (id=78485) [edit]
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.