I made a package that installs all applications that are necessary to have the better gpg support in kmail (which has been done by the aegypten project)
Created attachment 7135 [details] aegypten.zip The package of ebuilds
*** Bug 14125 has been marked as a duplicate of this bug. ***
Question, which one is the top ebuilds with the dependency for installing all the other? For example, I have put those ebuilds inside my overlay folder. now which one should I emerge to validate? And shouldn't that ebuild become a dependency on KMail(kdenetwork) based on a USE flags such as "gpg" or "pgp".
The "collecter" ebuild is the aegypten ebuild. It works like the kde ebuild. I don't know about the dependency though. It might be added as a runtime dependency. No part of this package is required for the compilation of kde.
Hi Paul, thanks for this ebuild. It seems that some of the programs I use look for pinentry-xxx at /usr/local/bin but they are installed in /usr/bin. Perhaps you could add something to the ebuild that either builds some symbolic links or tells the user to do so. Christian
Created attachment 7564 [details] pinentry.zip (replaces pinentry from aegypten.zip) This new ebuild includes a patch from cvs to make pinentry-qt work. The problem is very very stupid, as the program got "-display" as argument while expecting "--display". I also added a message that informs the users that the pinentry programs are installed in /usr, and not in /usr/local
When aegypten is used, it is also necessary to start gpg-agent before starting kde. Therefore this is the script I use in the kde session script. if [ -x /usr/bin/gpg-agent ]; then if [ -f ${HOME}/.gpg-agent-info ]; then OLD_GPG_AGENT=`cat ${HOME}/.gpg-agent-info` CHECK_PID=`echo ${OLD_GPG_AGENT}|cut -d ":" -f 2` PROG=`ps -p ${CHECK_PID} |tail -1| sed -e "s,^[^ ]* *[^ ]* *[^ ]* *,,"` if [ "${PROG}x" != "gpg-agentx" ]; then rm ${HOME}/.gpg-agent-info else export GPG_AGENT_INFO=${OLD_GPG_AGENT} fi fi if [ ! -f ${HOME}/.gpg-agent-info ]; then eval "`gpg-agent --daemon`" echo $GPG_AGENT_INFO >${HOME}/.gpg-agent-info fi fi
I installed the packages. Seems to me that aegypten is an empty package only there to get the dependencies installed. Not sure this is a good behavior will need to ask around. What is the kde session (sorry not so much familiar with xwindows/kde integration). Is this the startkde? If the file already contains stuff it would be nice to know if we just append it or insert it or require to put in the middle somewhere...
Is it normal that OpenPGP doesn't respect the "Always sign" and "Always encrypt" options and instead always ask for both? That seems like a bad integration of a plugin when those options exists and are used with gnupg.
What's the status of this? Does it work at all? I recently read the KDE 3.1 New Feature Guide (http://promo.kde.org/3.1/feature_guide.php?page=2), and saw this: "Email Security. On the PIM front, the email client (KMail) has gained several important privacy and security enhancements - namely S/MIME, PGP/MIME and X.509v3 support. This work has been done in successful collaboration with the
What's the status of this? Does it work at all? I recently read the KDE 3.1 New Feature Guide (http://promo.kde.org/3.1/feature_guide.php?page=2), and saw this: "Email Security. On the PIM front, the email client (KMail) has gained several important privacy and security enhancements - namely S/MIME, PGP/MIME and X.509v3 support. This work has been done in successful collaboration with the Ägypten project, an IT security project sponsored by the German government (screenshot). Moreover, OpenPGP support has been enhanced, such as enabling encrypting with a different key for each addressee." Can someone clarify the difference between this aegypten and that aegypten? :)
This is the package collection that enables the features from the aegypten project. The first official version of kde in which aegypten is available is 3.1 It is indeed right that the aegypten package is just a collector just as the kde and gnome ebuilds are. I don't know what the best thing about such packages is, but I like it this way. Another option could be a useflag on kdenetwork and mutt(other client that can use aegypten) About the allways ask behavior. I don't have the problem, but the configuration is plugin specific, and needs to be done in the plugin configuration dialog. About the session script. When using a display manager (gdm/kdm) to start your X session you can select different window managers. These are implemented using session scripts. The kde session script looks like: #!/bin/sh /usr/kde/3.1/bin/startkde Mine contains the beforeposted lines to start gpg-agent if it is not allready started for this user. Those lines need to be put between the startkde line and the /bin/sh line. gpg-agent needs to be started before kde to make sure that all kde components can find gpg-agent in all cases. (This is actually the same for XInput (input methods for chinese/japanese/etc ) )
It works perfectly. I have found the plugin specific configuration and it now better integrate inside KMail. I still don't like the aegypten ebuild because it generate an error about the tar file missing but still look like a success. If we could resolve that then I'll be happy. Maybe an Aegypten USE flags would be better thought. I will present the case to Dan/Hannes. >>> Install aegypten-1.0 into /var/tmp/portage/aegypten-1.0/image/ category app-crypt man: strip: >>> Completed installing into /var/tmp/portage/aegypten-1.0/image/ tar: *: Cannot stat: No such file or directory tar: Error exit delayed from previous errors ln: creating symbolic link `/mnt/network/packages/gentoo/dell_gx110/app-crypt/aegypten-1.0.tbz2' to `../All/aegypten-1.0.tbz2': Operation not permitted >>> Done.
I forgot to mention that there's a need to move the ~/.gnupg/options file to ~/.gnupg/gpg.conf and to create the ~/.gnupg/gpg-agent.conf.
I think there should be a comment about the ./gpg/options rename in the gnupg ebuild. Maybe the overall package or the pinentry package should have a comment referring people to the howto at kmail.kde.org
Discussed this with Hannes, The package is good for KMail and Mutt. Mutt is not kde related. Therefore we will move the environment stuff to env.d and the startup of the deamon to init.d. I will make a config entry to aegypten which if you run under the user for which you use KMail will do the steps about backuping, arranging the gpg.conf/gpg-agent.conf and KMail plugins (if the kde USE flag is set). Therefore for each users you want them to use aegypten you would proceed with emerge aegypten (env-update will be call here) rc-update add <proper name here> default su <user> ebuild aegypten-1.0.ebuild config Is that a good idea? While it is not explicitely related to KDE I am quite interested to have this because I make use of that new security system and it looks better than the integrated one.
The thing is that gpg-agent needs to run for every user using aegypten. I think running the daemon from init.d is misplaced for a situation where a daemon needs to run for a specific user. I think a gpg-agent-check script with the contents I described can be used better. Possibly conditionally sourced in /etc/profile and the various session scripts (maybe a generic sessionprofile script) depending on the existence of an enabling file. Another point (maybe should be a different bug) is the xdm/gdm/kdm startup sequence. Gdm and kdm allow users to select the session to be started. This bypasses the ~/.xsession file. This file is the file that traditionally gets used for starting a window manager and personal favourite apps. gdm and kdm use the directory /etc/X11/Sessions/ where each script represents a different session. The scripts from this directory don't source .xsession as that would start a second window manager. This means there should be another file to allow users to start programs like ~/.xsession and ~/.bash_profile . A solution would be to make a DMSession script is sourced from the various session scripts. This DMSession script then conditionally sources a /etc/X11/dmprofile and a ${HOME}/.dmprofile script (based on existence). Those scripts would be the place from which gpg-agent or XInput programs could be started.
Is this "bug" the reason that I'm constantly seeing "Problem: OpenPGP plug-in was not specified" errors, even though I have kmail configured (in the Security & Privacy Settings) to use GnuPG - Gnu Privacy Guard?
That would be a KMail bug. Because plugins are optional but basically once you configure the plugin this error msg goes away. I don't believe that OpenPGP plugins are or should be required for running KMail and the fact that it is complaining is probably a KMail bug.
The .xsession stuff should be treated as a separate bug and please do enter a new bug to track it. For the gpg-agent, why is not the OpenPGP plugin looking for it and instantiating it if missing? We could even write a KMail wrapper to ensure it is started. This would remove need to have per-session script and when KMail is not started that would make one less daemon to care about. This looks more like a plugin bug than something else.
I committed bug #14872 for the session scripts (http://bugs.gentoo.org/show_bug.cgi?id=14872)
I made a howto for aegypten + kmail, available at my website: http://www.cs.kun.nl/~pauldv/kmailgentoo.php
> Unpack aegypten.zip in your personal portage dir, and do > an "emerge aegypten". Now all necessary packages should > be emerged. I'm having a bit of trouble merging the aegypten ebuild. The above statement isn't exactly clear. What is my "personal portage dir"? Are you suggesting that I should unpack aegypten.zip into my /usr/portage tree? I keep modified ebuilds (mostly locally unmasked unstable packages) in /usr/local/portage. I tried moving the affected classes to /usr/local/portage and upacking aegypten.zip into that tree, but the build fails calculating dependencies (claiming that all builds that could satisfy a certain dep are masked) and I can't figure out the cause of the dep failure. There are no masks defined in the aegypten ebuilds, and no related masks that I can find in /usr/portage/profiles/package.mask. I would post more details, but I want to be certain that I'm not causing the failure before I waste everyone's time. Would you mind being explicit about the installation procedures, particularly the working directory into which the files should be placed? Once I'm certain about the procedures, if I still expecience problems I'll post the details. Thanks, D.
Personal portage dir means the contents of PORTDIR_OVERLAY. In your many cases /usr/local/portage The problem is some of the involved packages have in the meanwhile been put in the official gentoo tree. They are masked there though, causing the masking problems. Running ACCEPT_KEYWORDS="~x86" emerge aegypten should solve the problem
Problems to solve before this gets in the tree: Why is libgcrypt 1.1.10 dependency was change to app-text/docbook2X while previous version uses app-text/docbook-sgml-utils? We need proper description for all package. Most of them are "Needed for aegypten" or going around that theme. This is, in my opinion, not acceptable as a description. Instead, we would prefer having the real description of the library. For example: libksba -> DESCRIPTION="Aegypten development library" newpg -> DESCRIPTION="NewPG, part of the aegypten project" cryptplug -> DESCRIPTION="Part of the aegypten project" pinentry -> DESCRIPTION="Part of the aegypten project" Another question is, cryptplug is the plugin used by KMail and Mutt right? Then why is not that called aegyptenplugin which in my opinion would make more sense than cryptplug has that is a general name that doesn't related to secure mail at all. It also seems like cryptplug should be the dependency of KMail / Mutt and not the empty aegypten. Is there problem with this? Am I missing the point?
There's already some package that made their way to portage. dev-libs/libgcrypt-1.1.10 dev-libs/libksba-0.4.6 app-crypt/gpgme-0.3.14 app-crypt/cryptplug-0.3.15 It is now only missing pinentry and newpg.
Ok, here come some nice descriptions (you're right about that): Cryptplug: DESCRIPTION="gpg and s/mime encryption plugins for kmail and mutt" Newpg: DESCRIPTION="NewPG is the S/MIME variant of GnuPG which does also include the gpg-agent" libgcrypt: just a version bump (the old version might work, I didn't check there is a .12 version now) libksba: DESCRIPTION="KSBA makes X.509 certificates and CMS easily accessible to applications" pinentry: DESCRIPTION="modules for entering passphrases into gpg-agent for ncurses, qt and gtk+" The docbook2X dependency in libgcrypt was a mistake trying to fix the docbook script included in the package. After really fixing it (with sgml-db-utils), it turns out that nowhere it is actually called, so I removed the dependency altogether (commented out). (I will post a new package shortly with new descriptions) About cryptplug. Aegypten is the name of a German government funded project with the purpose of getting gpg and s/mime support into opensource. It's existence is/was temporary. I think cryptplug is short for something like cryptography-plugin but I'm in no way related to the aegypten project. It's functionality is for now limited to mutt and kmail, but other packages that need gpg signing / signature checking could use it too. About the aegypten ebuild. I wrote it for my own convenience. One I'm not a gentoo maintainer so I do not have access to CVS. As such I try to limit what my builds touch. Also the relationship of kmail (don't know about mutt) with aegypten is some like I compile without it, I run without it, I can use it if it is there. For someone not using kmail for reading/sending pgp mail it should IMHO not be necesarry to compile in gpg and all other packages.
Created attachment 7932 [details] aegypten.zip (Updated version) This is an updated version with descriptions and gpgme removed (it is allready in the main portage tree and the description is OK) For the packages in the portage tree but with lousy descriptions I made a revision bump.
Another question... cryptplug generate the opengpg plugin for mutt/kmail right? There is actually no dependencies on newpg and pinentry. Therefore my question is how those two packages related to cryptplug? Should I set newpg & pinentry as a RUNNABLE DEPENDENCY? What happens exactly if those packages are not install, what functionnality will be provided by cryptplug without those?
newpg and pinentry might be only runtime deps. Basically cryptplug asks gpg-agent (from newpg) for the passphrase. Depending on the cache gpg-agent will supply the passphrase or use pinentry to get the passphrase.
What happen if cryptplug cannot find gpg-agent? Does it default back to some other kind of functionnalities? I wouldn't want to enforce a dependency if cryptplug is usable without newpg/pinentry which is why I'm asking for even more details.
Created attachment 7977 [details] newpg-0.9.4.ebuild (new version) This is a new version of newpg that sets pinentry-gtk as default pinentry. It uses pinentry-gtk as default. It also looks for other tools in /usr not in /usr/local
If there is no pinentry kmail functionality will not work as there is no way to ask for a passphrase without a correct pinentry program. The plugin just fails giving some error that pinentry was not found. I believe (+95% sure) that gpg-agent cannot ask for passphrases without pinentry. I did find though with my test user that the functionality actually works without a gpg-agent.conf configuration file (now that I set a sane default pinentry program). The only necessity is for gpg-agent to be actually started before kmail starts, and that the GPG_AGENT_INFO variable is set correctly in kmail's environment
Hmm, I committed ebuilds for newpg and pinentry earlier today, without knowledge of this bug. My newpg ebuild doesn't set a default pinentry, but you can set it in your ~/.gnupg/gpg-agent.conf file. E.g. "pinentry-program /usr/bin/pinentry-gtk" My goal was/is to get all the necessary pieces in portage to be able to use gpg with kmail, following the guide on kmail's site. An updated libmcrypt ebuild is forthcoming pending an investigation into some docbook details (bug 15026).
Seems like all the piece of the puzzle are in place. For me, the PGP stuff is working, I had trouble with S/MIME but not much a worry (the plugin failed to load inside KMail... probably because I need an X.509 cert somewhere.)
About the default pinentry module in newpg. While it is not essential (I didn't change this since today either), I believe setting a default pinentry that is actually available is a good idea. Of course we still want people to make a configuration file (a.o. for a pinentry-qt pinentry)
I didn't mention before but pinentry-qt is broken, so I disabled it in the ebuild for now.
the separate pinentry.zip in this bug contains a patch taken from cvs that fixes pinentry-qt. I'm happily using it at the moment.
Ah, great. I added the patch to my ebuild and committed an -r1.
I believe that this is now inside portage and we can mark as resolved.
It's not completly in portage, so shouldn't be marked as resolved. Cryptplug in portage is version 0.3.15 but in aegypten.zip 0.3.15-r1 and aegypten.ebuild isn't in portage at all.
My version numbers are not portage version numbers, I just used different versions then the ones in the standard tree. About the aegypten ebuild. This is just a collector package, so technically only the aegypten ebuild is necessary
I personnaly feel that aegypten ebuild is not a valid ebuild to have because it's whole purpose is to get the other packages installed. The same could be achieve using emerge pinentry newpg cryptplug
hmm, shouldn't kdenetwork RDEPEND on these packages if USE=crypt? and what about this gpg-agent start script? we should imho do it in portage (but I'm not sure where): -startkde seems to be wrong cause aegypten is not only for kmail (it also works with mutt afaik) -an init script is not a per-user starting so maybe it should be anywhere in /etc/ and the newpg ebuild should tell the user that he has to source /etc/the-script to get it working. is there also a way to have if USE=crypt a default kmail config which provides information where the plugins are?
You are right. For sourcing /etc/the-script there is another problem which I described in http://bugs.gentoo.org/show_bug.cgi?id=14872 . If you use gdm or kdm (maybe wdm too) then there is no easy way to source some script at startup.
