updating technique file after adding new datasource throws date compare errors when generating visualisation layer

[driesbuyck]

After I try to update the techniques yaml file after I added a datasource, I get errors when I want to generate a new navigator layer:

So i have added packet capture logsource to my datasource file: data-sources-demo_withPcap.yaml

1. python dettect.py ds -ft input/techniques-administration-demo-all_update_driveby.yaml -fd input/data-sources-demo_withPcap.yaml --update

2. Error happens when:
   python dettect.py v -ft input/techniques-administration-demo-all_update_driveby.yaml -fd input/data-sources-demo_withPcap.yaml -l

One example of the error can be seen here (the line number might be off as I put in a try/except clause to provide you with some error data to work with)

---

Traceback (most recent call last):
File "/opt/DeTTECT/generic.py", line 591, in get_latest_score_obj
if not newest_score_obj or score_obj_date > newest_date:
TypeError: can't compare TimeStamp to datetime.date

yaml_object:ordereddict([('applicable_to', ['all']), ('comment', ''), ('score_logbook', [ordereddict([('date', datetime.datetime(2020, 10, 8, 13, 33, 1, 644981)), ('score', 2), ('comment', 'Datasource Packet Capture was added'), ('auto_generated', True)]), ordereddict([('date', TimeStamp(2020, 10, 8, 0, 0)), ('score', 1), ('comment', ''), ('auto_generated', True)])])])

score_obj:ordereddict([('date', TimeStamp(2020, 10, 8, 0, 0)), ('score', 1), ('comment', ''), ('auto_generated', True)])

newest_score_obj :ordereddict([('date', datetime.datetime(2020, 10, 8, 13, 33, 1, 644981)), ('score', 2), ('comment', 'Datasource Packet Capture was added'), ('auto_generated', True)])

---

Note that putting below code block into try/except in the end provided me a navigator json file I could load correctly

if not newest_score_obj or score_obj_date > newest_date:
    newest_date = score_obj_date
    newest_score_obj = score_obj

[marcusbakker]

Thanks for reporting the bug!

I pushed a fix that makes sure that date, within a technique administration file, will always be of the type datetime.date. This should fix this issue and other possible similar issues regarding the date.