You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I originally designed Buildarr, it was normal for Sonarr and Radarr to expose their API keys on their initialize.js[on] endpoints, allowing them to be dynamically fetched. To avoid doing this every time, I decided to cache them using a secrets.json file.
However, some issues have since become glaringly obvious:
The secrets.json file is difficult to manage from a security standpoint, as it is unencrypted and is not created using a secure umask by Buildarr by default at the moment
Whenever plugins have a major update and have no means of migrating older secrets model objects, older secrets.json files will cause validation errors when running the updated versions
With new versions of Arr suite applications moving to a forced-authentication model, where the API key must be provided by the client, there is simply no need to cache these credentials in a separate file anymore
Therefore, I have decided to remove management of the file in the next release. From now on, the only codepath will the "uncached" one.
Secrets models themselves will remain as they are for the moment, as they are a critical part of passing application metadata and credentials to the resource management code.
The text was updated successfully, but these errors were encountered:
When I originally designed Buildarr, it was normal for Sonarr and Radarr to expose their API keys on their
initialize.js[on]
endpoints, allowing them to be dynamically fetched. To avoid doing this every time, I decided to cache them using asecrets.json
file.However, some issues have since become glaringly obvious:
secrets.json
file is difficult to manage from a security standpoint, as it is unencrypted and is not created using a secureumask
by Buildarr by default at the momentsecrets.json
files will cause validation errors when running the updated versionsTherefore, I have decided to remove management of the file in the next release. From now on, the only codepath will the "uncached" one.
Secrets models themselves will remain as they are for the moment, as they are a critical part of passing application metadata and credentials to the resource management code.
The text was updated successfully, but these errors were encountered: