Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exposed OpenRouter API Keys? Secret Scanning Alert from GitHub #981

Open
cybersader opened this issue Feb 2, 2025 · 4 comments
Open

Exposed OpenRouter API Keys? Secret Scanning Alert from GitHub #981

cybersader opened this issue Feb 2, 2025 · 4 comments

Comments

@cybersader
Copy link

I use Obsidian Git and tried pushing to my repo and was alerted of the use of two OpenRouter API Keys prepended with "sk-or-v1" in them in the code. Let me know if these are placeholders or false positives. I usually put the data.json parts in my gitignore since that's usually where custom API keys go. However, it seems like these are being baked into the source code itself.

@cybersader cybersader changed the title Exposed OpenRouter Keys? Exposed OpenRouter API Keys? Secret Scanning Alert from GitHub Feb 2, 2025
@brianpetro
Copy link
Owner

I would exclude the .smart-env/ folder in your gitignore to ensure data protection and also to prevent any sync issues. Since the plugin implements the Smart Environment concept, settings that aren't specific to Obsidian (including API keys), may be stored in .smart-env/smart_env.json.

If it seems like it's in the source code, the Open Router keys could just be some keys I included so new users could easily try the Smart Chat (I too get a lot of those warnings about my keys being exposed seemingly anytime someone forks the project).

🌴

@huyz
Copy link

huyz commented Feb 3, 2025

I just checked my .gitignore and .smart-env has already been added.

@brianpetro
Copy link
Owner

As long as your .smart-env folder isn't being committed to GitHub then the only keys that might trigger this warning are compiled into the plugin code 🌴

@cybersader
Copy link
Author

If the exposed key is merely one that's a sort of "demo" key, then that's not as bad. I'm sure you're well aware of the risks of exposing API keys "to the kingdom." If sensitive data can be exposed this way, then it is problematic. I guess there would need to be full authentication to get around this sort of thing. I haven't developed a plugin myself yet, so I'm not aware of how hard it is to do such a thing. I would just make sure that any free testing keys are still limited in the scope of access they have. Then again, may not be a huge risk. Thanks for the clarification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants