Plaso follows the log2timeline style guide.
Every event data attribute container defines a data type (DATA_TYPE).
Conventions for the data type names are:
- If the data type is operating system (or operating system convension such as POSIX) specific start with the name of operating system or convention. Currently supported prefixes:
- android
- chromeos
- ios
- linux
- macos
- windows
Otherwise skip the operating system prefix.
- Next is the name of the application, sub system or data format for example 'chrome', 'windows:registry' or 'windows:evtx'.
TODO: describe which one is preferred and why.
- What follows are application, sub system or data format specific type information for example 'windows:evtx:record'.
Values stored in an event data attribute container must be of certain types otherwise event filtering or output formatting can break. Supported Python types are:
- bool (also see note below)
- int
- str
A list, of the types previously mentioned types, are supported. Do not use dict or binary strings.
Use a bool sparsely. For now it is preferred to preserve the original type. For example if -1 represents False and 0 True, store the value as an integer not as a bool. The message formatter can represent the numeric value as a human readable string.
- Use the test functions available in the local test_lib.py as much as possible nstead of writing your own test functions. If you think a test function is missing please add it, or mail the developer list to see if you can get someone else to do it.
- Use
self.CheckTimestamp
for testing timestamp values.
Common test code should be stored in "test library" files, for example. the parser test
library is tests/parsers/test_lib.py
.
We do this for a few reasons:
- to remove code duplication in "boiler plate" test code;
- to make the tests more uniform in both look-and-feel but also what is tested;
- improve test coverage;
- isolate core functionality from tests to prevent some future core changes affecting the parsers and plugins too much.