Fix setuptools error due to non-compliant version number

[mathdeziel]

Now that setuptools seems to enforce the PEP 440 – Version Identification and Dependency Specification (as tested on a fresh and updated Kali 2023.1 environment), installing inql as a standalone tool fails due to the version number the git describe command outputs.

In its current form, the version output would be <TAG>-<COMMITS-AHEAD>-<HASH> which is not compliant and prevents the successful completion of the install command, either through python3 setup.py install or pip install.

This PR adds the --abbrev=0 parameter and value to git describe, which will only return the tag, without the commits ahead of master and hash, allowing the install command to run successfully.

[execveat]

Hey Mathieu,

Thank you for the pull request, I will merge it shortly. This is a nice fix and I appreciate you taking the time to contribute.

However, I wanted to give you a heads up that we are planning to to deprecate and eventually abandon the standalone version of InQL in the near future. The reason is that the extension is currently written in Jython, which has been deprecated and stuck at Python 2. To make the extension easier to maintain and more streamlined for users, we are rewriting it in Kotlin and aiming at tighter integration with Burp.

That said, if you or others see a need for the standalone version, you are more than welcome to fork the project and continue its development. We would be happy to support a fork, if the maintenance burden is taken off of us.

Also, a portion of InQL's functionality has been offloaded into a separate project - GQLSpection. GQLSpection supports both Python 2 and 3 and can be used standalone. It may be a better target for your contributions, if the standalone mode is important to you.

I'm also curious about your use case for the standalone mode. We may be able to incorporate some of its functionality or use cases into the extension or GQLSpection.

Thanks again, and let me know if you have any other questions or comments.

Regards,
Andrew

[mathdeziel]

Hi Andrew / @execveat,

Thank you for merging it even though it will be deprecated, I'm glad I could contribute!

The standalone mode is being used in the newly released book Black Hat GraphQL to :

• Identify circular queries with the --generate-cycles flag; and
• Automate schema extraction and generate a report with the --generate-tsv flag.

I think the second use case could work with GQLSpection, but I haven't seen any mention of "cycles" in the codebase (although it wasn't an extensive search) to fulfill the first use case.

I'd like yo hear your thoughts on that.

Thanks!

[execveat]

Ah, I see. Cycles detection is the only feature that was present in 4.x branch but won't be included in 5.0 release. That's just due to time constraints though, we're not deprecating this functionality. There are a number of algorithms implemented in 4.x and recently @schoobydrew contributed Tarjan's algorithm: #82, so it's simply a matter of choosing one of those and porting it to GQLSpection.

The next release, 5.1 should be at full feature parity with the 4.x branch, which means cycles detection will land in GQLSpection before that, sometime this spring. Stay tuned (also, feel free to submit feature requests / PRs to that repo)!

As for the schema export, that's super easy to implement as GQLSpection already has all of the necessary bits to discover server's GraphQL spec version and to send the correct introspection query, right now it's just not exposed through CLI. I'll add that option and release a new version, shortly.

[mathdeziel]

Great! From what I read, switching to GQLSpection as a standalone tool would indeed be the best option in the somewhat near future. I'll be sure to take a look at the repo to see if I can contribute something 😉

In the meantime, I think this current PR still has its place to ensure compliance and proper installation before dropping support 🤔