raise FileNotFoundError for missing TLS material
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 54.3k
- Forks
- 10.4k
- Avg merge
- 16h 43m
- Merged PRs (30d)
- 3
Description
Would you accept a PR which changes the existing OSError for missing TLS material to FileNotFoundError?
e.g.:
if conn.cert_file and not os.path.exists(conn.cert_file):
raise OSError(
f"Could not find the TLS certificate file, "
f"invalid path: {conn.cert_file}"
)
becomes something like:
if conn.cert_file and not os.path.exists(conn.cert_file):
from errno import ENOENT
raise FileNotFoundError(
ENOENT,
"Could not find the TLS certificate file, invalid path",
str(conn.cert_file)
)
Our use case is that there are temporary conditions where the files don't exist and it'd be nicer to handle FileNotFoundError specifically and be able to compare the .filename attribute rather than the more general OSError and test str(excp).endswith(...). As FileNotFoundError is a subclass of OSError existing try/excepts continue to work but it would change the string representation:
>>> str(OSError("Could not find the TLS certificate file, invalid path: filename"))
'Could not find the TLS certificate file, invalid path: filename'
>>> str(FileNotFoundError(errno.ENOENT, "Could not find the TLS certificate file, invalid path", "filename"))
"[Errno 2] Could not find the TLS certificate file, invalid path: 'filename'"
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Search the repository for the conn.cert_file existence check shown in the issue and inspect its nearby tests or callers. Confirm the current OSError behavior and identify coverage for missing TLS material. Done means missing certificate paths raise FileNotFoundError with ENOENT and the filename available for targeted handling, while existing OSError handlers continue to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- security
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100