Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
- To: email@example.com
- Cc: firstname.lastname@example.org
- Subject: Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
- From: Manoj Srivastava <email@example.com>
- Date: Wed, 04 Apr 2007 02:21:48 -0500
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20070401220218.68e3ff59@localhost> ("Michal Čihař"'s message of "Sun\, 1 Apr 2007 22\:02\:18 +0200")
- References: <email@example.com> <Pine.LNX.4.62.0703280739010.29424@wr-linux02> <1175061383.4086.27.camel@localhost> <20070328093110.163ae03c@localhost> <firstname.lastname@example.org> <20070329100019.324dd431@localhost> <20070329192328.GA16156@roeckx.be> <20070330092338.60f7bb56@localhost> <email@example.com> <20070401181138.2a8c14c5@localhost> <firstname.lastname@example.org> <20070401220218.68e3ff59@localhost>
On Sun, 1 Apr 2007 22:02:18 +0200, Michal Čihař <email@example.com> said:
> Maybe I read RFC 3156 wrong, but I think it says exactly what I
> 6.1. RFC 1847 Encapsulation
> In , it is stated that the data is first signed as a
> multipart/signature body, and then encrypted to form the final
> multipart/encrypted body. This is most useful for standard MIME-
> compliant message forwarding.
No, you were quite correct; I had zone on RFC 1847
Encapsulation while writing up dvt-gpg. Mind you, implementing this
was icky, since this breaks the nice little work-flow where first we do
mime decoding, and then gpg verifications; now devotee has to decrypt
the mail message, note that there did not seem to be any signatures
on the message, run the mime parser on the newly decrupted body, see
if there are exactly two parts with the proper mime encoding, save
the body and the signature, and then run gpg again over the new body
and sig, and properly bubble up any errors at any stage of the
No wonder people tried to warn me away from implementing my
own mail handling and mime and gpg parsing when I started thinking
about writing devotee.
I added all this icky code to devotee, and now devotee is
indeed fully compliant with RFC 3156.
Anyway, there were 10 ballots which could have been affected,
so I re-ran these ballots through devotee.
9 failed to verify the sig.
One of your ballots (msg00250) did pass the gpg check -- but
you must have voted with the same ballot, since devotee says:
Failure: The signature on the message, though valid, has been seen
before. This could be a potential replay attack
So, after all this, no rejected ballot has been accepted --
and indeed, 9 of the 10 were correctly rejected in the first place.
But I'm happy to say that any RFC 3156 compliant message
should now be correctly interpreted by devotee.
Authors (and perhaps columnists) eventually rise to the top of
whatever depths they were once able to plumb. -- Stanley Kaufman
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C