update ida-settings api

[mr-tz]

closes #2736

currently untested (due some other local issues)

@williballenthin is this how envisioned this?

Checklist

• No CHANGELOG update needed

• No new tests needed

• No documentation update needed

[gemini-code-assist]

Summary of Changes

Hello @mr-tz, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant refactoring to the way user settings are managed within the IDA Pro plugin for capa. By abstracting the direct interaction with ida_settings.IDASettings into dedicated helper functions, the change aims to standardize setting retrieval and storage. This update improves maintainability and ensures a consistent approach to handling plugin configurations, addressing issue #2736.

Highlights

• Settings API Refactor: The direct use of ida_settings.IDASettings has been replaced with a new helper function get_setting for retrieving plugin settings and ida_settings.set_current_plugin_setting for storing them.
• Centralized Setting Access: All instances of accessing user settings (e.g., rule path, author, scope, analysis options) now use the new get_setting helper, promoting a more consistent approach.
• Changelog Update: The CHANGELOG.md file has been updated to reflect this API change for the IDA plugin.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the ida-settings API usage throughout the IDA plugin, replacing direct dictionary-style access with the new get_current_plugin_setting and set_current_plugin_setting functions. A helper function get_setting has been added to provide default values, which is a nice abstraction.

The changes are correct and also fix a bug in slot_settings where tuple unpacking was used incorrectly for assignment. I've suggested a small improvement in that same function to enhance readability and maintainability by unpacking the returned values into named variables before setting them.

Overall, this is a good refactoring that improves the code's consistency with the updated API.

[mike-hunhoff]

This looks reasonable to me, but I'm interested in hearing from @williballenthin if this is the intended use. I haven't had a chance to look into the recent changes to ida-settings.

[williballenthin]

as the API, yes exactly.

we'll also need to register the settings with the plugin, which allows:

1. validation, and
2. hcli to prompt during installation

unfortunately the only doc I have on this today is the example here: https://hcli.docs.hex-rays.com/reference/packaging-your-existing-plugin/, which is one of the reasons i hadn't proposed this PR yet 😉 that's ok though.

there's also the GUI settings manager now too, so perhaps capa could use that instead of its own settings dialog?

[mr-tz]

should we add this change before a new release or is it fine to adjust this afterwards as well?

[mr-tz]

Would the plugin registration look like this? I guessed on the "integer" type.

"settings": [
  {
    "key": "rule_path",
    "type": "string",
    "required": true,
    "default": "",
    "name": "rule path",
    "documentation": "capa rules directory",
  },
  {
    "key": "rulegen_author",
    "type": "string",
    "required": false,
    "default": "<insert_author>",
    "name": "rule author",
    "documentation": "capa rule author",
  },
  {
    "key": "rulegen_scope",
    "type": "string",
    "required": false,
    "default": "function",
    "name": "rule scope",
    "documentation": "capa rule scope",
  },
  {
    "key": "analyze",
    "type": "integer",
    "required": false,
    "default": "0",
    "name": "analysis option",
    "documentation": "no auto analysis (0), auto analyze on plugin start and load cached results (1), auto analyze on plugin start and ask to load cached results (2)",
  },
]

[williballenthin]

should we add this change before a new release or is it fine to adjust this afterwards as well?

I'd suggest that capa do a release before using the new ida-settings API, since it should work now with the legacy API.

I think the ida-settings API should work, but given that I haven't even documented it yet, it's not fair to risk a capa release on it. If you want to push forward, thats ok, too, things should be fine, but I don't think it's any sort of rush.

[williballenthin]

Would the plugin registration look like this? I guessed on the "integer" type.

I think this looks pretty good, though for the analysis options, we could do something like:

{
    "key": "analyze",
    "type": "string",
    "required": false,
    "default": "none",
    "name": "auto-analysis",
    "choices": ["none", "auto", "prompt"],
    "documentation": "whether to analyze when first opening the plugin: 'never', 'auto', and 'prompt'",
  },

[mike-hunhoff]

should we add this change before a new release or is it fine to adjust this afterwards as well?

I'd suggest that capa do a release before using the new ida-settings API, since it should work now with the legacy API.

I think the ida-settings API should work, but given that I haven't even documented it yet, it's not fair to risk a capa release on it. If you want to push forward, thats ok, too, things should be fine, but I don't think it's any sort of rush.

Second, let's not rush this with the next capa release.