search

Vector35 / binaryninja-api

Public API, examples, documentation and issues for Binary Ninja
https://binary.ninja/
MIT License
934 stars 212 forks source link

create github actions for native plugin authors to build/release plugins tracking both stable and dev #3399

Open robert-yates opened 2 years ago

robert-yates commented 2 years ago

Is this a general concept that needs to be documented or a specifi API? General Concept: What is the workflow for building and submitting a binja c++ based plugin, how to compile for all platforms, how to version and manage dependencies and linking etc.

There is already a good python plugin documentation: https://github.com/Vector35/community-plugins

What concept or API needs more documentation? N/A

Is this documentation related to a specifi API? N/A

Are there any known examples of people using this API/concept? N/A

fuzyll commented 2 years ago

This is related to #2238.

psifertex commented 2 years ago

Ultimately the problem here is larger than just documentation and I'm going to edit the title accordingly. There really isn't a good workflow right now for installing native plugins. The only way to do it now is to build yourself for the version you want and install manually.

What we'd like to do is to provide better facilities (along with documentation) by which third-parties can release native plugins that are available in the plugin manager.

There's a few related issues. The first, already tracked in #2238 is support for native plugins in the plugin manager.

The second, but arguably more important issue is helping plugin authors create releases for stable releases, dev releases, and across Linux, MacOS, and Windows. I'm going to adjust the title of this issue to track creating public GitHub actions that let authors more easily build plugins this way.

cblichmann commented 1 year ago

I'm late to this issue: Building native plugins like BinExport using your build infrastructure or via a GitHub action, while obviously possible, will result in binaries without any code signatures. I'd still like to sign BinExport with the Google code-signining key, but that requires that we build internally (and that is not just a big corp being difficult :-)). So a GitHub action is useful in the general case, but will not help BinExport, unfortunately.

psifertex commented 1 year ago

No worries, that makes sense. I just got a recent build going a few minutes ago and want to see if I can drag in a few other eyeballs from V35 to see how we can make the process easier. In particular, having to manually regenerate the header was a bit of a surprise (and I'm going to follow up on my other issue I just made as a result) and I'm wondering what we might be able to do to make the process easier.

Will follow up separately with a few other semi-related things.

jrozner commented 1 year ago

If you need testers for this with projects outside of v35 I'm happy to get it setup with the msp430 architecture. This is something I'd really like.