View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000503||file||general||public||2016-01-03 23:13||2017-07-11 09:24|
|Assigned To||Christos Zoulas|
|Target Version||Fixed in Version|
|Summary||0000503: GnuPG magic matches only some files|
|Description||GnuPG 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:
Author: Christos Zoulas <firstname.lastname@example.org>
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).
|Tags||No tags attached.|
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
file-magic_gpg_8501.patch (525 bytes)
|and new ones have 0x8504... I am not sure what to do here. These is some mail from 1999 claiming that 0x8501 is OpenPGP...|
|is there a better way to detect them?|
The OpenPGP format is defined in RFC 4880 https://tools.ietf.org/html/rfc4880#section-4 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
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:
for a 4 octets packet length
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.
|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|