Silent failure if async DNS is available but async dkimpy is not used

Bug #1954331 reported by David
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dkimpy
Fix Released
Medium
Scott Kitterman

Bug Description

I have an application that runs under asyncio. I noticed a number of Gmail messages failing DKIM validation, despite passing when verified manually.

The problem seems to be the default fallback to aiodns, found in the main code [1].

If neither dnspython or pydns are available [2], dkimpy will fall back to aiodns if available.

In my code I am using the standard verify(..) function, rather than the async version of dkimpy. The DNS request is successfully made, but it is not awaited in the correct manner for async code. Therefore the DNS record is not always available on the first function return (which presumably returns some async magic), and DKIM verification also fails.

Of course it would be sensible to use async functions where possible. However, I do not think that dkimpy should silently fail. The non-async verify function [3] should probably refuse to use an async function, or at minimum throw an error/exception.

1 - https://git.launchpad.net/dkimpy/tree/dkim/__init__.py?h=1.0.5#n72
2 - https://git.launchpad.net/dkimpy/tree/dkim/dnsplug.py?h=1.0.5#n65
3 - https://git.launchpad.net/dkimpy/tree/dkim/__init__.py?h=1.0.5#n936

Revision history for this message
Scott Kitterman (kitterman) wrote :

Thanks. That's not a scenario I had considered when I added asyncio support, but I agree with your assessment.

Changed in dkimpy:
status: New → Triaged
Changed in dkimpy:
milestone: none → 1.1.0
Changed in dkimpy:
importance: Undecided → Medium
assignee: nobody → Scott Kitterman (kitterman)
Revision history for this message
Scott Kitterman (kitterman) wrote :

The way it's set up right now, there's no good way to avoid it as during execution it's not particularly distinguishable. For this to be a problem as it is now, aiodns has to be available, but the async functions not used. I think this is somewhat unusual, so I'll add a way to disable it for this case.

Changed in dkimpy:
status: Triaged → Fix Committed
Changed in dkimpy:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.