You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
It seems like these two values are global constants initialized in __init__.py, and can't be overwritten. Instead of making these global constants, why not use docopt's default value functionality in cli.py, then import the values to domain.py for use by the get_psl definitions. Here's an example from docopt.org.
🐛 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.
The text was updated successfully, but these errors were encountered: