Closed linickx closed 4 months ago
A new configuration entry all_addon_configs
with read and write permissions has been added to the map
section in the sqlite-web/config.yaml
file. This change enhances the configuration capabilities, allowing more flexible and comprehensive management of addon configurations.
File | Change Summary |
---|---|
sqlite-web/config.yaml |
Added all_addon_configs:rw to the map section |
In the land of code, where configs reside,
A new key was added, permissions applied.
With read and write, it stands so tall,
Enabling addons, one and all.
A rabbit hops, in joy it sings,
For better configs, and all that it brings.
[!TIP]
New Features and Improvements
## Review Settings Introduced new personality profiles for code reviews. Users can now select between "Chill" and "Assertive" review tones to tailor feedback styles according to their preferences. The "Assertive" profile posts more comments and nitpicks the code more aggressively, while the "Chill" profile is more relaxed and posts fewer comments. ## AST-based Instructions CodeRabbit offers customizing reviews based on the Abstract Syntax Tree (AST) pattern matching. Read more about AST-based instructions in the [documentation](https://docs.coderabbit.ai/guides/review-instructions#ast-based). ## Community-driven AST-based Rules We are kicking off a community-driven initiative to create and share AST-based rules. Users can now contribute their AST-based rules to detect security vulnerabilities, code smells, and anti-patterns. Please see the [ast-grep-essentials](https://github.com/coderabbitai/ast-grep-essentials) repository for more information. ## New Static Analysis Tools We are continually expanding our support for static analysis tools. We have added support for `biome`, `hadolint`, and `ast-grep`. Update the settings in your `.coderabbit.yaml` file or head over to the settings page to enable or disable the tools you want to use. ## Tone Settings Users can now customize CodeRabbit to review code in the style of their favorite characters or personalities. Here are some of our favorite examples: - Mr. T: "You must talk like Mr. T in all your code reviews. I pity the fool who doesn't!" - Pirate: "Arr, matey! Ye must talk like a pirate in all yer code reviews. Yarrr!" - Snarky: "You must be snarky in all your code reviews. Snark, snark, snark!" ## Revamped Settings Page We have redesigned the settings page for a more intuitive layout, enabling users to find and adjust settings quickly. This change was long overdue; it not only improves the user experience but also allows our development team to add more settings in the future with ease. Going forward, the changes to `.coderabbit.yaml` will be reflected in the settings page, and vice versa. ## Miscellaneous - Turn off free summarization: You can switch off free summarization of PRs opened by users not on a paid plan using the `enable_free_tier` setting. - Knowledge-base scope: You can now set the scope of the knowledge base to either the repository (`local`) or the organization (`global`) level using the `knowledge_base` setting. In addition, you can specify Jira project keys and Linear team keys to limit the knowledge base scope for those integrations. - High-level summary placement: You can now customize the location of the high-level summary in the PR description using the `high_level_summary_placeholder` setting (default `@coderabbitai summary`). - Revamped request changes workflow: You can now configure CodeRabbit to auto-approve or request changes on PRs based on the review feedback using the `request_changes_workflow` setting.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
I consider this quite a thing, as giving unneeded access IMHO, is something to avoid (considering security). Could you provide a concrete and common use case that would justify this change? The motivation for this is currently not provided in the PR description.
../Frenck
The blog post referenced encourages the use of public add-on config directory instead of config to improve security.
Any developers looking to enhance their security by migrating their add-on SQLLite Db's out of config into the safer add-on config directory cannot use this add-on and need to roll their own solution.
The concern about expanding footprint does make sense, but of course this add-on already has access to secrets/etc stored in config. The assumption I have made is that addons_config is a lower security risk than homeassistant config, of course I understand that could be wrong.
(Edit for typo)
The blog post referenced encourages the use of public add-on config directory instead of config to improve security.
Sure, but for this add-on specifically its goal is to access the Home Assistant database... so that isn't related to this PR at all.
Any developers looking to enhance their security by migrating their add-on SQLLite Db's out of config into the safer add-on config directory cannot use this add-on and need to roll their own solution.
That is cool, but not a concrete example.
The concern about expanding footprint does make sense, but of course this add-on already has access to secrets/etc stored in config. The assumption I have made is that addons_config is a lower security risk than homeassistant config, of course I understand that could be wrong.
They are not related at all, I'm failing to understand this reasoning. Probably because the lack of concrete examples is missing.
../Frenck
Thanks for your feedback.
this add-on specifically its goal is to access the Home Assistant database
I understand, happy to close/cancel the PR.
Proposed Changes
Update
config.yaml
map to include all add-on configs so that databases which are stored there can be opened.Related
Summary by CodeRabbit