Gnupg cannot handle extremely large keys on 32 bit Linux

[Charly Avital]

Ludwig Hügelschäfer wrote the following on 4/14/07 8:57 PM:
> Hi,
> 
> Charly Avital wrote on 14.04.2007 18:17 Uhr:
> 
>> *Therefore, there is a difference in results (Key ID and fpr) when the
>> keyblock is imported from Thunderbird+Enigmail (inside option), and when
>> the same keyblock is saved in a stand-along file that is imported via CLI*.
> 
> I just deleted the mentioned key from my keyring and reimported it using
> enigmails import function by clicking on "decrypt".
> 
> The key still identifies in the same way (0x2D879666, fingerprint
> BCA2 2448 8F7C 5646 A94A CE16 35BE A302 2D87 9666) afterwards.
> 
> Running TB 2.0.0.0pre (20070414) + Enigmail nightly 0.95b (20070409)
> 
> Which combination do you run?
> 
> Ludwig, cc'ing to the enigmail list.

Ludwig,

The most recent comments by Alexander Feigl point at the possibility
that gpg 2.0.3 is writing out the key incorrectly, in such a way that
gpg 1.4.7 does not recognize it.

Following that comment, I have already posted to the list that I am
running TB+Enigmail using gpg 2.0.3, and not gpg 1.4.7.

When I imported Alexander Feigl's large key, using the 'Decrypt' icon
(in TB 2.0.0.0 + Enigmail 0.95.0) or the OpenPGP option 'Sender's
key>Import Public Key (in TB 1.5.0.10 + Enigmail 0.94.3), I was using
gpg 2.0.3.

If indeed gpg 2.0.3 is writing out the key incorrectly, why it is doing so?

Just to remind what was happening:
- although TB+Enigmail/gpg 2.0.3 indicated that it was going to import a
key whose key ID was 2D879666, the key that was imported had the key ID
17CACAE3
- gpg --edit-key 2D879666 did not find such a key.
- gpg --edit-key 17CACAE3 found a key that showed a self signature made
  with 2D879666
- but when the key block was imported through CLI as a copy/paste/saved
  file (i.e. *not* via TB+Enigmail/gpg 2.0.3), the imported key was
  2D879666, without any mention of 17CACAE3.

Charly



Charly