Mismatch of documentation about editions for montoya-api extensions

[sysupbda]

The README.md suggests that the extensions are only for the pro edition of Burp, however, the release notes of burp suggest that montoya extensions were added to both the community and professional editions.

I only mention this because I had no experience of the BurpExtender class concept, and I am confused about some documentation/examples pointing to net.portswigger.burp.extensions and others to net.portswigger.burp.extender for montoya-api.

After investigation, I am assuming I am fine using net.portswigger.burp.extensions as it has the release 0.10.1 which is higher than the net.portswigger.burp.extender's 0.9.25 montoya-api. But because Burp is rejecting my extension in a way that is very similar to errors reported by others with the legacy BurpExtender, my confidence is low about what to use, and whether I really should be building using montoya-api instead of the legacy BurpExtender model. I will continue to investigate whether it is my way of creating the jar file or if I am doing some other idiotic thing, but the feedback I receive from the software failing to load my extension leaves me with very little to go on. It just says:

java.lang.Exception: Extension class is not a recognized type
    at burp.dqa.W(Unknown Source)
    at burp.dqa.E(Unknown Source)
    at burp.sb2.o(Unknown Source)
    at burp.jhh.J(Unknown Source)
    at burp.uv0.lambda$panelLoaded$0(Unknown Source)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:833)

Note I am using Burp Community Edition. Can you please help clarify whether it should work? Or whether it is only meant to work for Burp Pro?

[sysupbda]

I managed to get my extension working with the Community Edition. It was indeed something, not sure what, wrong with how I was putting together the JAR.

I am not sure whether it is possible to improve on the resulting error message, as I am not sure what precisely was wrong with my previous setup. It feels like it would open a major scope of "fix all error messages", and I would therefore understand if we chose to close this ticket without processing it.

[sysupbda]

Although, it might be worth syncing the mismatches in documentation, so that:

• It does not state "This repository holds the Burp Suite Pro Extensions API"
• We can maybe have it documented somewhere easy to find that montoya has moved from net.portswigger.burp.extender to net.portswigger.burp.extender
• We might want to specify a specific version rather than use LATEST_VERSION as it would help understand what is expected and avoid people going into some rabbit holes. I think Eclipse gave me a warning about LATEST_VERSION anyway.
• We might want to have neat names for the montaya API and the previous API and clearly have those names reflected and discussed from both API repo's perspectives. Maybe also stating that montaya is the only API that will offer hooking into WebSockets.

[SeanBurnsUK]

Hello @sysupbda,

Thanks for your feedback.

We will be releasing version 1.0.0 of the api in the near feature (next couple of weeks). At that point we will replace "LATEST VERSION" with version 1.0.0.

Up until that point we have been making breaking changes to the api based on the feedback from the community.

We have updated the readme as you recommended. We have also updated the examples so they should be easier to copy and paste.

You can see the latest version in the dev branch of Montoya API Dev. We have also moved the examples for that branch to its own repository Dev Branch Examples

[sysupbda]

Thank you Sean. The versioning makes sense then. May I still suggest the fact that there will likely be breaking changes on the current version of the release? I think a 1.0.0 as a cut-off point where developers can expect stability in the API absolutely makes sense, but I would argue it is not entirely the norm in the industry. Many people use 0.X releases of open source projects blissfully unaware of its likely backwards compatibility breaking possibility.

Whether you choose to make it explicit or not, I think we can close this issue.

Thank you very much for taking the time to consider my suggestions and for pointing out interesting branches and repositories. Have a beautiful day!