Mailing List Archive: silent mode; signing headers

silent mode; signing headers

Jun 17, 1998, 7:59 PM

Post #1 of 3 (652 views)

There are two features I would really like to see in G10.

First, a `silent mode' for verifying signatures. In this mode g10
reads a file and indicates whether the signature is good or not by
its exit status, but produces no output. Exit codes should
distinguish good sig, bad sig, unknown key, no sig, and program
failure. This feature is for checking signatures from inside some
automated system, such as a netnews server.

Second, it would be nice to be able to sign some of the headers of a
message as well as its content. This allows the recipient to check
that the envelope wasn't tampered with. At least Date, From, To,
Subject, Sender, and Reply-To should be signable for email messages;
in Usenet one would like to sign Control and Approved (if present)
also. There's an existing semistandard for this, the X-PGP-Sig and
X-Signed-Headers headers used by pgpverify.

zw

p.s. --verify is documented to not print the contents of the file
verified, but in 0.2.19 it does (at least with --clearsign
signatures).

Re: silent mode; signing headers [ In reply to ]

wk at isil

Jun 18, 1998, 12:40 AM

Post #2 of 3 (633 views)

Permalink

Zack Weinberg <zack@rabi.phys.columbia.edu> writes:

> First, a `silent mode' for verifying signatures. In this mode g10
> reads a file and indicates whether the signature is good or not by
> its exit status, but produces no output. Exit codes should

that should be possible with gpg --batch --verify. I can make sure
that you get these exit codes:
0 - okay
1 - can't check signature (unknown algorithm, no public key)
>= 2 - program failure.
I don't think that it is a good idea to use exit codes as this is
complicated if gnupg is used in a pipe (yes, bash 2 has a facility for
this). A better way is to parse the output of gpg: when used with
--status-fd 2 you will see lines
[GNUPG:] keyword more stuff
which are quite easy to parse.

> Second, it would be nice to be able to sign some of the headers of a
> message as well as its content. This allows the recipient to check

I do not think gnupg should do this; it is MUA relatated stuff. I'd
suggest do invent some MIME encoding for this. A way to do this is
to bring the headers in a standard format (MTA may rewrite them), hash
them and put the hashvalue as printable string into the contents of
the message (or simply copy the headers into the contents).

> p.s. --verify is documented to not print the contents of the file
> verified, but in 0.2.19 it does (at least with --clearsign

Noted, thanks.

Werner

Re: silent mode; signing headers [ In reply to ]

zack at rabi

Jun 18, 1998, 12:14 PM

Post #3 of 3 (630 views)

Permalink

On Thu, 18 Jun 1998 09:40:40 +0200, Werner Koch wrote:
>Zack Weinberg <zack@rabi.phys.columbia.edu> writes:
>
>> First, a `silent mode' for verifying signatures. In this mode g10
>> reads a file and indicates whether the signature is good or not by
>> its exit status, but produces no output. Exit codes should
>
>that should be possible with gpg --batch --verify. I can make sure
>that you get these exit codes:
> 0 - okay
> 1 - can't check signature (unknown algorithm, no public key)
> >= 2 - program failure.
>I don't think that it is a good idea to use exit codes as this is
>complicated if gnupg is used in a pipe (yes, bash 2 has a facility for
>this). A better way is to parse the output of gpg: when used with
>--status-fd 2 you will see lines
>[GNUPG:] keyword more stuff
>which are quite easy to parse.

That I could live with, but INN's verification mechanism wants it all
in the exit codes. I was hoping to be able to eliminate the wrapper
script. On the other hand, as you say

>> Second, it would be nice to be able to sign some of the headers of a
>> message as well as its content. This allows the recipient to check
>
>I do not think gnupg should do this; it is MUA relatated stuff. I'd
>suggest do invent some MIME encoding for this. A way to do this is
>to bring the headers in a standard format (MTA may rewrite them), hash
>them and put the hashvalue as printable string into the contents of
>the message (or simply copy the headers into the contents).

this would require me to keep the wrapper anyway, and I do think this
is reasonable.

zw