@nicolas-grekas as previously discussed. This should be everything.

can you add a line in the changelog file of the bundle please?

Done. Hopefully the changelog entry is fine this way?

@nicolas-grekas Do I need to change anything else because the bot added the "needs work" tag?

Thank you@AndreasA.

Sorry to comment on a closed ticket but I have to say that I'm personally not very satisfied with the path we took here:

• A bundle isn't meant to provide logic or any public code, should rather just be glue
• What if I don't want secrets e.g. because I have my own setup for those? Having it always enabled kinda goes against some of the motivations behind flex
• The cost of moving these classes from internal to a new component is just the same as opening these classes modulo the cons listed above

All in all, I fail to see what prevents us from opening this API the same way we usually do it for other parts of the framework.
I hope we can reconsider before it gets released.

I can reply for myself: I rejected#45571 because I've no idea which part of which domain those classes would cover. Creating a new component sends a message that this new lib will solve a useful problem. But I honestly don't know the boundaries of a new symfony/secrets component. Those classes look a bit "random" to me from a domain coverage pov. I preferred not opening a pandora box by creating a component that would raise false expectations - thus be deceptive. Also, I don't plan to invest my time into defining+implementing a "secrets" domain.
On the other side, if making those classes non-internal helps some ppl, I've no objection to do so because I know we can deal with the BC promise quite easily on them.

Personally, I would also have preferred a component but this way there are already some possibilities:

• I know shop system that uses Symfony Framework and the bundle loading for plugins. However, to determine active plugins they initialize the database connection before the kernel is finished loading. They provide an option to provide the db URL through external code. So by the SodiumVault etc. not being internal, I can still use them to provide the DB URL.
• With AbstractVault not being internal, it would be possible to replace it with a custom implementation, e.g. to load secrets from 1Password or similar. Though it probably will be easier to use the default vault and provide the secrets key using 1Password in such a scenario but in theory it would be possible.
• The secret vaults can be used outside of Symfony altogether, even if the overhead of installing unnecessary stuff is necessary.
  • However, one could relatively easily automatically create a custom package automatically through git subtree, so that would be gone as well.

One thing that I am not sure about is, if the commands should also remove the@internal tag, though I don't think it is necessary as those are quite specifc to the framework bundle implementation and would make BC promise probably more tricky.

load secrets from 1Password or similar

It could be interesting to contribute those back here. If we have many of them, then maybe a new component would make sense, as a generic way to plug in specific vault implementations.

create a custom package automatically through git subtree

if that's the plan, then we can keep the@internal annotation!

@nicolas-grekas regarding the custom package, that is currently not the plan - at least not by me 😄

Just mentioned it. And I think it would be easier without internal because then it is BC safe and easier to extract new versions, with internal it might break in the future 😄 but not that important.

The other things though are still valid. and they do help. As mentioned in the worst case, one can now use the vaults by requiring the framework-bundle, even if they only use the vaults.

Regarding additional vaults, not currenlty planned, but maybe in the future. In which case I might create a PR, once it works.

@AndreasA

We are also loading secrets from aws secrets manager but it is encapsulated in a service which is loaded by anEnvVarLoader

See

@faizanakram99 I know that it is possible to use env var processors to do so, I am doing something similar in another project. I just think it would be nicer to use a corresponding vault as that would also allow thelist command to show those secrets etc. but yes strictly speaking it isn't necessary.

Thanks for the tip anyway.