Date: Mon, 07 Sep 2015 15:53:31 +0200 From: "Julian H. Stacey" <jhs@berklix.com> To: jvarner@gmail.com Cc: ctm-users@freebsd.org, Peter Wemm <peter@wemm.org> Subject: Re: Future of CTM Message-ID: <201509071354.t87DrVGV023261@fire.js.berklix.net> In-Reply-To: Your message "Sat, 05 Sep 2015 14:39:48 -0400." <201509051839.t85IdmIJ047044@eden.local>
next in thread | previous in thread | raw e-mail | index | archive | help
jvarner@gmail.com wrote:
> (apologies for not replying to previous emails; just subscribed to
> the list...)
> Peter Wemm wrote:
>
> > I have been trying to find an example of somebody who is actually
> > verifying signatures before piping the messages to ctm_rmail.
>
> I am such an example. The following recipe is the one I use (I
> use nmh, so for most people the pipe to rcvstore should be
> replaced with a simple mailbox or maildir delivery):
>
> :0
> * ^X-BeenThere: ctm-ports-cur@freebsd.org
> {
>
> :0 c: ${MAILDIR}/ctm-ports.${LOCKEXT}
> | rcvstore +ctm-ports -nounseen
>
> :0 c
> | gpg --no-default-keyring --keyring ${PMDIR}/ctm.key --verify
>
> :0 a
> | ctm_rmail -p ${HOME}/ctms/ports/pieces -d ${HOME}/ctms/ports/deltas -l ${PMDIR}/ctm.log
> }
Thanks for the example! I linked to it from http://ctm.berklix.org
I'm studying it, before upgrading my
http://berklix.com/~jhs/dots/.procmailrc.lists
http://berklix.com/~jhs/src/bsd/jhs/bin/local/mail/ctm-freebsd-ports-incoming
Suggestions:
Line 1 s/:0/:0 Hw/
Line 11 s/:0 a/:0 Haw/
H is by default, but appending 'w', So if connecting to internet
after days of absence, the 'w' should wait & thus reduce cpu load
if mail includes an incoming flood of ctms for different paths, eg
ports-cur src-9 src-10 etc that might otherwise run in parallel.
Nit picking: ;-) Instead of
* ^X-BeenThere: ctm-ports-cur@freebsd.org
I use
* ^Sender: (|owner\-)ctm-ports-cur(|\-bounces)@freebsd\.org
Sender might be formaly correct, long term stable ?
The 2nd ':' in ":0 c:" puzzled me.
man 5 procmailrc shows you invoke a lockfile.
No subsequent line uses your lock name, so
why specify it "${MAILDIR}/ctm-ports.${LOCKEXT}" ?
Is it so you know what to manually clear if something fails ?
Why do you need a lockfile ?
Is it gpg that needs the lockfile ? or would you have asserted a
lock even if not using gpg ? (My non gpg ctm works, but I see
bursts of errors which I guess are out of order mails, deltas or
pieces to deltas, that dont always immediately build to an
applicable ctm; is lockfile to mitigate that rather than particulary
for gpg ?)
man 5 procmailrc quotes opaquely:
"A locallockfile on the recipe that marks the start of a non-forking
nested block does not work as expected."
> Where ctm.key was produced by importing and exporting the ascii
> armored key from the mailman info page.
OK, There's a common key in both
http://lists.freebsd.org/mailman/listinfo/ctm-ports-cur
http://lists.freebsd.org/mailman/listinfo/ctm-src4
& it works for src-10 too, so presumably all. Extracted with vi.
mv ~/.gnupg ~/.gnupg.orig
gpg --import \
~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubkey.asc
mv ~/.gnupg/pubring.gpg \
~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp
rm -rf ~/.gnupg
mv .gnupg.orig .gnupg
In a Makefile (to test return result is 0 on success):
gpg --verify --no-default-keyring --keyring \
~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp \
/home/jhs/mail/CTM/36
cat ~/mail/CTM/36 | gpg --verify --no-default-keyring --keyring \
~/public_html/src/bsd/jhs/bin/local/mail/ctm-freebsd-gnupg-pubring.pgp \
/home/jhs/mail/CTM/36
Both exit OK with next command running, though I saw:
gpg: Good signature from "CTM Generator <ctm@freebsd.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs \
to the owner.
I tried briefly but failed to get rid of the warning with
gpg --edit-key trust 65FE4840
> I did check to confirm
> that modifying a signed CTM message will prevent ctm_rmail from
> running (gpg exits with an status of 2, which prevents the 'a'
> recipe from running).
Makefile errored both times when I tampered 1st char of delta or signature.
> I did not check to confirm that a
> mis-signed message would not verify, but my presumption is that
> the combination of --no-default-keyring and --keyring should
> prevent that verification from working since the only key in the
> specified keyring is the CTM signing key.
Sound reasonable. Thanks, & if you have time for questions above, great :-)
Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
Reply after previous text, like a play - Not before, which looses context.
Indent previous text with "> " Insert new lines before 80 chars.
Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201509071354.t87DrVGV023261>