Werner Koch writes: > On Tue, 17 Sep 2019 11:09, m...@halfdog.net said: > >> Therefore some exports (or copies of old secring.gpg) just >> do no include the public key, otherwise import would be trivial. > > Nope. It is not possible to create an OpenPGP secret keyblok > without the public key parts.
There must have been some easy/likely pathes to reach such a state regarding the number people searching for such a solution, e.g. checking only 'gpg "secret key without public key"', which is only one possible error message in such an incomplete-private-key scenario. One cause seems loss of pubring.gpg (or zeroing out, not replaying it from backup, ...) as documented in [0]. Others might be related only to the missing user_id or sig packets, maybe because these expired during the whole timeline. >> As the key causing me problems was very old, I do not have >> the software at hand that was used to create it, nor it is >> clear > > We removed v3 key support in 2.1 for security reasons. You > need to use gpg 1.4 wo work with these keys. At least my problematic keys were already v4 ones, I cannot say for sure for similar problem reports on the net, they might have used v3s. >> https://unix.stackexchange.com/questions/267844/gpg-secret-key-not-available-when-sec-pub-key-are-in-keyring > > That is about the old 2.0 (or a 1.4) version which is end-of-life > and did not allow to merge secret and public keyblocks. That > might be the problem at hand. 2.2 fixes this problem by not > trying to sync a secring.gpg and pubring.gpg. The secring.gpg > is actually not anymore used but the secret parts of the key > have been moved to the gpg-agent's secret key store. As the problem might be related to long-time compatibility of gpg, most of the reports and possible solutions are quite old and may affect outdated software. As it seems quite important for some users to decrypt old data also years after creating it and that seems to fail sometimes, the probability to have an outdated version in the whole scenario is nearly 100%. Hence I did not spend much time to figure out how the problem happened over the years, just took it as granted and tried to find an easy fix - not recreating all the frames with some Python opengpg framework as one poster suggested. hd [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640241 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
