On Tue, 10 Jan 2012, Andreas Schulze wrote:
> I just found an other string "dkim-filter", patch attached.
Applied; thanks.
> And I like to suggest a discussion about dividing signer and verifier in
> two different binaries. I have more and more installation where opendkim
> act as signer *or* as verifier. Would it be practicable to split
> opendkim?
>
> + smaller memory footprint
I don't think that's strictly true. Not that much code gets removed when
you tear out one mode or the other. Most of the code base is
infrastructure in the libraries or things in the filter needed by both
modes, and it's hard to be selective about what parts of those get
included.
> + reduced complexity
> + less librarie dependencies
I think these are a function of which features you enable at compile-time,
coupled with the general architecture of autoconf and automake. I can go
some steps toward fixing this, but it's limited.
> + increased security
How so?
> - costs of coderewrite
This is a pretty huge point. Really the only code that would be separated
out would be:
- config values that apply to one but not the other
- signature generation in one, signature post-verify analysis in the other
- matching Lua functions
Most or all of the dependent library stuff has already been
compartmentalized. That would leave 60% or more duplicated code, because
the only places the two modes differ is in EOH processing (where the sign
vs. verify decision is made) and in EOM processing (where signatures are
attached and/or verified signatures are analyzed).
You would also sacrifice completely the re-signing optimization, where the
hashes computed inbound are recycled outbound. This might be a big deal
for some installations when, for example, MLMs become more DKIM-aware.
But all that said, it's worth considering at some point, especially if an
easy path toward such a separation reveals itself.
-MSK
Received on Tue Jan 10 2012 - 21:02:38 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:33:30 PST