--===============1649369792867357341== Content-Type: multipart/signed; boundary="nextPart4006830.8drCHuaYvr"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart4006830.8drCHuaYvr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, On Sunday, August 30, 2015 08:04:59 PM Rolf Eike Beer wrote: > Jeremy Whiting wrote: > > On Sun, Aug 30, 2015 at 8:48 AM, Jeremy Whiting = wrote: > > > Hey all, > > >=20 > > > I may have found another candidate for unmaintained. KGpg is a ui= for > > > gnupg. I've never used it, but have used kleopatra. Anyway, here'= s my > > > reasoning. Please fix any false assumptions I may have made if yo= u > > > know kgpg or kleopatra better than I: > > >=20 > > > 1. KGpg does gnupg. Kleopatra also does, but is maintained. > > > 2. KGpg has not been ported to Qt5/kf5, Kleopatra has. > > > 3. KGpg isn't part of kdepim nor is it maintained by the PIM team= , > > > Kleopatra is. > > >=20 > > > Is there anything that KGpg does that Kleopatra doesn't/can't do?= Or > > > is there any reason to port KGpg to Qt5/kf5 and keep releasing it= ? > >=20 > > Correction, KGpg is maintained, Rolf made commits as late as last > > month. My mistake. I gave KGpg a try here and it does seem to work > > well. Rolf, could you use a hand porting it to Qt5/KF5 ? >=20 > I did not port for the reason that KGpg depends on kdepimlibs (KABC),= which > had no Qt5-based release yet (now it has), and I must confess I can o= ccupy > my time with other stuff and was too lazy to build it from git. In fa= ct I > was asked at least twice why there was no KF5-port and both were also= too > lazy to build kdepimlibs stuff themself. Now that there is a release = it > makes actually sense to port, so I hope I can manage it in time for 1= 5.12. > If someone is bored and wants to assist I will not reject any efforts= . What's the state of GnuPG 2.1 support in KGpg? I've tried to run KGpg (= from=20 debian jessie) on my with 2.1 and it fails to start with an error that = It=20 can't find the Gpg-agent. (Probably because there is no mandatory=20 GPG_AGENT_INFO anymore) > Kleopatra can do X.509, which KGpg can't. I never found that really m= issing. So you probably never much had encrypted communiction with instutional = users.=20 ;-) S/MIME is pretty widespread there. (At least in Germany) =20 > And KGpg looks so much more beautiful ;)=20 Aww, now you've hurt Kleopatra's feelings (Doesn't she have a cute nose= ) ;-) But I have to agree there at least for the keylisting. (as Sune and Ann= e also=20 wrote in the other branch of this topich). The Keylisting / visualizati= on of=20 validity is imho better in Kgpg. Something I hope to address in Kleopat= ra at=20 some point. This will probably go along with GnuPG's TOFU database / us= age=20 statistics that are currently worked at. Which will also need new=20 representation in GUI's. Kleopatra at least has the advantage that it uses the official API (gpg= me) and=20 so it is theoratically much easier to work with new features and differ= ent=20 versions of GnuPG. Buit let's not get into a detailed comparision of Kleo vs. Kgpg I don't= think=20 that would be helpful. I'd much rather see us working together on a single GUI then splitting = the=20 effort to work on two Certificate Managers in the KDE community. Of cou= rse I=20 doub't that will happen. If you are willing to work on KGpg Ok! Alternatives are good. :-) There is also another advantage KGpg has over kleopatra, The Kleopatra=20= codebase is kind of a beast with a usage of stdc++ and boost that is pr= obably=20 unfamiliar to most KDE hackers. > And it has the CAFF mode, which I doubt Kleopatra has.=20 I actually did not know that. Maybe something we could add to Kleopatra= then,=20 too. > And it supports photo ids, which I was told was > intentionally left out of Kleopatra for some policy reasons. Yes. Afaik this was done because the gnupg maintainer requested us not = to=20 support this in Kleo. The reasons for this are: =2D Gives a false sense of security. =2D Increases the attack surface as you need image parsers to parse exter= nal=20 Input. =2D Key size is drastically increased. =2D Considered bad practice even though the OpenPGP standard allows for t= his. I did not find sources for these claims, just something I picked up in=20= discussions. I was not around when it was decided in the first place. M= aybe we=20 should discuss this again.=20 Regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, H= R B 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wa= gner --nextPart4006830.8drCHuaYvr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlXkGsYACgkQXek4XMl4IvVuKACdGXlZI5qishm/fXdmCNx94BRD nMoAoKFa/7K0vI8hBIGLlA4Z1cfdcsA+ =SWDh -----END PGP SIGNATURE----- --nextPart4006830.8drCHuaYvr-- --===============1649369792867357341== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmVsZWFzZS10 ZWFtIG1haWxpbmcgbGlzdApyZWxlYXNlLXRlYW1Aa2RlLm9yZwpodHRwczovL21haWwua2RlLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JlbGVhc2UtdGVhbQo= --===============1649369792867357341==--