Identify a gpg file

Hans-Christoph Steiner hans at guardianproject.info
Thu Jul 25 20:36:30 CEST 2013



On 07/25/2013 12:05 PM, Werner Koch wrote:
> On Thu, 25 Jul 2013 17:05, hans at guardianproject.info said:
> 
>> "gpg2 --import" or "gpg2 --decrypt".  I want GPG on Android to be able to
>> receive a .gpg file and then do the right thing without the user having to
>> tell GPG that the .gpg file is keys, encrypted content, a signed file, etc.
> 
> You are right.  GPGME needs to know what it shall do.  Although gpg
> usually does the right thing, it does not automatically import files -
> you need to use --import.  I would consider the latter a feature.

I agree it should not automatically import keys in a .gpg.  I think if it
detects that the .gpg file contains keys, it should present the user with a
summary of the contents and ask the user whether she wants to import them.


> Back to GPGME.  I recall that for some projects we often talked about
> your needs but eventually get around it with simple methods.  For
> example GpgEX (the Windows file explorer extension) uses a list of
> suffixes to decide whether to show sign/encrypt or verify/decrypt at the
> top of the context menu.  This more or less works but is not very
> comfortable.  GPA (src/filetype.c) and GpgOL have code to distinguish
> between CMS/X.509 and OpenPGP but that is all we have.
> 
> I agree that a generic function in GPGME to do what file(1) does for
> OpenPGP files would be quite useful.  Unfortunately we have not yet had the
> time to implement it.   src/filetype.c along with a list of commonly
> used suffixes might be a start, though.

I think the best and easiest solution for this is using explicit file
extensions by default everywhere.  So things like .pkr for public keys, .skr
for private keys, .sig for binary detach-sign, etc.  Any specific format that
does not already have its own file extension should get a new one.  Then gpg
should avoid adding the ambiguous extensions, like .gpg, .pgp, .asc, but
continue to accept them.

I could probably find some time in the not-too-distant future to implement this.

As a side note, the file-5.14 detection could use some improvement.  Its not
detecting keys and detached signatures as something distinct.  It seems that
the logic in gpa/src/filetype.c could be contributed to file.

$ for f in *.gpg *.sig *skr *pkr; do file $f;done
icon-encrypted-not-signed.png.gpg: data
icon.png.gpg: data
pubring.gpg: GPG key public ring
secret.gpg: data
secring.gpg: data
trustdb.gpg: GPG key trust database version 3
icon.png.sig: data
public-keys.pkr.sig: data
secret-keys.skr: data
public-keys.pkr: data

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 939 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130725/88d40439/attachment.sig>


More information about the Gnupg-devel mailing list