[plaso] Fixed parser filter expression bugs #647

[plaso] Fixed parser filter expression bugs #647

[Joachim Metz, 2016-04-20 16:56:12]

Code updated.

[dc3.plaso, 2016-04-21 18:29:08]

On 2016/04/20 16:56:12, Joachim Metz wrote:
> Code updated.

The --parsers option works a lot better when running parsers by themselves,
individual plugins are another story. A plugin_filter_expression is an optional
parameter in some methods of parsers/interface, but nothing ever sets a
plugin_filter_expression, causing all plugins to run every time regardless of
the --parsers arguments. I made a few suggestions on how to set a
plugin_filter_expression in the parsers/* class that supports plugins (sqlite,
olecf, esedb, etc.).

[dc3.plaso, 2016-04-21 18:30:36]

Made some comments about running individual plugins.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/interface.p...
plaso/parsers/interface.py:75: Takes a comma separated string and splits it up
into two dictionaries,
two lists

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:70: return includes, excludes
This creates a dictionary with the parser name as a key and a list of
included/excluded plugins of that parser (or empty if all plugins should run) as
values, but the list is never passed/called/required anywhere. The only method
that calls _GetParserFilters is GetParsers, which yields the parser name and
class without caring what plugins are associated. With --parsers
sqlite/appusage, all sqlite plugins will run.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:198: parser_objects[parser_name] = parser_class()
One solution would be to create and pass a plugin_filter_expression to the
parser_class() here, but that would require all parsers with plugins to have
__init__(self, plugin_filter_expression=None): in the contructor.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:239: yield parser_name, parser_class
The plugin information in the inclusion/exclusion dictionary is lost.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/sqlite.py
File plaso/parsers/sqlite.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/sqlite.py#n...
plaso/parsers/sqlite.py:226: self._plugins = SQLiteParser.GetPluginObjects()
This causes plugin_filter_expression in parsers/interface to always be None,
indicating to run all plugins regardless.

[Joachim Metz, 2016-04-26 04:58:23]

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/interface.p...
plaso/parsers/interface.py:75: Takes a comma separated string and splits it up
into two dictionaries,
On 2016/04/21 18:30:36, dc3.plaso wrote:
> two lists

Acknowledged.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:70: return includes, excludes
Good catch. As you indicate passing it via init could be an alternative. Let me
give this some thought.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:198: parser_objects[parser_name] = parser_class()
On 2016/04/21 18:30:36, dc3.plaso wrote:
> One solution would be to create and pass a plugin_filter_expression to the
> parser_class() here, but that would require all parsers with plugins to have
> __init__(self, plugin_filter_expression=None): in the contructor.

Acknowledged.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:239: yield parser_name, parser_class
On 2016/04/21 18:30:36, dc3.plaso wrote:
> The plugin information in the inclusion/exclusion dictionary is lost.

Acknowledged.

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/sqlite.py
File plaso/parsers/sqlite.py (right):

https://codereview.appspot.com/293180043/diff/20001/plaso/parsers/sqlite.py#n...
plaso/parsers/sqlite.py:226: self._plugins = SQLiteParser.GetPluginObjects()
On 2016/04/21 18:30:36, dc3.plaso wrote:
> This causes plugin_filter_expression in parsers/interface to always be None,
> indicating to run all plugins regardless.

Acknowledged.

[Joachim Metz, 2016-04-26 20:25:05]

Code updated.

[dc3.plaso, 2016-04-27 19:29:23]

Looks a lot cleaner than my idea! :)

Exclusion list is not handled properly when configuration is '--parsers
sqlite,!sqlite/appusage', all sqlite parsers will still run. I included a fix to
it in parsers/mediator should you be so inclined to need it.

There are a few other corner cases that don't produce the correct output (the
most simple of which being !sqlite,sqlite/appusage to indicate: run all parsers
except sqlite, but run sqlite/appusage), but they all seem a bit far fetched and
require something other than 'None' to mean 'run all parsers'.

When running a single olecf plugin (other than default), the olecf_default runs
as well. Not sure if that's intended.

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/interface.p...
plaso/parsers/interface.py:64: # _plugin_classes = {}
Do these comments still need to be here?

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:209: 
# get all parser plugins, then subtract out the excluded ones
if (not plugin_includes and parser_name in excludes and
parser_class.SupportsPlugins()):
  plugin_names = []
  for plugin_name, _ in parser_class.GetPlugins():
    plugin_names.append(plugin_name)
  plugin_includes = set(plugin_names).difference(
      set(excludes[parser_name])

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser.py
File plaso/parsers/text_parser.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser...
plaso/parsers/text_parser.py:756: 
Remove space

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
File plaso/parsers/xchatscrollback.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
plaso/parsers/xchatscrollback.py:79: self.text = text
Any reason to reorder these variables? Either keep them alphabetical in their
assignments and doc string or follow the ordering in the init params.

[Joachim Metz, 2016-04-27 20:01:36]

> Looks a lot cleaner than my idea! :)

Great, we seem to be in agreement on the way forward ;)

> Exclusion list is not handled properly when configuration is

Ack, thx I'll look at this and add test coverage.

[Joachim Metz, 2016-04-27 20:01:40]

> Looks a lot cleaner than my idea! :)

Great, we seem to be in agreement on the way forward ;)

> Exclusion list is not handled properly when configuration is

Ack, thx I'll look at this and add test coverage.

[Joachim Metz, 2016-04-27 20:04:08]

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/interface.p...
plaso/parsers/interface.py:64: # _plugin_classes = {}
On 2016/04/27 19:29:22, dc3.plaso wrote:
> Do these comments still need to be here?

Yes, the class variable _plugin_classes still needs to be defined on a per
parser basis otherwise the plugin classes of all parsers are stored in that of
BaseParser.

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
File plaso/parsers/xchatscrollback.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
plaso/parsers/xchatscrollback.py:79: self.text = text
They are in alphabetical order and match the order of "Attributes:" in the class
docstring? If you think it is more clear to have the arguments of init to also
be alphabetical order, we can pursue that. Until now we've not been doing so.

[dc3.plaso, 2016-04-28 12:08:55]

Any ideas about the olecf issue?

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
File plaso/parsers/xchatscrollback.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
plaso/parsers/xchatscrollback.py:79: self.text = text
On 2016/04/27 20:04:08, Joachim Metz wrote:
> They are in alphabetical order and match the order of "Attributes:" in the
class
> docstring? If you think it is more clear to have the arguments of init to also
> be alphabetical order, we can pursue that. Until now we've not been doing so.

No, I don't think that's necessary. Line 70 and 71 Need to be swapped though.

[dc3.plaso, 2016-04-28 12:09:04]

Any ideas about the olecf issue?

[Joachim Metz, 2016-04-28 12:53:06]

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
File plaso/parsers/xchatscrollback.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
plaso/parsers/xchatscrollback.py:79: self.text = text
Typically method args in docstrings are in args order, not in alpha order.

https://google.github.io/styleguide/pyguide.html?showone=Comments#Comments

[dc3.plaso, 2016-04-28 17:19:03]

On 2016/04/28 12:53:06, Joachim Metz wrote:
>
https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
> File plaso/parsers/xchatscrollback.py (right):
> 
>
https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/xchatscroll...
> plaso/parsers/xchatscrollback.py:79: self.text = text
> Typically method args in docstrings are in args order, not in alpha order.
> 
> https://google.github.io/styleguide/pyguide.html?showone=Comments#Comments

Noted

[Joachim Metz, 2016-05-05 12:40:54]

Fixed support for a parser expression string with only excludes.

> Any ideas about the olecf issue?

> When running a single olecf plugin (other than default), the olecf_default
runs
> as well. Not sure if that's intended.

For now yes. My idea was to have the default plugin enabled when the parser is
enabled.
Let me give this some thought, if it makes sense to disable default plugins as
well.

[Joachim Metz, 2016-05-05 12:41:03]

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:209: 
I see what you mean, I'll solve this differently and add a test.

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser.py
File plaso/parsers/text_parser.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser...
plaso/parsers/text_parser.py:756: 
On 2016/04/27 19:29:22, dc3.plaso wrote:
> Remove space

I'll remove it, just FYI, style guide allows for both.

[Joachim Metz, 2016-05-05 12:41:05]

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/manager.py#...
plaso/parsers/manager.py:209: 
I see what you mean, I'll solve this differently and add a test.

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser.py
File plaso/parsers/text_parser.py (right):

https://codereview.appspot.com/293180043/diff/40001/plaso/parsers/text_parser...
plaso/parsers/text_parser.py:756: 
On 2016/04/27 19:29:22, dc3.plaso wrote:
> Remove space

I'll remove it, just FYI, style guide allows for both.

[Joachim Metz, 2016-05-05 13:01:21]

Code updated.

[Joachim Metz, 2016-05-05 14:50:21]

FYI recent changes from HEAD seem to have leaked into this CL.

[dc3.plaso, 2016-05-05 15:56:23]

LG2M. I assume the leak is in response to mostly the parsers\syslog file.

[Joachim Metz, 2016-05-09 05:15:58]

Code updated.

[dc3.plaso, 2016-05-09 20:08:47]

On 2016/05/09 05:15:58, Joachim Metz wrote:
> Code updated.

LG2M

[onager, 2016-05-10 04:56:01]

Got up to the parser manager, but running out of time, so partial review.

I don't love the
passing-empty-lists-of-plugins-to-init-for-parsers-that-don't-actually-support-plugins
pattern, it's pretty ugly. Is there a way to tidy that up? I haven't examined
this in detail yet.

https://codereview.appspot.com/293180043/diff/80001/plaso/frontend/presets.py
File plaso/frontend/presets.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/frontend/presets.py...
plaso/frontend/presets.py:43: u'android_app_usage', u'sqlite/android_calls',
u'sqlite/android_sms']}
+filestat?

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py
File plaso/parsers/bsm.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py#newc...
plaso/parsers/bsm.py:536: plugins. The default plugin, named "NAME_default",
NAME_default? And this parser doesn't actually support plugins, so this is just
to make the interface consistent?

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py#newc...
plaso/parsers/bsm.py:537: is handled seperately.
separately

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/iis.py
File plaso/parsers/iis.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/iis.py#newc...
plaso/parsers/iis.py:149: is handled seperately.
separately

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/interface.p...
plaso/parsers/interface.py:77: is handled seperately.
separately (I'll stop mentioning this now).

What does "separately" actually mean? It's enabled by default, regardless of
what this plugins list includes, so we should say that.

[Joachim Metz, 2016-05-11 19:35:31]

> I don't love the
passing-empty-lists-of-plugins-to-init-for-parsers-that-don't-actually-support-plugins
> pattern, it's pretty ugly. Is there a way to tidy that up? I haven't examined
this in detail yet.

I'll give this some thought but no good alternative came to mind previously.

[Joachim Metz, 2016-05-11 19:35:36]

> I don't love the
passing-empty-lists-of-plugins-to-init-for-parsers-that-don't-actually-support-plugins
> pattern, it's pretty ugly. Is there a way to tidy that up? I haven't examined
this in detail yet.

I'll give this some thought but no good alternative came to mind previously.

[Joachim Metz, 2016-05-11 19:36:03]

https://codereview.appspot.com/293180043/diff/80001/plaso/frontend/presets.py
File plaso/frontend/presets.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/frontend/presets.py...
plaso/frontend/presets.py:43: u'android_app_usage', u'sqlite/android_calls',
u'sqlite/android_sms']}
On 2016/05/10 04:56:01, onager wrote:
> +filestat?

SGTM

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py
File plaso/parsers/bsm.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py#newc...
plaso/parsers/bsm.py:536: plugins. The default plugin, named "NAME_default",
On 2016/05/10 04:56:01, onager wrote:
> NAME_default? And this parser doesn't actually support plugins, so this is
just
> to make the interface consistent?

Yes

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/bsm.py#newc...
plaso/parsers/bsm.py:537: is handled seperately.
On 2016/05/10 04:56:01, onager wrote:
> separately

Done also in other places in the codebase.

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/iis.py
File plaso/parsers/iis.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/iis.py#newc...
plaso/parsers/iis.py:149: is handled seperately.
On 2016/05/10 04:56:01, onager wrote:
> separately

Done.

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/80001/plaso/parsers/interface.p...
plaso/parsers/interface.py:77: is handled seperately.
> separately (I'll stop mentioning this now).

;)

> What does "separately" actually mean? It's enabled by default,
> regardless of what this plugins list includes, so we should say
> that.

Ack

[Joachim Metz, 2016-05-14 14:14:46]

I'll could move the plugin initialization into a separate method.

[Joachim Metz, 2016-05-15 07:47:28]

Code updated.

[Joachim Metz, 2016-05-15 07:53:00]

Code updated.

[Joachim Metz, 2016-05-15 07:54:53]

Some previous changes seem to have leaked into this CL, used diffbase:
7c5f934bfe13f046cc5b31d48979c602a25b3808

[onager, 2016-05-16 04:27:22]

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface....
plaso/parsers/interface.py:77: The default plugin, named
"{self.NAME:s}_default", is handled separately.
-separately +"and is always enabled if it exists, and cannot be disabled"

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface....
plaso/parsers/interface.py:110: plugins. Not that the default plugin is handled
"note" and see above regarding "separately"

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/plist.py
File plaso/parsers/plist.py (right):

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/plist.py#n...
plaso/parsers/plist.py:125: if self._default_plugin:
Are you sure you want this? To process every plist with the default, as well as
the specific one?

https://codereview.appspot.com/293180043/diff/120001/tests/parsers/docker.py
File tests/parsers/docker.py (left):

https://codereview.appspot.com/293180043/diff/120001/tests/parsers/docker.py#...
tests/parsers/docker.py:18: self._parser = docker.DockerJSONParser()
You don't like this pattern?  Another update for the style guide along the lines
of "don't use a setUp method in tests"?

[Joachim Metz, 2016-05-16 04:35:40]

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface....
plaso/parsers/interface.py:77: The default plugin, named
"{self.NAME:s}_default", is handled separately.
On 2016/05/16 04:27:21, onager wrote:
> -separately +"and is always enabled if it exists, and cannot be disabled"

Done.

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/interface....
plaso/parsers/interface.py:110: plugins. Not that the default plugin is handled
On 2016/05/16 04:27:22, onager wrote:
> "note" and see above regarding "separately"

Done.

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/plist.py
File plaso/parsers/plist.py (right):

https://codereview.appspot.com/293180043/diff/120001/plaso/parsers/plist.py#n...
plaso/parsers/plist.py:125: if self._default_plugin:
Good point I'll have a look.

https://codereview.appspot.com/293180043/diff/120001/tests/parsers/docker.py
File tests/parsers/docker.py (left):

https://codereview.appspot.com/293180043/diff/120001/tests/parsers/docker.py#...
tests/parsers/docker.py:18: self._parser = docker.DockerJSONParser()
I'm not against using setUp. Using it for the creation of a single object using
setUp() is IMO overkill.

[Joachim Metz, 2016-05-16 04:43:31]

Code updated.

[dc3.plaso, 2016-05-16 14:02:04]

Some runtime errors.

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py...
plaso/parsers/manager.py:212: parser_object.EnablePlugins(plugin_includes)
Unless I'm missing something, the EnablePlugins method needs to be created for
all parsers that support plugins. Currently, sqlite and syslog will throw
errors.

https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py
File tests/parsers/sqlite.py (right):

https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py#...
tests/parsers/sqlite.py:22: parser_object.EnablePlugins([u'chrome_history'])
Not sure this method exists for sqlite.

[Joachim Metz, 2016-05-16 15:23:28]

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py
File plaso/parsers/manager.py (right):

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py...
plaso/parsers/manager.py:212: parser_object.EnablePlugins(plugin_includes)
It is defined in the interface, should not be necessary to create your own
EnablePlugins.
See:
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py

syslog definitely creates its own EnablePlugins.
See:
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/syslog.py

Can you send the errors you are seeing e.g. via mail.

https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py
File tests/parsers/sqlite.py (right):

https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py#...
tests/parsers/sqlite.py:22: parser_object.EnablePlugins([u'chrome_history'])
On 2016/05/16 14:02:04, dc3.plaso wrote:
> Not sure this method exists for sqlite.

Is defined in the BaseParser. See:
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py

[dc3.plaso, 2016-05-16 15:28:38]

On 2016/05/16 15:23:28, Joachim Metz wrote:
> https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py
> File plaso/parsers/manager.py (right):
> 
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py...
> plaso/parsers/manager.py:212: parser_object.EnablePlugins(plugin_includes)
> It is defined in the interface, should not be necessary to create your own
> EnablePlugins.
> See:
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py
> 
> syslog definitely creates its own EnablePlugins.
> See:
> https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/syslog.py
> 
> Can you send the errors you are seeing e.g. via mail.
> 
> https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py
> File tests/parsers/sqlite.py (right):
> 
>
https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py#...
> tests/parsers/sqlite.py:22: parser_object.EnablePlugins([u'chrome_history'])
> On 2016/05/16 14:02:04, dc3.plaso wrote:
> > Not sure this method exists for sqlite.
> 
> Is defined in the BaseParser. See:
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py

Thanks. I was looking at the wrong delta between patches. Sorry about that

[onager, 2016-05-17 01:18:34]

On 2016/05/16 15:28:38, dc3.plaso wrote:
> On 2016/05/16 15:23:28, Joachim Metz wrote:
> >
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py
> > File plaso/parsers/manager.py (right):
> > 
> >
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/manager.py...
> > plaso/parsers/manager.py:212: parser_object.EnablePlugins(plugin_includes)
> > It is defined in the interface, should not be necessary to create your own
> > EnablePlugins.
> > See:
> >
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py
> > 
> > syslog definitely creates its own EnablePlugins.
> > See:
> > https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/syslog.py
> > 
> > Can you send the errors you are seeing e.g. via mail.
> > 
> > https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py
> > File tests/parsers/sqlite.py (right):
> > 
> >
>
https://codereview.appspot.com/293180043/diff/140001/tests/parsers/sqlite.py#...
> > tests/parsers/sqlite.py:22: parser_object.EnablePlugins([u'chrome_history'])
> > On 2016/05/16 14:02:04, dc3.plaso wrote:
> > > Not sure this method exists for sqlite.
> > 
> > Is defined in the BaseParser. See:
> >
>
https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py
> 
> Thanks. I was looking at the wrong delta between patches. Sorry about that

LGTM

[onager, 2016-05-17 01:18:55]

Woops, forgot to say, couple of typos

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface....
plaso/parsers/interface.py:77: The default plugin, named
"{self.NAME:s}_default", if it exitsts,
"exists"

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface....
plaso/parsers/interface.py:110: to enable, where None or an empty list
represents all
"exists"

[Joachim Metz, 2016-05-17 03:20:41]

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface.py
File plaso/parsers/interface.py (right):

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface....
plaso/parsers/interface.py:77: The default plugin, named
"{self.NAME:s}_default", if it exitsts,
On 2016/05/17 01:18:55, onager wrote:
> "exists"

Done.

https://codereview.appspot.com/293180043/diff/140001/plaso/parsers/interface....
plaso/parsers/interface.py:110: to enable, where None or an empty list
represents all
On 2016/05/17 01:18:55, onager wrote:
> "exists"

Done.

[Joachim Metz, 2016-05-17 03:25:13]

Manual merge