Future of CTM
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 ?"
> 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.
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 email@example.com 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
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
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
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...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the ctm-users