Future of CTM

[Julian H. Stacey]

jvarner at 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 at 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 at 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 at 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.