Future of CTM

Peter Wemm peter at wemm.org
Tue Sep 1 02:19:37 UTC 2015

On Tuesday, September 01, 2015 02:19:36 AM Julian H. Stacey wrote:
> Peter Wemm wrote:
> > I'm torn about how much to say in public, but there are a couple of
> > problems.
> ...
> Thanks for the analysis Peter.
> Before we go deeper, might there by chance be a frustrated SOC
> student whose project fizzled out & who might grasp CTM as a
> replacement/ top up project ?  Or students coming to end of summer
> project thinking "That was fun! What next to hack ?"
>   http://lists.freebsd.org/pipermail/soc-status/2015-August/date.html
> Perhaps not very likely but might be worth checking, as your post
> nicely describes the remit.

I have been trying to find an example of somebody who is actually verifying 
signatures before piping the messages to to ctm_rmail.  Even the procmailrc 
files that you publish at http://www.berklix.com/jhs/txt/ctms.html don't do 
signature checking.   From your own pages:
# JJLATER add a check for pgp signature, ref.
#       http://www.freebsd.org/handbook/synching.html#CTM

I did find one person who gpg verified the files he downloaded from ftp and 
posted about a corrupted file:
but even then it was a check to see if it was signed by *somebody*, rather 
than signed by the pgp key listed on the mailman info pages.   Even then, I'd 
bet he only did the gpg check as a diagnostic after the ctm run failed

I actually went looking for sample scripts for how to do this all safely and 
there was nothing obvious that turned up in likely searches.

There's some hints about how to do specific key verification here: 
but note the caveat about it needing to be a pubkey.gpg, not pubkey.asc.

I'd wager that few people (if anybody) are actually doing proper signing key 
verification of the email feed, and are therefore completely vulnerable to 
mischief.  Relying on the ctm-*@freebsd.org email list protection is *not* 
sufficient for this, but I would rather not talk about specifics just yet.

My biggest concern is that there is a vast quantity of published documentation 
advising people to do dangerous things, with the "oh by the way, and you 
probably should protect youself" aspect left as an exercise for the reader as 
an afterthought.

We can't retroactively recall all the bad advice so the only real option is to 
break the old dangerous ways and give corrected instructions on how to do it 
safely.  Make it so that you *need* the script that verifies signatures before 
decoding it and sending the delta to ctm_rmail.  It should be a choice to opt-
out of being safe, not something you have to research and implement yourself 
to opt-in.

That's what lead to my current thinking.  Would this effort be well spent?  I'm 
not convinced that it is, but I wouldn't stop somebody from doing the refresh 

I'm wondering whether to ask Stephen to switch away from detached signatures 
to help force the issue.  ie: replace the "ctm-*.nnnn.xz" + "ctm-
*.nnnn.xz.sig" files with "ctm-*.nnnn.xz.gpg" so that gpg is needed to decode 
it and at least have the signature status presented right there at decode 
time.  Likewise for the email deltas, sign and encode the deltas rather than 
clearsign - that forces it to be run through gpg in front of ctm_rmail.  A 
script to check that its signed by the *right* keys would need to be written 
and published for that to be worth anything though.  (Processing a ctm email 
packet with a valid signature by evilguy at terrorist.org is no safer than 
accepting unsigned things)

However, at the very least, I still want to move the ctm files from 
ftp://ftp.freebsd.org to something like ftp://ctm.freebsd.org because of the 
crawler issue.
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/ctm-users/attachments/20150831/5225b5c6/attachment.bin>

More information about the ctm-users mailing list