Why the DSL language doesn't match the documentation ?

[theoberthier]

Describe the bug
The DSL(Gremlin) request differ between documentation and reality.

To Reproduce
Steps to reproduce the behavior:

1. Go to jupyter Notebook
2. Go to one playbook
3. found container name with kh.containers().elementMap()
4. take one name of container and launchd " kh.containers("name_of_container").attacks().
5. i have this error : {'error': TypeError("unhashable type: 'dict'")}

same for

• 'kh.services().criticalPath()'
• 'kh.group("name_of_group").criticalPaths(5)' : => group doesn't exist, it's groups() and with groups().criticalPaths(5) doesn't works too
• and maybe another

Expected behavior
All attacks possible from a specific in the graph (like documentation)

Kubehound version
Release v1.3.2

Another question
Why the release 2.* are gone ?

[edznux-dd]

Hey, thanks for the report and sorry for the delay, we've been busy with the preparation for defcon/BH workshops!

We have updated the documentation a bit for 1.4.0 but I can reproduce kh.containers("name_of_container").attacks()., i'm going to take a look ASAP.

'kh.group("name_of_group").criticalPaths(5)' : => group doesn't exist, it's groups() and with groups().criticalPaths(5) doesn't works too

group => groups in the documentation was fixed with the 1.4 release (see documentation here)

The {'error': TypeError("unhashable type: 'dict'")} is still there however.

Another question
Why the release 2.* are gone ?

We realized it didn't make sense to have a 2.0 that is pretty much identical to 1.x (there wasn't any breaking change).
And moving to 2.0 would have made some release process more annoying (for example, the ability to go install) both from a user and a maintainer perspective.

Since the user base was still low and was going to grow after our workshops/presentation we decided to move back to 1.x.
We know it's not great, and we shouldn't have released the 2.0 in the first place but it was simply better to do it now instead of later. We deemed the number of downloads for the 2.x release to be low enough that we wouldn't break any major workflows :)
We could have kept the images, available but that would have caused confusion for the users for "which version is the latest".

The project now more closely match the SemVer model.

(I've created ASENG-1437 for internal tracking)

[theoberthier]

Thank you for your answer.
I understand that my base is 1.4.0 now.
Do you want me to specify here which commands don’t work when i found them ?