[exim-dev] [Bug 1523] New: DANE support under GnuTLS
--- You are receiving this mail because: --- You are on the CC list for the bug. http://bugs.exim.org/show_bug.cgi?id=1523 Summary: DANE support under GnuTLS Product: Exim Version: 4.84 Platform: All OS/Version: All Status: NEW Severity: wishlist Priority: low Component: TLS AssignedTo: p...@exim.org ReportedBy: jgh146...@wizmail.org CC: exim-dev@exim.org EXPERIMENTAL_DANE only works with an OpenSSL build. We should do a GnuTLS implementation also. Viktor has, I think, opined that the builtin support in GnuTLS for DANE is insufficient; possibly we should try to use the same library (basically Viktor's code) for both. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 1523] New: DANE support under GnuTLS
On Tue, Sep 02, 2014 at 02:03:05PM +0100, Jeremy Harris wrote: Viktor has, I think, opined that the builtin support in GnuTLS for DANE is insufficient; possibly we should try to use the same library (basically Viktor's code) for both. The DANE support in GnuTLS does not handle DANE-TA(2) where the trust-anchor is not the immediate issuer of the leaf certificate. It also predates the new requirement to not enforce the expiration date or hostname found in the leaf certificate for DANE-EE(3) as these are already handled (much better) in DNSSEC. There may be other issues, those were the easy ones I found when reading the code a year or so ago. My library depends on OpenSSL internals, I don't know how much work is required to port/rewrite it for GnuTLS. Perhaps a better approach is to contact the GnuTLS dane add-on maintainer, and see if he or she would be interested in updating/improving the code. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 1523] DANE support under GnuTLS
--- You are receiving this mail because: --- You are on the CC list for the bug. http://bugs.exim.org/show_bug.cgi?id=1523 --- Comment #1 from Andreas Metzler eximus...@bebt.de 2014-09-02 18:04:23 --- On 2014-09-02 Jeremy Harris jgh146...@wizmail.org wrote: EXPERIMENTAL_DANE only works with an OpenSSL build. We should do a GnuTLS implementation also. Viktor has, I think, opined that the builtin support in GnuTLS for DANE is insufficient; possibly we should try to use the same library (basically Viktor's code) for both. Just as a data point: GnuTLS DANE support is currently not used a lot since it requires unbound which in turn requires one of the other two big SSL toolkits (NSS or OpenSSL). That is why we are not shipping the library in Debian yet. That is supposed to change, though, see http://lists.gnutls.org/pipermail/gnutls-devel/2014-July/007039.html cu Andreas -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 1524] New: extract inside inlisti, fails
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1524
Summary: extract inside inlisti, fails
Product: Exim
Version: 4.84
Platform: All
OS/Version: All
Status: NEW
Severity: bug
Priority: medium
Component: String expansion
AssignedTo: jgh146...@wizmail.org
ReportedBy: jgh146...@wizmail.org
CC: exim-dev@exim.org
Messing around with an LDAP issue I started trying to
lay out some example coding, and ran into some brainfade.
I'd got to here:
${if forany \
{mail:EximMailPrimaryAddress:EximMailAlternateAddress} \
{inlisti {$local_part} \
{, ${extract {$item} \
{${lookup
ldapm{ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4}}}\
}\
}\
}\
}
and, replacing the $local_part for testing, failed like so:
${if forany \
{mail:EximMailPrimaryAddress:EximMailAlternateAddress} \
{inlisti {user4alterna...@example.com} \
{, ${extract {$item} \
{${lookup
ldapm{ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4}}}\
}\
}\
}\
}
expanding: mail:EximMailPrimaryAddress:EximMailAlternateAddress
result: mail:EximMailPrimaryAddress:EximMailAlternateAddress
expanding: user4alterna...@example.com
result: user4alterna...@example.com
skipping: result is not used
expanding: $item
result:
skipping: result is not used
expanding: ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4
result: ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4
skipping: result is not used
expanding: ${lookup
ldapm{ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4}}
result:
skipping: result is not used
failed to expand: , ${extract {$item} {${lookup
ldapm{ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4}}}
error message: missing or misplaced { or }
failed to expand: ${if forany
{mail:EximMailPrimaryAddress:EximMailAlternateAddress} {inlisti
{user4alterna...@example.com} {, ${extract {$item} {${lookup
ldapm{ldap://localhost/ou=users,dc=example,dc=com?mail,cn?sub?cn=user4}}}
error message: missing or misplaced { or } inside forany condition
Failed: missing or misplaced { or } inside forany condition
This looks to be a syntax-check initial run through
the arguments for the forany, failing because $item
is empty and ${extract requires nonempty.
Replace the $item with a dummy and it works.
The reason is that the empty result for $item is wrongly interpreted as a
number, and a third substring is insisted upon for the extract.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
[exim-dev] [Bug 1524] extract inside inlisti, fails
--- You are receiving this mail because: --- You are on the CC list for the bug. http://bugs.exim.org/show_bug.cgi?id=1524 --- Comment #1 from Jeremy Harris jgh146...@wizmail.org 2014-09-02 23:48:02 --- Created an attachment (id=754) -- (http://bugs.exim.org/attachment.cgi?id=754) Skip the is-numeric check for the syntax-check pseudo-expansion -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 1524] extract inside inlisti, fails
--- You are receiving this mail because: --- You are on the CC list for the bug. http://bugs.exim.org/show_bug.cgi?id=1524 Jeremy Harris jgh146...@wizmail.org changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 1524] extract inside inlisti, fails
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1524
Git Commit g...@exim.org changed:
What|Removed |Added
CC||g...@exim.org
--- Comment #2 from Git Commit g...@exim.org 2014-09-03 00:17:07 ---
Git commit:
http://git.exim.org/exim.git/commitdiff/82dbd376b5de9b9d91e93e91a4e058a80a43de99
commit 82dbd376b5de9b9d91e93e91a4e058a80a43de99
Author: Jeremy Harris jgh146...@wizmail.org
AuthorDate: Tue Sep 2 23:37:57 2014 +0100
Commit: Jeremy Harris jgh146...@wizmail.org
CommitDate: Tue Sep 2 23:53:28 2014 +0100
fix ${extract expansion for use within ${if inlist etc. bug 1524
the coding of the numeric test on the key decided that empty was numeric,
and
insisted on a third substring even in syntax-check skip mode. this
failed
when a single expansion variable was used for the key (eg. $item) and the
defaults for string2, string3 were being assumed. skip the test in skip
mode.
src/src/expand.c | 45 ++---
1 files changed, 26 insertions(+), 19 deletions(-)
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
[exim-dev] [Bug 1523] DANE support under GnuTLS
--- You are receiving this mail because: --- You are on the CC list for the bug. http://bugs.exim.org/show_bug.cgi?id=1523 --- Comment #2 from Phil Pennock p...@exim.org 2014-09-03 01:13:51 --- The exbot42 build farm agent is using unbound as its local resolver. Todd, shout if you want me to add a bunch more agents, as variant builds, or if you just want ssh access to the build farm account on that machine. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] DANE work
My jaw dropped when I returned to my list index view and saw just how many patches came in from work this weekend by Todd and Jeremy to implement DANE in Exim. Seriously good work which makes me very happy and feeling that I owe drinks to you both. Thank you for picking up where I totally slacked off and working on implementing this. (Thank you for removing one of my guilt layers of I need to find time to work on X too). Happiness. :) -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] DANE work
On Wed, Sep 03, 2014 at 12:27:16AM +, Phil Pennock wrote: My jaw dropped when I returned to my list index view and saw just how many patches came in from work this weekend by Todd and Jeremy to implement DANE in Exim. Seriously good work which makes me very happy and feeling that I owe drinks to you both. Thank you for picking up where I totally slacked off and working on implementing this. (Thank you for removing one of my guilt layers of I need to find time to work on X too). Yes, thanks a bunch. I have a few questions about the code. Specifically: verify_callback_client_dane(), (lines 469--471) tlsa_lookup(), (lines 1691--1713) dane_tlsa_load(), (all lines) transports/smtp.c: (lines 3297--3306, tempfail_try_clear logic) Since I only read the commit diff, I am missing some context, so please pardon my ignorance... I don't know where the logic is that tracks the DNSSEC status of the MX lookup to determine whether the subsequent per MX-host lookups can be considered secure. I am not sure that DNS lookup errors are handled correctly. I could not find code that distinguishes between lookups failure and NXDOMAIN (which is not a lookup error). I don't at first glance see code that enforces STARTTLS, without authentication, when a secure TLSA RRset exists, but all records are unusable. I did not find any code to coerce PKIX-EE(1) and PKIX-TA(0) to unusable. I did notice that unsupported matching types seem to be needlessly treated as errors, rather than as an unusable record among possibly usable other records. I am confused by the interaction with tempfail try clear. The DANE-specific verify callback seems to assume that any call in which the verification status is OK is sufficient to make the peer's chain valid, but that need not be the case when the chain length is greater than 1. It may be best to not infer any final status in that callback, and check the verification state after the connection completes, sending a QUIT (to the MiTM perhaps) and gracefully closing the connection if verification failed. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
