On 09/26/2012 12:32 PM, Murray S. Kucherawy wrote:
> On Wed, 26 Sep 2012, Ken Murchison wrote:
>> In the iSchedule case, its usually just a different URL on the same
>> host, but we can't just use the same sig header for the new request,
>> because the http tag won't match the new URL. My current code runs
>> through the entire process of creating a DKIM handle, adding the http
>> tag, processing the message, and generating the sig header for the new
>> request. This seems like a waste, as none of the headers (other than
>> the sig header), the body, or the body hash change.
>>
>> Is there a way that I can just change the http tag and reuse the same
>> signing handle to generate the updates sig header?
>
> Not with the current APIs. The opendkim filter right now would just
> establilsh two signing handles and feed the full set of data to both of
> them, with fields altered as appropriate.
>
>> Can dkim_resign() be massaged so that it can handle a signing handle
>> as the "old" handle?
>>
>> Can the original signing handle be "reset" so that the same
>> parameters, header cache, and body hash can be reused?
>>
>> dkim_add_xtag() could be massaged so that rather than throwing an
>> error when a duplicate xtag is seen, that it just overwrites the
>> content for the xtag.
>
> All of those are possible. The last two are probably the least impactful.
>
> I'll try to take a look at these options soon, but for now you do have
> the existing (duplicate, sub-optimal) method.
Correct, I have the functionality that I need.
Optimally, the signature would only be calculated when the application
calls dkim_getsighdr(). I see that its really calculated in
dkim_eom_sign(), which is what causes the major problem in reusing the
signing handle. I haven't looked at all of the logic to see why its
done that way, and what, if anything, would break if its pulled out of
there.
I can certainly fix the dkim_add_xtag() issue since its trivial. If you
want to direct me with some thoughts on the reusing the signing handle,
I would be willing to work on the code.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Received on Wed Sep 26 2012 - 16:42:57 PST