This makes it a bit easier to check if all milestoned issues/PRs are addressed, or reassign to a new milestone.
I am committing directly to master as this is a minor change which doesn't need review.
I assume once we migrate to Python3, we want to support Python 3.6-9.
Python 3.5 will stop receiving security fixes next month, so I don't
think we need to support it.
As running the test as many times as we want is free, run them for all
supported versions to ensure capa work in all of them.
Get rid of the `characteristic(switch)` feature as any of our rules use
it and its analysis is not very easy. Analysis results most likely
differ across backends, leading to inconsistency.
Avoid erroneous commits. The pre-commit can be skipped with the
`--no-verify` option, which is not available with the post-commit.
Note that `pre-commit` doesn't run when rebase while post-commit did.
This allows to have a single script which is run by both hooks. This
scripts can also be used independently to run the CI setup locally.
Previously the `setup-hooks.sh` took care of more things. Consequently
the comments needed to be separated. This is not needed anymore and it
looks weird.
The comment claims that:
> doesn't matter if `#!/usr/bin/env bash` gets repeated later on in a hooks file
However it is a convetion that there is only one comment like that and
the `setup-hooks.sh` script already takes care of adding it if the file
didn't exist.
Alternatively, we could leave the extra comment and remove the related
code in `setup-hooks.sh`. Currently two comments are added even if the
file didn't exist.
Run `isort` and `black` in the hooks. Run them with the `--check` option
to not modify files which could be committed by accident.
Note that the changes in `.gitignore` are not needed as `.log` is
already excluded in the Django's section. We add those file to this
section in case `.log` is removed in the future.
They are not needed and complicate the code and make more difficult to
add more parameters to the initialization of Statements.
This produces many changes in the tests. The alternative would be to add
a parameter None in all of them, which are also a lot of changes.
Move the cloning all submodule option to the beginning as when using
capa in development this is the most common option. Test files are
needed to run the tests locally. Simplify the rest of the submodules
documentation, as it is easier for people to look the submodule
documentation than for us to maintain a copy. The submodule init step
shouldn't be needed to clone the rules directory.
Add the tests to the CI GitHub action. Only run the tests if code style
and rule linter succeed, as tests take some time to run.
A similar actions should be added to `capa-testfiles`.
Prevent the linter to raise an exception if `examples` is `None`, as it
for example currently happens in:
`capa-rules/nursery/hash-data-using-murmur2.yml`
We could also remove the `examples` tag in those cases, but the linter
shouldn't break in any case.
```
s = 'number: 4 = I am a description with an = yes'
s.rpartition(' = ') => ('4 = I am a description with an', ' = ', 'yes')
s.partition(' = ') => ('4', ' = ', 'I am a description with an = yes')
s.split(' = ', 1) => ['4', 'I am a description with an = yes']
```
`args` and `value` are a duplication for most of the features:
`args = [value]`
get rid of `args` and introduce `value` for `Feature` (the main class
instead of the subclasses). This makes the code simpler.
Refactoring the `freeze_serialize` function to not use an array would
simplify the code a bit more, but that needs a bit more of work.
A misplaced type annotation in `capa/main.py` causes that black fails to
solve offenses in this file. It may also make capa fail in newer Python
versions. Replace type by `schema` as we don't use type checker tools.
Get rid of `True` in characteristic (rules, output and json) as it is
implicit. This way, the same syntax is used for characteristic as for
the rest of the features.
Co-authored-by: William Ballenthin <william.ballenthin@fireeye.com>
Enable associate context for all features. This was called symbol before
and only enabled for `number`, `offset` and `bytes`.
This is not enabled for strings with regular expressions, as they are
not a feature.
If the style checker of the rule linter failed, the stashed changes were
not restored. There is no reason to exist with an error code in a post
hook. In pre hooks this causes the action to be aborted.
`hidden_meta` saves not only the existing hidden meta keys, but also
those who don't exist with value `None`. For example:
```
{'capa/path': None, 'capa/nursery': None}
```
Deleting nonexistent keys raises a `KeyError` exception.
This should have been removed as part of the migration. The build status
in the README will be reimplemented using GitHub Actions and
https://shields.io
Add the `scripts/setup-hooks.sh` script which sets the following hooks
up:
- The `post-commit` hook runs the linter after every `git commit`,
letting you know if there are code style or rule linter offenses you
need to fix.
- The `pre-push` hook runs the linter and the tests and block the `git
push` if they do not succeed.
This way you realise if everything is alright without the need of
sending a PR.
The `Element` class is just used for testing. By using `Element` we are
not testing the actual code. Also, every time we implement a new feature
for the `Feature` class, we need to implement it for `Element` as well.
Replace `Element` by `Integer`.
