-
Notifications
You must be signed in to change notification settings - Fork 41
Description
🐛 Summary
Trustymail saves new PSLs to './public_suffix_list.dat' even when specifying a different file name using --psl-filename=
. Additionally, older PSLs are overwritten even when using --psl-read-only
.
This behavior is confirmed both through WSL and through a Docker container.
Because of this, trustymail is difficult to run in bulk, and is throwing errors from failed PSL fetches from publicsuffix.org.
To reproduce
Steps to reproduce the behavior:
-
Open terminal
-
Run
trustymail --psl-filename=psl.dat cisa.gov
-
See PSL is saved to 'public_suffix_list.dat' instead of 'psl.dat'
-
Run
trustymail --psl-read-only cisa.gov
-
Note last modified time of 'public_suffix_list.dat'
-
Change last modified time by running
python3 -c "from os import utime; utime('public_suffix_list.dat', (1330712280, 1330712280))"
. -
Confirm that the last modified time was changed
-
Repeat step 1
-
See that the last modified time changed, signaling that PSL is overwritten
Expected behavior
Trustymail should never fetch a new PSL when specifying --psl-read-only
.
Trustymail should read from/save to the path specified by --psl-filename=
Any helpful log output or screenshots
Here's an image of a container running trustymail against 22 dummy domains. The container spawns with an out of date PSL. Arguments specify that the file is read only to avoid trustymail producing unnecessary fetch requests. Trustymail rapidly produces 11 fetch requests (most of which fail causing their respective child processes to exit with error). When a fetch is successful, the PSL is overwritten evidenced by it's last modified time changing.
