On Tue, 2006-11-07 at 12:26 -0500, Peter S. May <[EMAIL PROTECTED]> wrote:
> Henry Hertz Hobbit wrote:
> > Even if you do have an encrypted file that doesn't use these,
> > is there anything wrong with the file command returning the
> > answers given for the first six bytes of the file? I can't
> > find any information that they are used for any other kind
> > of file.
>
> A trivial example: Your specified headers all take the form
>
> 8c 0d 04 XX ...
>
> The first byte, 8c, or bin 10001100, represents an old-format packet,
> tag 3, length type 0 (one octet length). 0d is the length (13), 04 is
> the packet version (4), XX is the cipher algorithm, and the rest may vary.
>
> A 100% semantically identical packet could be formatted starting like this:
>
> c3 ff 00 00 00 0d 04 XX ...
>
> The point isn't that this is normal, but that it is _allowed_ and
> _could_ be normal in another implementation. A related (and more real)
> problem with this heuristic check is that no part of the standard
> requires the tag-3 packet to be the first packet in the file. Because
> of this, you really need to use a program that knows how to grok all of
> OpenPGP to do this sort of checking. It's really not that hard to
> design one after having read RFC 2440--I can think of a few ways I'd do
> it in Perl--but there's no point in writing a new program for checking
> the packets in a GnuPG-produced file when GnuPG already does the same thing.
>
> My two more cents -- PSM
It is a worthwhile and at a much higher value than two cents, but I
was NOT thinking of a new program. I was thinking of the magic number
and the "file" command. Evidently, OpenPGP is totally incompatible
with that and always will be. At least I can't see a way to make it
fit. If you can, be my guest. It would require enumerating all of the
possibilities and putting in ALL of them, but being careful you don't
clobber something else in the process.
This is now going beyond the scope of the initial request. It is just
that I have sat there looking at files before with a file command giving
back "data" not knowing what to do. In one case I was looking at
thousands of unknown files amidst Mechanical Engineering AutoCad files
and not knowing what they were. I removed them, but looking back on
the episode I had no way of knowing what went where anyway. Those files
also had no extension to give me a clue and the file command just gave
me back "data." I do suggest the following script instead (unless you
like one line PERL statements):
#!/bin/sh
# change the following if you have multiple versions
GPG=/usr/local/bin/gpg
echo
if test "$#" -eq 0
then
echo usage: "ciphertype <file-1 [file-2] ... >"
echo
exit 1
fi
for FILE in $*
do
if [ -s ${FILE} ]
then
echo ${FILE}
echo ---------------------------------
$GPG --list-packets --list-only ${FILE} 2>&1 | head -n 1
echo
fi
done
exit
-----
Here is the result of running it on some files:
$ ./ciphertype TOOMUCH.AES192 TOOMUCH.TWOFISH TOOMUCH
TOOMUCH.AES192
---------------------------------
gpg: AES192 encrypted data
TOOMUCH.TWOFISH
---------------------------------
gpg: TWOFISH encrypted data
TOOMUCH
---------------------------------
gpg: no valid OpenPGP data found.
Either that, or just run gpg with the -list-packets --list-only
and look at all of it. I suspect the assumption that the encryption
type always showing up on the first line may be a wrong one.
Therefore my advice is to just show all of it.
At least you know where I was heading - magic data in the magic
database for the file command to recognize the files. OpenPGP is
not the first, nor will they be the last to be incompatible. All
that does is reinforce the notion that you can't just throw the
file name extension out the door and try to depend on the file
command for everything. In this case the extension is needed. I
would prefer to have both the magic info / "date" command AND
the file name extension. It also may be nice to have just one
extension for all OpenPGP compliant programs. If that isn't
possible for what ever reason, people using PGP should not have
problems sending to GnuPG users or vice-versa. It seems like I
read about somebody having problems with it. The work-around
seemed to be a change in the config files. If that is the case,
then the config files should be changed, with a FAQ somewhere
on how to alter older configs for interoperability. This does
go to the subject in question; well I think it does.
At least now you know where I was headed. We just didn't make
it ...
Sorry
HHH
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
