View Issue Details

IDProjectCategoryView StatusLast Update
0000503filegeneralpublic2017-07-11 09:24
Assigned ToChristos Zoulas 
Status feedbackResolutionopen 
PlatformGentooOSLinuxOS Version
Product Version5.25 
Target VersionFixed in Version 
Summary0000503: GnuPG magic matches only some files
DescriptionGnuPG file magic apparently "lost" 0x8501 as a pattern some years ago, causing it to fail to match some .pgp / .gpg files created by GnuPG.

Some .pgp files created by GnuPG start with the bytes 0x8502, which magic/Magdir/gnu matches.

However, others begin with bytes 0x8501. It seems as though magic/Magdir/gnu _used_ to have a match for that, but it was changed from 0x8501 -> 0x8502 in 2008 or earlier.

From git blame gnu:

  aa04735e (Christos Zoulas 2008-03-07 19:51:01 +0000 31) # Note: magic.mime had 0x8501 for the next line instead of 0x8502
  aa04735e (Christos Zoulas 2008-03-07 19:51:01 +0000 32) 0 beshort 0x8502 GPG encrypted data

...The commit message for aa04735e is simply:

  commit aa04735e6d7286fdbce4d24cc665b7b27ccada38
  Author: Christos Zoulas <>
  Date: Fri Mar 7 19:51:01 2008 +0000

      bring them back so that we don't lose history and mess up other repositories.

So, I think that is a pseudo-commit, and I can't trace back further than that.

I'll attach a patch that adds 0x8501 in addition, although that might not be correct.

There might be a conflict if 0x8501 was simply added back - magic/Magdir/cisco matches 0x85011400 and 0x8501cb00. FWIW in the .pgp files I have that start with 0x8501, the third byte's first nibble is always zero (but I don't know if that's actually dependable, or just luck).
TagsNo tags attached.





2016-01-03 23:13


file-magic_gpg_8501.patch (525 bytes)
diff -u magic/Magdir/gnu.orig magic/Magdir/gnu
--- magic/Magdir/gnu.orig	2015-04-19 18:59:25.000000000 -0400
+++ magic/Magdir/gnu	2016-01-03 17:39:36.903142532 -0500
@@ -28,7 +28,7 @@
 # The format is very similar to pgp
 0	string          \001gpg                 GPG key trust database
 >4	byte            x                       version %d
-# Note: magic.mime had 0x8501 for the next line instead of 0x8502
+0	beshort		0x8501			GPG encrypted data
 0	beshort		0x8502			GPG encrypted data
 !:mime	text/PGP # encoding: data
Christos Zoulas

Christos Zoulas

2016-01-11 21:10

manager   ~0001173

and new ones have 0x8504... I am not sure what to do here. These is some mail from 1999 claiming that 0x8501 is OpenPGP...
Christos Zoulas

Christos Zoulas

2016-01-11 21:10

manager   ~0001174

is there a better way to detect them?
Antonio Ospite

Antonio Ospite

2017-07-11 09:24

reporter   ~0001546

The OpenPGP format is defined in RFC 4880 the header describes a sequence of packets, it does not use a fixed magic number.

For example a packet starting with:
00000000: 8501 0e03

means "a public key session packet of length 270 octets":

 0x85 --> Public key Session packet: bit 7 always set, bit 6 = 0 (old format), bits 5-2 = 1 (the packet type), bits 1-0 = 1 (the length type)
 0x010e --> packet length as little endian (270 octets), the field is two-octets long according to the length type 1 from above

 0x03 --> header length (opening tag 1 octet + 2 octets packet length)

So the fixed parts for this type of packet are octets 0 and 3

0: 0x85
3: 0x03

Octets 1 and 2 could not be used because they represent a variable length.

Keeping the same packet type and varying the length type we could derive other matching criteria:

for a 1 octet packet-length:
0: 0x84
2: 0x02

for a 4 octets packet length
0: 0x86
4: 0x05

Just for reference the gnupg code which parses the packets can be found here:

Note that I am not an expert on OpenPGP so my reasoning should be double checked :)

Some other matching criteria could be figured out varying the packet type but I don't know if being complete is libmagic mission.


Issue History

Date Modified Username Field Change
2016-01-03 23:13 hlein New Issue
2016-01-03 23:13 hlein File Added: file-magic_gpg_8501.patch
2016-01-11 21:10 Christos Zoulas Note Added: 0001173
2016-01-11 21:10 Christos Zoulas Assigned To => Christos Zoulas
2016-01-11 21:10 Christos Zoulas Status new => assigned
2016-01-11 21:10 Christos Zoulas Note Added: 0001174
2016-01-11 21:10 Christos Zoulas Status assigned => feedback
2017-07-11 09:24 Antonio Ospite Note Added: 0001546