[Alpine-info] Extensions needed for proper crypto support.

[Steven W. Orr]

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 
alpine.

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