Skip to content

Conversation

@ekzhu
Copy link
Contributor

@ekzhu ekzhu commented Mar 14, 2025

To prevent accidental export of API keys

@codecov
Copy link

codecov bot commented Mar 14, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.77%. Comparing base (84c622a) to head (3c1ac4a).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5939      +/-   ##
==========================================
+ Coverage   75.54%   75.77%   +0.22%     
==========================================
  Files         191      191              
  Lines       13100    13100              
==========================================
+ Hits         9897     9926      +29     
+ Misses       3203     3174      -29     
Flag Coverage Δ
unittests 75.77% <100.00%> (+0.22%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
@ekzhu ekzhu requested a review from victordibia March 14, 2025 04:24
@ekzhu ekzhu merged commit a4b6372 into main Mar 14, 2025
56 checks passed
@ekzhu ekzhu deleted the ekzhu-secret branch March 14, 2025 04:29
ekzhu added a commit that referenced this pull request Mar 14, 2025
To prevent accidental export of API keys
assert serialized_config
assert "sk-password" not in serialized_config
client2 = AnthropicChatCompletionClient.load_component(config)
assert client2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hold on, did you assert that api_key==sk-password. How would the model know how to load it back?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention is to prevent the key from exported and loaded back directly without user specifying the API key on the config first.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense in theory, but what about autogenstudio if a user specifies a key it will be lost as soon as it's saved.

Copy link
Collaborator

@victordibia victordibia Mar 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok .. let us step back for a second.

  • Core issue that his PR addresses is that whenever dump_component() is called, fields like keys (for some model clients) get dumped too. This can lead to key security issues.
  • This PR, makes those field Secrets and hence they are not dumped.

The side effect is that anyone who is loading a dumped component (with secrets) will get an error now when they load the component (secrets no longer available).


by @EItanya For the meantime I think we need to revert until a better solution is reached, unless we just tell everyone they have to use the OPENAI_API_KEY env var


A potential middle ground is that we parameterize dump_component(secrets=true) and it is false by default. If people really want to dump their secrets, they set it to true. WDYT @EItanya @ekzhu ?

This seems to be slightly different from the error in #5944 (it seems somwhere down the stack we will need to convert SecretStr to str before giving it to the model client). I am still investigating.
Edit: fix for #5944 is in #5939

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a parameter secrets=True is a good middle ground. Right now, it is a security issue that we need to fix for the default case.

Copy link
Contributor

@EItanya EItanya Mar 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally understand where the requirement is coming from.

I agree that in the default case this will be totally fine because the model is loaded in from some datastore, run, and thrown away.

But I still think there are questions that need to be answered here. Let's say a GroupChat is paused, so save_state is called, how will it pick back up? You're saying in that instance we pass secrets=true so that it can be picked back up?

Checkpointing is one of the coolest potential features of Autogen so just wanna make sure we account for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to throw this in to the mix, I feel like secrets should be able to be specified externally and "referenced" in a config. For example in home assistant you can use the !secret directive to load a secret https://www.home-assistant.io/docs/configuration/secrets/

@EItanya
Copy link
Contributor

EItanya commented Mar 14, 2025

I think this was prematurely merged, I thought about doing this as well, but realized it was a problem for loading components

@ekzhu
Copy link
Contributor Author

ekzhu commented Mar 14, 2025

I think this was prematurely merged, I thought about doing this as well, but realized it was a problem for loading components

Perhaps we should make it a parameter?

@EItanya
Copy link
Contributor

EItanya commented Mar 14, 2025

Perhaps we should make it a parameter?

Secrets in config are always difficult, but they still need to be able to be loaded. I've seen other projects create secret_sources which can load from files, or other more secure sources rather than the config itself.

For the meantime I think we need to revert until a better solution is reached, unless we just tell everyone they have to use the OPENAI_API_KEY env var

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

5 participants