[Alpine-info] Extensions needed for proper crypto support.
Steven W. Orr
steveo at syslang.net
Sat Jun 6 10:00:36 PDT 2009
I've been reading up on the crypto aspects as they relate to alpine. I
understand pretty much how the PGP/GPG side operates. I think I have a
sense of the S/MIME side of things as well. After having gone through it
all, feel like I have a definite preference to using GPG over S/MIME. But
I see a number of messages that have GPG signature attachments and the
support needed to verify these messages is not good. And verifying is less
useful if I can't also send a message with an attached signature.
What seems to be missing is the ability to easily create filters for
dealing with GPG in the context of an attached signature.
I downloaded topal and built that to give it a spin. It seemed to be the
only thing out there that supports attached signatures. It built fine, I
configured it the way it was specified. Things didn't work for me. I can
go into detail about what didn't work, and I *would* like to take a shot
at finding out why I'm having problems, but I'd like to ask about the
issues of display_filters and sending_filters. Please understand that the
reason that topal is as complex as it is is partially because of the lack
of support from alpine that I'm describing below, which necessitates the
creation of a patch to the src code that as yet is not supported by
The problem that I see with alpine is that the Command and Trigger
Modifying Tokens are inadequate. I'm not proposing a full spec for how to
fix the problem, but let me offer a suggestion for an improvement. Note
that my suggestion is probably not a full and proper design for how to
make a more general interface for sending and display filters.
Let's pretend that I want to write a simple display filter that will
perform the verification of a pgp signed message where the signature is
attached. I really can't do this in alpine. One way that I might be able
to do something like this is to have a new token in the display feature
that allows a filter to have access to the attachments. A possible
implementation might be that the new token, _ATTACHED_, would expand to
the list of temporary filenames that would each contain a copy of the
attachments in the message. The files would only be created if the
display_filter made a reference to the _ATTACHED_ token. Then the display
filter could cycle through the list, looking for a MIME type of
application/pgp or if the attachments name is signature.asc (or whatever
the filter is supposed to do) and do the job.
>From the sending filter side, we already have the ability to create an
output file which would be the signature but there is no way to cause that
resulting file to be added to the list of attachments. I know I'm punting
here, but if we created a new token called _ATTACH_ then alpine could look
at that filename and attach it to the outgoing message if the file exists
after the filter returns a successful status.
Am I intriguing people with this idea or am I way off base? Does someone
have a better suggestion? I'd like to help but I need to know how and
where to start.
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
More information about the Alpine-info