Package Details: gnupg-git 2.1.0beta3+220+g82c25e6-1

Git Clone URL: https://aur.archlinux.org/gnupg-git.git (read-only)
Package Base: gnupg-git
Description: GNU Privacy Guard 2 - a PGP replacement tool. Development version. Do not use in production environments. Test new ECC algorithm by using --expert with --gen-key
Upstream URL: http://www.gnupg.org/
Licenses: GPL
Conflicts: dirmngr, gnupg, gnupg2
Provides: dirmngr, gnupg=2.1.0beta3+220+g82c25e6
Replaces: dirmngr, gnupg, gnupg2
Submitter: alphazo
Maintainer: alphazo
Last Packager: alphazo
Votes: 1
Popularity: 0.000000
First Submitted: 2013-06-30 19:25
Last Updated: 2015-06-10 14:22

Required by (117)

Sources (1)

Latest Comments

alphazo commented on 2014-10-03 09:05

@flick, secret key export of ECC keys seems to be working now.

djhaskin987 commented on 2014-09-15 17:57

This build is asking for libgpg-error 1.15+ now. Currently the core/ repo has 1.14 . I have added a library in the AUR for this library that works off of git: https://aur.archlinux.org/packages/libgpg-error-git/ Using that library should solve the problem.

flick commented on 2014-06-10 02:34

I experience similar results to AdrianCohea, specifically with regards to "--export-secret-keys" and "--export-secret-subkeys". These options fail, causing the password prompt to open repeatedly before (key-ids changed to 0x):

> gpg --export-secret-keys me@me.com
gpg: key 0x: error receiving key from agent: Missing item in object - skipped
gpg: key 0x/0x: error receiving key from agent: Missing item in object - skipped
gpg: key 0x/0x: error receiving key from agent: Missing item in object - skipped
gpg: WARNING: nothing exported

These errors occur for all ECC secret-key material it seems. Appears to be a development problem, noted in the mailing list:

http://permalink.gmane.org/gmane.comp.encryption.gpg.user/37232

