Package Details: gnupg-largekeys 2.3.0-1

Git Clone URL: https://aur.archlinux.org/gnupg-largekeys.git (read-only, click to copy)
Package Base: gnupg-largekeys
Description: Complete and free implementation of the OpenPGP standard
Upstream URL: https://www.gnupg.org/
Keywords: gpg
Licenses: GPL
Conflicts: gnupg, gnupg2
Provides: gnupg, gnupg2
Replaces: gnupg, gnupg2
Submitter: ido
Maintainer: xgjmibzr
Last Packager: xgjmibzr
Votes: 4
Popularity: 0.000000
First Submitted: 2013-11-04 02:45 (UTC)
Last Updated: 2021-04-10 21:38 (UTC)

Required by (196)

Sources (4)

Latest Comments

ido commented on 2017-03-15 13:59 (UTC)

This package tracks gnupg stable, not modern.

ido commented on 2016-07-17 16:20 (UTC)

I have disowned this package. If anyone wants to take it over and upgrade to 2.0.30, please feel free.

webdawg commented on 2016-04-24 22:17 (UTC)

:: gnupg-largekeys: requires dirmngr

ido commented on 2016-02-15 14:33 (UTC)

2.0.29 is the latest upstream stable version. This package tracks upstream stable, not upstream modern. Please do not flag it as out of date.

ido commented on 2015-04-18 03:01 (UTC)

GnuPG 2.1.x is the NON-STABLE "modern" distribution. It is not yet recommended for general use, as far as I know. I've uploaded 2.0.27, the latest upstream stable. Enjoy. As a reminder, please submit pull requests to https://github.com/ido/packages-archlinux ...

reki commented on 2015-03-01 15:08 (UTC)

I didn't see there already was a package for large keys. I made a patch for 2.1.2 --enable-large-rsa will allow RSA keys up to 16k. I didn't touch other algorithms since I don't even know if it's even possible to have bigger keys t

korgan1983 commented on 2014-12-19 14:38 (UTC)

Hi Ido, thanks for feedback! I will keep my eyes open and contact you, if I see any patch for 2.1 and at this point also thanks in advance for working on update for 2.1

ido commented on 2014-12-18 16:54 (UTC)

This package will stay with 2.0.x for a little while longer - 2.1.x is not yet marked stable. (I expect this to happen within a few weeks; if it takes too much longer we'll go back to tracking the gnupg package more closely.) I am still squishing a few bugs in the patch for 2.1.x (currently 2.1.1), and only have a few minutes a week to work on that, so if you know of an existing working 2.1.x large keys patch out in the wild, please point me to it and I will test that instead of making one myself.

korgan1983 commented on 2014-12-18 11:44 (UTC)

Hi, are you planning to update to 2.1?

ido commented on 2014-08-31 17:10 (UTC)

Updated gnupg to 2.0.26. Fixed GitHub issue #27.

ido commented on 2014-07-05 23:07 (UTC)

Bumped to 2.0.25. @vwyodajl - thank you for the comment.

vwyodajl commented on 2014-07-05 19:25 (UTC)

2.0.24 CVE https://mailman.archlinux.org/pipermail/arch-security/2014-June/000083.html pkgver bump breaks patch.

ido commented on 2014-01-19 17:51 (UTC)

Release bumped to match upstream. libgcrypt update to 1.6.0 requires a rebuild of this package to link against the new version (libgcrypt.so.20 vs. libgcrypt.so.11). Pacman will break if this isn't upgraded at the same time as libgcrypt. If pacman is complaining about "GPGME error: invalid crypto engine" when trying to upgrade/install packages, and when you try running "gpg --version" you get an error that it couldn't find libgcrypt.so.11 but libgcrypt.so.20 exists in /usr/lib, then that error is probably because you upgraded libgcrypt without rebuilding gnupg. So, just run makepkg or "yaourt -Sa gnupg-largekeys" again and it should be resolved.

vwyodajl commented on 2013-11-18 00:21 (UTC)

That makes sense. Thank you for explaining that to me I was confused as to why it only happened with the larger keys.

ido commented on 2013-11-17 21:36 (UTC)

vwyodajl - if you are referring to this FAQ entry from the GnuPG documentation: http://www.gnupg.org/faq/GnuPG-FAQ.html#why-do-i-get-gpg_warning_using_insecure_memory By setuid'ing (chmod u+s) the gpg2 binary, you are giving it many more capabilities/permissions than you need to. This violates the principle of least privilege, so most distributions (including Arch) do not setuid the gpg binary. The gnupg-largekeys PKGBUILD is identical to the Arch PKGBUILD except for the largekeys patch, which does not affect gpg's permissions or capability to lock memory, however the larger key size may require that more pages be locked into memory... A less invasive fix would be to allow gpg2 to lock more memory by modifying /etc/security/limits.conf, setting the appropriate ulimit setting, or any number of other ways. This is something I will mark as "wontfix" since it is a matter of preference for the user whether they modify their limits.conf, set ulimits, use a helper/wrapper program, etc.

vwyodajl commented on 2013-11-14 18:24 (UTC)

I get the following warning once I install this. Does not appear with the Arch package Warning: using insecure memory! Some googling gave me that it is the suid of the binary? http://www.ibm.com/developerworks/aix/library/au-gnupg/ I did try just to see what would happen and it does get rid of the warning. chmod 4755 gpg Just curious why the Arch package does not give me this warning but once this is installed I get it? Is the suid approach even applicable still, everything seems mostly old relating this warning.

ido commented on 2013-11-04 02:50 (UTC)

NOTE: To request changes to this package, please submit a pull request to the GitHub repository at https://github.com/ido/packages-archlinux Otherwise, open a GitHub issue. Thank you! -Ido This package's PKGBUILD and its corresponding commits in the above git repository are signed with key fingerprint: pub 4096R/2389BB21 2011-10-08 Key fingerprint = F353 09F4 93E8 F6D3 3973 5A70 A669 D000 2389 BB21 To import that key, try gpg --keyserver pgp.mit.edu --recv-keys 2389BB21