Mika Suomalainen wrote:
> Jeremy T. Bouse wrote:
> > Mika Suomalainen wrote:
> > > Camaleón wrote:
> > > > Mika Suomalainen wrote:
> > > I am now asking this question for the third time, but now in separate
> > > thread.
That is the way to do it. I had not seen any of your previous
questions. If I kill a long rambling thread it will sweep in any
unrelated questions that were posted in that thread. Therefore if you
want people to read and make sense of your question you should post it
as a separate message in as clear of a problem statement as possible.
> > > As this list seems to be against GPG INLINE signatures, I have
PGP inline signatures are just annoying. They aren't fatal. They are
simply the very old way. Because they were annoying an improved way
was developed. Generally we think that using PGP/MIME is a superior
and more friendly way to go. I use PGP/MIME and think you should too.
> > > I am using PGP INLINE mainly, because of two reasons, which are
> > > 1. GPG INLINE is easier to verify manually. It's only
> > > copy-pasting the whole message to gpg.
If you are manually verifying messages I think that is too labor
intensive to do normally though the course of daily reading email.
There are hundreds of messages to this mailing list every day. Trying
to verify them manually would be too hard. Your mail user agent needs
to do this for you or it just won't happen when it needs to happen.
Therefore instead of worrying about doing it manually I would worry
about using and configuring your agent to do it for you.
Also when cutting and pasting you probably will not have the actual
contents of many messages. If the message is encoded with us-ascii it
might work fine. But if encoded in UTF-8 (or even 8859-1) due to
non-ascii characters then the message in the cut-n-paste will almost
certainly be different from the one encoded and will fail to verify.
So that isn't a good general purpose solution.
> > PGP/MIME just makes it easier for those that don't bother with the
> > signatures to ignore the attachment with the signature and not have to
> > deal with cutting it out in replies. The other issue I've seen with
> > inline vs PGP/MIME is that if the signature is not stripped out by
> > someone replying and including the signature in the quote it will
> > sometimes confuse the MUA. In most cases PGP/MIME won't have this issue
> > as the signature is a separate attachment and unless efforts are made to
> > include attachments in replies won't be included and even if it does it
> > still doesn't confuse the MUA.
Agreed to all.
> So if I was verifying my signature in that my latest message manually, I
> would need two files, which would be message and signature.asc
Yes, mostly. This is fully described in RFC 2015.
To manually verify your signature on a message you would need the
contents of the message body in one file. That must include the
encoding verbatim and it must include the content header.
Content-Type: text/plain; charset=us-ascii
This is a test message.
Including Camale=F3n's name to force quoted-printable encoding to
illustrate that it also must be part of the signed message.
That would be in one file. Note the character encoding and the
message header. This data must be a verbatim copy of the signed part
of the file.
In the other file would be the detached signature.
> and the verifying command would be "gpg --verify message
> signature.asc" (or were they swapped)?
Here is an example where I tried the above:
$ gpg --verify message.gpg.signature.asc message.txt
gpg: Signature made Sun 08 Apr 2012 05:40:55 PM MDT using DSA key ID C13650B6
gpg: Good signature from "Bob Proulx <email@example.com>"
> If we think that I am verifying the signature in my latest message,
> http://lists.debian.org/debian-user/2012/04/msg00748.html , how would I
> get the message part of it? Or is just copy-pasting and saving it
> enough? (Or is it impossible?
You need the original message. Being able to see how the message is
displayed is not enough due to character encoding changing the
underlying data. This is why cutting and pasting isn't a good thing
even in the inline case.