FYI if you use the #NVDA translation addon polyglot: it stores API keys and passwords in nvda.ini in cleartext. If your NVDA log level is anything above info, those values will be written to nvda.log, even if the addon was disabled or removed at the time. I have filed an issue and PR, and am sure this will be fixed shortly. But in the meantime, if you use this addon and have filed any bugs with #nvdasr or with any other addon, and included a copy of nvda.log, you must rotate all API keys and passwords for all of your translation services. github.com/cary-rowen/polyglot/issues/20
@jscholes@FreakyFwoof If you're interested, Andre, it would be pretty easy for codex or claude to add regular expressions to detect if things that look like OpenAI, ElevenLabs, and other popular kinds of API keys are in nvda.ini, and warn the user. I suspect lots of other addons do this, when they really shouldn't. Windows has an encrypted locker, like keychain on mac, that addon authors should be using.
@fastfinge On one hand, I think NVDA add-on code quality is through the floor. Some add-ons don't even store things in the NVDA config to start with, and a "why do X when Y is easier?" attitude is rife.
On the other, I'd be pretty annoyed if I copied a portable copy of my NVDA to a new machine and couldn't use an add-on because it had stored encrypted secrets on another Windows machine. My knowledge that per-machine secrets are a best practice wouldn't stop me from being annoyed.
Then there's the issue of portable copies storing things persistently on the host machine if users were to configure such add-ons there.
These problems have solutions. But, see my first hand. @FreakyFwoof
@jscholes@FreakyFwoof Unfortunately, nvda.ini has all of its values logged when debug logging is turned on. So it doesn't matter if it's annoying or not. Passwords and API keys cannot go into nvda.ini. If they do, every user who files any bug report against NVDA or any NVDA addon has now leaked all of there API keys and passwords, in public, for anyone in the world to use. There's just no way around that.
@fastfinge@jscholes@FreakyFwoof Yeah makes me wonder how the almost certainly AI generated password manager, and password generator add-ons got approved for the store.
@dhamlinmusic@jscholes@FreakyFwoof The addon store doesn’t do any addon checks other than to make sure the addon is valid and runs, and was developed by the person submitting it.
@fastfinge The line of reasoning here only ends up painting NV Access in a bad light.
NV Access routinely requires full debug logs. NV Access hasn't provided a way to mark certain log content as sensitive. I've shifted secret storage in my own add-ons to a system that's more secure but incompatible with portable versions. If you don't like it, blame NV Access.
In reality, that mechanism should probably exist. They should probably be okay with manually or automatically redacted logs. Should, should, should.
In the meantime, there is a middle ground that your posts don't acknowledge: store the secrets outside of the config file so they don't get auto-logged, but still within the user data directory. It still won't be as secure as the system keychain, but it also won't result in your users complaining that your add-on is broken in a way which gives you an excuse to respond with a bunch of technical stuff they don't care about before abdicating responsibility.
@jscholes@dhamlinmusic@FreakyFwoof Leaked OpenAI keys are the first thing any info stealer looks for. And all the AI providers will happily let your stolen key rack up thousands of dollars. So they can’t go on disc unencrypted.
@jscholes@fastfinge@dhamlinmusic@FreakyFwoof There were junk issues filed on NVDA repo in recent days. Also, NVDA 2026.2's log handler will let add-on authors redact secrets like passwords and API keys. Worse, I came across add-ons (mostly thanks to add-on store submission review work) that stored the author's own API key in plaintext (as part of URL access), and I told authors that they just gave web scrapers access to their private info.
@jscholes@fastfinge@dhamlinmusic@FreakyFwoof Regarding debug log, I post relevant fragment(s), not the entire log. Sometimes, people claiming to have posted a "log" ends up uploading info level log. Also, whenever I require a debug log from someone, I ask them to send the log to me privately (there were instances where someone posted their full debug log on NVDA user communities, and forum admins replied with a strongly worded disapproval of that practice).
@fastfinge@dhamlinmusic@jscholes@FreakyFwoof The automated add-on store submission checks looks at add-on manifest and metadata such as version format, validity of the download link, and so on. Some community members (including veteran add-on authors) have reviewed and commented on recent add-on store submissions, pointing out issues like missing readme file, coding style, copyright and license, security issues, add-on scope, to name a few.
