Summary
Running the tool with a non-decimal value argument (for example a hexadecimal literal like 0x220, or any non-numeric string) aborts with an uncaught ValueError traceback instead of a user-friendly error message.
Location
- File(s):
msFlagsDecoder.py
- Line(s) / function(s):
__main__ block at L78 (for userAccountControl) and L122 (for sAMAccountType)
Category
error-handling
Severity
medium
Brief justification: every end user who mistypes the value or pastes a Windows-style hexadecimal value gets a Python traceback. The tool looks broken and no guidance is given.
Reproduction / Evidence
Reproducible at runtime:
$ ./msFlagsDecoder.py userAccountControl 0x220
Traceback (most recent call last):
File "/.../msFlagsDecoder.py", line 78, in <module>
options.value = int(options.value)
^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '0x220'
$ ./msFlagsDecoder.py userAccountControl abc
Traceback (most recent call last):
File "/.../msFlagsDecoder.py", line 78, in <module>
options.value = int(options.value)
^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: 'abc'
$ ./msFlagsDecoder.py sAMAccountType 0x30000000
Traceback (most recent call last):
File "/.../msFlagsDecoder.py", line 122, in <module>
options.value = int(options.value)
^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '0x30000000'
The int(options.value) calls at L78 and L122 run before any validation and propagate straight to the interpreter.
Expected Behavior
The tool prints a concise error message explaining that the value could not be parsed as an integer and exits with a non-zero status code.
Actual Behavior
The tool prints a Python traceback and exits with a non-zero status code coming from the uncaught exception.
Root Cause
int(options.value) is called without any surrounding error handling and without base auto-detection, so every input argparse did not reject crashes the interpreter at that call site.
Summary
Running the tool with a non-decimal
valueargument (for example a hexadecimal literal like0x220, or any non-numeric string) aborts with an uncaughtValueErrortraceback instead of a user-friendly error message.Location
msFlagsDecoder.py__main__block at L78 (foruserAccountControl) and L122 (forsAMAccountType)Category
error-handlingSeverity
mediumBrief justification: every end user who mistypes the value or pastes a Windows-style hexadecimal value gets a Python traceback. The tool looks broken and no guidance is given.
Reproduction / Evidence
Reproducible at runtime:
The
int(options.value)calls at L78 and L122 run before any validation and propagate straight to the interpreter.Expected Behavior
The tool prints a concise error message explaining that the value could not be parsed as an integer and exits with a non-zero status code.
Actual Behavior
The tool prints a Python traceback and exits with a non-zero status code coming from the uncaught exception.
Root Cause
int(options.value)is called without any surrounding error handling and without base auto-detection, so every input argparse did not reject crashes the interpreter at that call site.