On Fri, Feb 19, 2010 at 10:20:19AM -0800, Murray S. Kucherawy <msk_at_blackops.org> wrote:
> On Fri, 19 Feb 2010, Mike Markley wrote:
> >So realistically, my KeyTable will be passed the... domain or email
> >address in $d? And should return one attribute? And the SigningTable
> >will be passed the contents of THAT attribute (again in $d) and should
> >return three attributes?
>
> The other way 'round:
>
> The SigningTable will be passed first the full user_at_host.domain from the
> From: header field, then the host.domain, then user_at_.domain, then .domain,
> then just "*". On the first match (or if MultipleSignatures is set, on
> each match), the returned value is expected to be the name of a key. That
> key is then passed to a KeyTable query, which is expected to return a
> three-part value containing the signing domain, the signing selector, and
> either a PEM-formatted private key or the path to a file containing a
> PEM-formatted private key. Then that tuple will be used to generate what
> the filter calls a "signing request" that results in a signature being
> added to the message.
Okay, that's working a little better. As a heads-up, the filter
currently dies with a failed assert() if it gets fewer attributes than
expected back from an LDAP query. Since I had this backwards, I had my
KeyTable returning only one attribute:
lt-opendkim: getvalues.c:98: ldap_get_values_len: Assertion `target != ((void *)0)' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1231037520 (LWP 13606)]
0xb7c9d947 in raise () from /lib/tls/libc.so.6
(gdb)
(gdb) bt
#0 0xb7c9d947 in raise () from /lib/tls/libc.so.6
#1 0xb7c9f0c9 in abort () from /lib/tls/libc.so.6
#2 0xb7c9705f in __assert_fail () from /lib/tls/libc.so.6
#3 0xb7dd7653 in ldap_get_values_len () from /usr/lib/libldap_r.so.2
#4 0x08059488 in dkimf_db_get (db=0x8099a28, buf=0xb69fc578, buflen=11, req=0xb69fc4b4, reqnum=3,
exists=0xb69fc4db) at opendkim-db.c:2262
#5 0x0804e75b in dkimf_add_signrequest (dfc=0x8087700, keytable=0x8099a28,
keyname=0xb69fc578 "loopted.com") at opendkim.c:3395
#6 0x08050cef in mlfi_eoh (ctx=0x80a1550) at opendkim.c:7127
I imagine that sanity-checking the size of lud_attrs against reqnum and
throwing an error would take care of it.
--
Mike Markley <mike_at_markley.org>
Going the speed of light is bad for your age.
Received on Fri Feb 19 2010 - 18:47:12 PST