Re: seahorse and gpg

I believe one of these versions breaks the usage of older style pgp v3(?) keys by default. This should probably be latest version with a note to use the .conf option to be able to use the old key and how to generate a new one. Having 1.4 seems unwise. But this should be answered definitively as to why (we have to forego extra CPU usage on slower machines because we've reached the point of easily and cheap to bust small key lengths, which will be inconvenient to older arch people using the mail plugin).

Cheers.

(With the security-team hat on)

--
William J. Coldwell ARIN:WC25 PGP:0x5E994445 @Cryo AIM:Cryonator
Warped Inc. helpdesk.warped.com 661-WARPED1 @warped @deadjournal
Put on 3D glasses, otherwise you only see in 1½D.

On Oct 29, 2015, at 07:07, Tobias Nygren <tnn%NetBSD.org@localhost> wrote:

On Thu, 29 Oct 2015 12:31:08 +0100
Richard PALO <richard%netbsd.org@localhost> wrote:

pbulk balks at seahorse, which seems to compile fine normally. It appears
to come from a missing dependency on gpg (implicit via gpgme?).

I tried the following quick hack:
richard@omnis:/home/richard/src/pkgsrc/security/seahorse$ git diff ../gpgme
diff --git a/security/gpgme/buildlink3.mk b/security/gpgme/buildlink3.mk
index bf9de4f..678952f 100644
--- a/security/gpgme/buildlink3.mk
+++ b/security/gpgme/buildlink3.mk
@@ -17,9 +17,17 @@ pkgbase:=            gpgme
.include "../../mk/pkg-build-options.mk"

.if !empty(PKG_BUILD_OPTIONS.gpgme:Mgpgsm)
+. if !empty(PKG_BUILD_OPTIONS.gpgme:Mgnupg21)
+DEPENDS+=              gnupg21>=2.1:../../security/gnupg21
+. else
+DEPENDS+=              gnupg2>=2.0<2.1:../../security/gnupg2
+. endif
GPGME_GPG=             ${PREFIX}/bin/gpg2
+CONFIGURE_ARGS+=       ac_cv_path_GNUPG=${GPGME_GPG}
.else
+DEPENDS+=              gnupg>=1.4.2:../../security/gnupg
GPGME_GPG=             ${PREFIX}/bin/gpg
+CONFIGURE_ARGS+=       ac_cv_path_GNUPG=${GPGME_GPG}
.endif

.endif # GPGME_BUILDLINK3_MK

which seems to now build okay, but is this reasonable? Too me it seems convoluted...
Could someone a bit more familiar with these waters take a look?

Looks OK to me. Even if convoluted, it is needed to unbreak things after
my options.mk change and should be committed.

I believe there may be other "issues" around gpg use elsewhere where there
may be a better solution. BTW, why are there so many flavours?

Beats me. 2.1 looks like it should have replaced 2.0 instead of being
a new package. Having multiple versions of packages toggled by options
makes binary packages useless.

-Tobias