This should now be fixed in stable releases also in this update:
http://www.ubuntu.com/usn/usn-2554-1/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/1371766
Title:
Latest
This bug was fixed in the package gnupg - 1.4.18-6ubuntu1
---
gnupg (1.4.18-6ubuntu1) vivid; urgency=medium
* Resynchronise with Debian (LP: #1371766). Remaining changes:
- Disable mlock() test since it fails with ulimit 0 (on buildds).
- Set gpg (or gpg2) and gpgsm to use
** Changed in: gnupg (Debian)
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/1371766
Title:
Latest CVE-2014-5270 patch breaks ElGamal keys
Small update on the upstream issue I opened:
there is no way for GnuPG to support keys larger than 4k, although it's a
one-line patch. Please read the explanation in the link above.
I see two possible outcomes of this:
1) Just add a tiny patch which increase the secure memory to 128k, keep the
Bug opened:
https://bugs.g10code.com/gnupg/issue1732
** Bug watch added: GnuPG Bugs #1732
https://bugs.g10code.com/gnupg/issue1732
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
So, what's the deal with this?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/1371766
Title:
Latest CVE-2014-5270 patch breaks ElGamal keys of 16k
Status in “gnupg”
Please report this issue to the gnupg project at the following link, and
link the bug here:
https://bugs.g10code.com/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/1371766
...and it works. So, the problem is:
with the latest patch, the usual amount of secure memory (32768 bytes) is not
sufficient anymore. I just raised it to another arbitrary number (262144) and
it works fine.
Wouldn't it be sufficient to just raise secmem_init() in g10/gpg.c ?
--
You received
This is an upstream decision. In fact, they've now limited the size of
ElGamal keys to 4096 with the following commit:
http://git.gnupg.org/cgi-
bin/gitweb.cgi?p=gnupg.git;a=commit;h=aae7ec516b79e20938c56fd48fc0bc9d2116426c
Another relevant Debian bug: https://bugs.debian.org/cgi-
Well, the first commit just limits the key generation size. I'm fine with
that, but breaking GnuPG for _currently_ used keys it's a totally different
matter. I have been using this key for a while (let's say, a year and a half?)
without any problems.
This, for me, is clearly a regression.
The
Ciaby, perhaps try raising your max locked memory resource limit. See
setrlimit(2) and limits.conf(5) manpages for details.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
** Changed in: gnupg (Debian)
Status: Unknown = New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/1371766
Title:
Latest CVE-2014-5270 patch breaks ElGamal keys of
These are the current limits:
ciaby@lila:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 23805
max locked memory
13 matches
Mail list logo
