Re: [courier-users] Standard Signatures

Peter Burden wrote:
> On 23/04/2008, Gordon Messmer <yinyang@eburg.com> wrote:
>
>> Peter Burden wrote:
>> > Since then, I've cut some code and have a working signing filter.
>> > If anybody wants to have a look and let me know about any bugs
>> > (obvious or subtle), source code is at
>> > http://web.ptwol.net/sigfilter/sigfilter.c
>> > It's in standard C and uses a MySQL database.
>> > There are some explanations of how it works in the source code.
>> >
>>
>>
>> I don't like criticizing you twice in one evening, but there are some
>> pretty serious problems with this code:
>>
>> * Filter is threaded, but you're not taking the required steps to make
>> mysql thread-safe:
>> http://dev.mysql.com/doc/refman/5.0/...d-clients.html
>>
>
> Since the filter doesn't try and share a connection between threads my
> interpretation of the reference is that, provided you link against
> libmysqlclient_r, you don't need to do anything further special.
>

I don't think that's correct. I could be wrong, since I rarely use the
mysql C API (I'm actually not a big fan of MySQL in general), but it
looks to me like you at *least* need to call mysql_library_init() before
you create any threads. I think you also need to call
mysql_thread_end() to avoid memory leaks. You should check with the
mysql list for further confirmation, but I wouldn't trust this code to
be thread safe as it is.

There's also a minor risk that "tp" will be changed in realmode before
it's copied in procmsg. You should pass that functions args by value
only. Either just pass fd as an arg, or allocate the memory in the
realmode function and pass the address to procmsg.

Unrelated: I'm not confident that t->signature will have enough space if
the field values are much longer than the names from the template. It's
kind of hard to tell how that works, but it looks like a likely buffer
overflow to me.

>> * Filter uses global variables with no mutex protection. See above.
>>
>
> The global variables that are accessed by the threads are only
> read, not written to. They are set up as part of the initialisation, the
> filter does not start listening or launching threads until initialisation
> is complete. I have never found any need for mutexes to control
> access to read-only data. Read-write is, of course, a completely
> different matter.
>

Yeah... I'm not sure why I thought gettemplate was called by procmsg.

>> * Filter seems to treat any "AUTH: LOGIN" as if it were a header
>> * AUTH header won't always say "AUTH: LOGIN"
>>
>
> Fair comment. For my server installation we currently only use LOGIN
> authentication but this should be easy to fix.
>
> I don't think I'm treating AUTH:LOGIN as if it were a header, based
> on my observation of what Courier seems to do, it appears that AUTH:LOGIN
> is interposed amongst the parts of the "Received:" header - usually on
> a continuation line.
>
> I would accept the criticism that the AUTH:LOGIN recognition code
> doesn't really understand headers and, worse, carries on looking for
> AUTH:LOGIN in the message body if it didn't find it in the headers.
>

That's what I meant. :)

You should be looking for the first Received header, and examining its
contents. Stop there.

> Is there a definitive statement on the location/syntax of "AUTH:LOGIN" anywhere?
> I can't see it in RFC2822/2821.
>

I'm not sure. I think I used Courier's code as a reference.

>> * Finally, and most importantly IMO, you append a plaintext signature to
>> any text part. It looks like this includes attached files. Regardless,
>> by modifying the existing text parts, you invalidate PGP and SMIME
>> signatures, which is bad.
>>
>
> The point about PGP and SMIME is a fair comment, but I find it difficult
> to imagine a signing system that would both satisfy end user requirements
> and not break such things.
>

I believe that it's possible to encapsulate the original, signed message
in a new MIME message, and add the signature as a text/plain part at the
end.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757...un.com/javaone
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users