If one follows that thread Werner Koch is himself involved (although it seems he didn't anticipate the errors).

AdrianCohea commented on 2014-03-08 04:12

The Brainpool curves over P-256, P-384, and P-512 appear to be implemented. I was able to generate two keypairs over each curve.

I could clearsign with all keys I generated. I could verify messages signed by all keys I generated.

I could encrypt a message using all keys I generated with recipients being any one of the keys I generated, and I was able to have recipients using keys generated over curves different from the sender's key.

However, all decryption operations failed. I could not export any of the keys. I could not remove the keys from my keyring.

alphazo commented on 2014-02-02 21:19

I asked on gnupg mailing list regarding this issue and it appears that code for some of the ECC curves is just implemented yet. Stay tuned!

clpwn commented on 2014-02-02 11:54

Could not generate ECC key with a build done today, Feb 2.

# gpg --expert --key-gen

[Curve 25519]
gpg: writing self signature
gpg: signing failed: No such file or directory
gpg: make_keysig_packet failed: No such file or directory
Key generation failed: No such file or directory

[NIST P-384]
gpg: key_from_sexp failed: Invalid object
Key generation failed: Invalid object

alphazo commented on 2014-01-23 14:45

I had the same issue but compiling the git version today (Jan 23) worked and I could generate an ECC key.

AdrianCohea commented on 2014-01-18 21:09

libgcrypt is now version 1.6 in [core], and this package now builds, but it still doesn't work for me unfortunately. I can't do anything with the ECC functionality:

# ECDSA and ECDH Key Generation Testing
# gpg --expert --gen-key

# [Curve 25519] FAIL
gpg: agent_genkey failed: Invalid S-expression
Key generation failed: Invalid S-expression

# [NIST P-256] FAIL
gpg: key_from_sexp failed: Invalid object
Key generation failed: Invalid object

# [NIST P-384] FAIL
gpg: key_from_sexp failed: Invalid object
Key generation failed: Invalid object

# [NIST P-521] FAIL
gpg: key_from_sexp failed: Invalid object
Key generation failed: Invalid object

# [Brainpool P-256] FAIL
gpg: signing failed: Provided object is too short
gpg: make_keysig_packet failed: Provided object is too short
Key generation failed: Provided object is too short

# [Brainpool P-384] FAIL
gpg: signing failed: Provided object is too short
gpg: make_keysig_packet failed: Provided object is too short
Key generation failed: Provided object is too short

# [Brainpool P-512] FAIL
gpg: signing failed: Provided object is too short
gpg: make_keysig_packet failed: Provided object is too short
Key generation failed: Provided object is too short

AdrianCohea commented on 2013-12-06 03:12

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6286d01ba33b963be30fbb4fba6f35f1b05acd17

Regrettably, per the October 8th commit by Werner Koch, ECC is unsupported by GnuPG at this time. That might have explained why I was having such difficulty getting it to work. So I agree with your assessment that we'll just have to wait.
It seems that the GnuPG git branch relies on libgcrypt 1.6 (inasmuch as ./configure fails on it), but it is not stable yet. I am still unable to build libgcrypt from source in a way that doesn't break my system.

I'll let you know if I have a breakthrough or something, but I think we're probably waiting on Mr. Koch at this point.

Cheers!

alphazo commented on 2013-11-29 08:51

Thanks for the feedback. I tried to create a libcrypt-git package but found out that 1.6.0 is not available either from ftp://ftp.gnupg.org/gcrypt/libgcrypt/ or the git repository. I guess we have to wait a little bit.

AdrianCohea commented on 2013-11-29 05:16

Hello, I am having trouble building this package via makepkg -s command. The error comes from the build step on the ./configure file of gnupg. The problem is that libgcrypt is required to be version >=1.6.0, but libgcrypt version is 1.5.3 in core. I could not find a higher version in the Arch repos or AUR.

I propose changing depends to 'libgcrypt>=1.6'. Also, I think this implies a libgcrypt-git package might need to be created in the AUR. (Unfortunately, I don't know how to create packages yet.)

If I figure out how, I will try to make that contribution. Thanks!

AdrianCohea commented on 2013-11-29 05:15

Hello, I am having trouble building this package via makepkg -s command. The error comes from the build step on the ./configure file of gnupg. The problem is that libgcrypt is required to be version >=1.6.0, but libgcrypt version is 1.5.3 in core. I could not find a higher version in the Arch repos or AUR.

I propose changing depends to 'libgcrypt>=1.5'. Also, I think this implies a libgcrypt-git package might need to be created in the AUR. (Unfortunately, I don't know how to create packages yet.)

If I figure out how, I will try to make that contribution. Thanks!

abdo commented on 2013-11-03 22:56

Hi,

You can get rid of the automake-1.11 dependency by fixing configure.ac as follows:

sed -i 's/\[dist-bzip2 no-dist-gzip\]/\[dist-bzip2 no-dist-gzip serial-tests\]/' configure.ac

Also, is there any reason for depending on libassuan-git instead of libassuan from core?

alphazo commented on 2013-08-12 12:39

@Nothing4You, PKGBUILD has been updated. Thanks again.

Nothing4You commented on 2013-08-12 12:30

Also, please remove the replaces=() section. It's reserved for packages replacing obselete packages, not when providing different versions of the same package:
https://wiki.archlinux.org/index.php/PKGBUILD#replaces

Nothing4You commented on 2013-08-12 11:35

Maybe you could send a merge request to the mailing list ( https://mailman.archlinux.org/mailman/listinfo/aur-general ) so gnupg2-git gets merged into this?

alphazo commented on 2013-06-30 19:26

Please use gnupg-git instead that complies with pacman 4.1 PKGBUILD.

alphazo commented on 2013-06-30 19:26

Former package was called gnupg2-git. This one complies with PKGBUILD 4.1 rules. Thanks to @holos for the heavy cleanup.

alphazo commented on 2013-06-30 18:52

Thanks @holos for the heavy cleanup. I have two questions:
- Should I submit the package gnupg-git as you mentioned and then kill gnupg2-git?
- Why is pkgver=2.1.0beta3+220+g82c25e6 considering than it is much newer than the rather old 2.1beta3? What do the extra numbers stand for? When compiled and installed, "gnupg --version" outputs gpg (GnuPG) 2.1.0-beta220. Can version number (220) be automatically appended to the pkgver?

alphazo commented on 2013-06-30 18:39

Thanks @holos for the heavy cleanup. I have two questions:
- Should I submit the package gnupg-git as you mentioned and then kill gnupg2-git?
- Why is pkgver=2.1.0beta3+220+g82c25e6 considering than it is much newer than the rather old 2.1beta3? What do the extra numbers stand for?

alphazo commented on 2013-06-30 18:34

Thanks @holos for the heavy cleanup. I have two questions:
- Should I submit the package gnupg-git as you mentioned and then kill gnupg2-git?
- Why is pkgver=2.1.0beta3+220+g82c25e6 considering than it is much newer than the rather old 2.1beta3? What do the extra numbers stand for?

holos commented on 2013-06-30 18:05

pacman 4.1 PKGBUILD: http://ix.io/6qT

alphazo commented on 2013-06-27 07:10

Package has been updated and can now compile the latest git version again (rather than 2.1beta3).

alphazo commented on 2013-06-13 16:13

Thanks @nullren, all your fixes have been applied.

alphazo commented on 2013-06-13 14:55

I applied @nullren' suggestions and was able to compile it. Then I uploaded the PKGBUILD to AUR but if I try to compile it as a regular user like through Yaourt I get :

==> Starting make...
fatal: Not a git repository (or any parent up to mount point /tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Can you give it a try with the PKGBUILD I have posted on AUR?

nullren commented on 2013-05-24 06:20

not able to get this to build as is. changed the PKGBUILD a little bit to at least get something i could play with. needed to skip building docs because got an error there. also using the 2.1.0b3 tag.

--- PKGBUILD-orig 2013-05-23 22:56:02.320835635 -0700
+++ PKGBUILD 2013-05-23 23:15:46.305561006 -0700
@@ -12,7 +12,7 @@
license=('GPL')
url="http://www.gnupg.org/"
makedepends=('git' 'ghostscript' 'transfig')
-provides=("gnupg=${pkgver}")
+provides=("gnupg=${pkgver}" 'dirmngr')
conflicts=('gnupg2' 'gnupg' 'dirmngr')
replaces=('gnupg2' 'gnupg' 'dirmngr')
install=${pkgname}.install
@@ -28,7 +28,7 @@
msg "Connecting to GIT server...."

if [ -d $_gitname ] ; then
- cd $_gitname && git pull origin
+ cd $_gitname && git pull origin master
msg "The local files are updated."
else
git clone $_gitroot $_gitname
@@ -38,11 +38,13 @@
msg "Starting make..."

rm -rf "$srcdir/$_gitname-build"
+ git checkout gnupg-2.1.0beta3
git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build"
cd "$srcdir/$_gitname-build"
- read me
- ./autogen.sh --force
- ./configure --enable-maintainer-mode --prefix=/usr --libexecdir=/usr/lib/gnupg #$EXTRAOPTS
+ sed -i 's/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g' configure.ac
+ sed -i 's/doc, yes/doc, no/g' configure.ac
+ autoreconf -fiv --force
+ LIBS=-llber ./configure --enable-maintainer-mode --prefix=/usr --libexecdir=/usr/lib/gnupg #$EXTRAOPTS
make
}

@@ -55,5 +57,5 @@
# Remove conflicting man file
#rm -f ${pkgdir}/usr/share/man/man7/gnupg.7
ln -s gpg2 "${pkgdir}"/usr/bin/gpg
- ln -s gpg2.1.gz "${pkgdir}"/usr/share/man/man1/gpg.1.gz
+ #ln -s gpg2.1.gz "${pkgdir}"/usr/share/man/man1/gpg.1.gz
}

kang commented on 2013-03-13 07:09

remove "read me" ;)
sed -i 's/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g' configure.ac
sed -i 's/AM_PROG_MKDIR_P/AC_PROG_MKDIR_P/g' configure.ac
sed -i 's/\$\(mkdir_p\)/\$\(MKDIR_P\)/g' Makefile.am
autoreconf -fiv
instead of autogen

configure:
./configure \
`> --prefix=/usr \
`> --sysconfdir=/etc \
`> --libexecdir=/usr/lib/gnupg \
`> --enable-maintainer-mode \
`> --enable-symcryptrun \
`> --enable-gpgtar

alphazo commented on 2012-12-04 10:13

Thanks @kurz, PKGBUILD has been fixed.

kurz commented on 2012-11-04 00:40

This package requires these packages:
ghostscript, transfig

The reason for these strange dependecies seems to be the documentation that is build during make.