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
An alpha version of my polyglot fork is now available. Note that this is alpha quality software, as of yet. The key changes: * stores credentials in the Windows Credential Manager * adds engines: LibreTranslate, Argos Translate, Naver Papago, and Lara Translate * no longer attempts to download chrome runtimes on secure screens * no longer attempts to download Argos models on secure screens * makes writing the translation cache thread-safe, and batches writes for speed * deletes all API keys and config values when uninstalled * no longer attempts to translate strings that are only numbers, punctuation, or emoji: both for speed, and a tiny boost in privacy * removes all engines that depend on the NVDACN infrastructure * removes shared API keys shipped with the addon * removes someone's private ollama server that was a hardcoded default for some reason
The road to 1.0: * lots and lots of real-world testing to find the bugs that almost certainly exist * get API keys for all of the available services so I can test them locally * build a test harness using GitHub actions that tests all of the services for API changes and ensures they all continue working * set up GitHub secrets, etc, so I have a CI/CD environment that can actually test all 18 API's
@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.
@jscholes@FreakyFwoof Now, we can argue about if NVDA debug logging should be spitting config values for disabled addons into nvda.log or not. But they are doing exactly that. So unless they stop, we have no other options.
@fastfinge that repo owner needs a smack. upside the head. As soon as I saw them mention DPAPI I was like no, DPAPI is not the way forward, bozo! I don't need to say it though because you did it for me. Some people need to actually research what something is, how it works, etc. if they had, they wouldn't have even mentioned it, but in the grand scheme of things their addon, not yours, or mine, but it doesn't mean we can't bitch a plenty.
@fastfinge NVDA 2026.2 will redact such secrets where it detects them, but it's a good reminder that most users should have logging level set to info most of the time. If recreating a bug for an issue and if you "restart NVDA with debug logging", it will go back to your previous level (info) next restart
@fastfinge Yes and it looks like there's some discussion in that original issue on ways for the add-on to address that, even if finding a workable solution is more complex than it may at first seem :)
@NVAccess Yes, the original issue in this thread and pr are mine. Unfortunately doing security right means adding complexity, the authors dislike of the fact not withstanding. I’m hoping this can be resolved without me needing to fork and maintain a version that meets security requirements.
