Skip to content

Move SECRETS in a new component 📦️ #45571

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

Closed
wants to merge 3 commits into from
Closed

Move SECRETS in a new component 📦️ #45571

wants to merge 3 commits into from

Conversation

casahugo
Copy link

First commit to move secret in a new component

Q A
Branch? 6.1 for features
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #44151
License MIT
Doc PR symfony/symfony-docs#...

Revert "📦 Move secret into a new component"

This reverts commit 364d22f.

📦 Move secret into a new component
@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@@ -29,6 +29,7 @@
"symfony/polyfill-mbstring": "~1.0",
"symfony/filesystem": "^5.4|^6.0",
"symfony/finder": "^5.4|^6.0",
"symfony/secret": "^5.4|^6.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be:

Suggested change
"symfony/secret": "^5.4|^6.0",
"symfony/secret": "^6.1",

Cause this component will not exists before that release.

@@ -9,7 +9,9 @@
* file that was distributed with this source code.
*/

namespace Symfony\Bundle\FrameworkBundle\Secrets;
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of moving you should copy & extend those new files by old ones to have BC.

Copy link
Author

@casahugo casahugo Feb 27, 2022

Choose a reason for hiding this comment

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

It is not a problem that the component is dependent on the FrameworkBundle?

Copy link
Member

Choose a reason for hiding this comment

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

It is, but we can do differently.
The deprecated framework-bundle classes should extend the new component’s classes, or be aliased to them (see e.g.

class_exists(BridgeAmqpTransport::class);
).

Copy link
Member

Choose a reason for hiding this comment

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

All classes are flagged @internal. As long as symfony/secret is a required dependency we don't need to use this trick.

But if we decide to make synfony/secret optional (see my comment #45571 (comment)), in that case, we should keep a BC layer in the FrameworkBundle


/**
* @author Nicolas Grekas <p@tchwork.com>
*
* @internal
Copy link
Contributor

Choose a reason for hiding this comment

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

Most likely should be still there.

Copy link
Author

Choose a reason for hiding this comment

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

Even if used in the FramworkBundle ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I also interpret it that no external project may rely on the interfaces of the class. In that case yes, usage in other libraries of the symfony package should work together with the internal tag.

@@ -9,12 +9,12 @@
* file that was distributed with this source code.
*/

namespace Symfony\Bundle\FrameworkBundle\Secrets;
declare(strict_types=1);
Copy link
Member

Choose a reason for hiding this comment

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

revert (same comment everywhere)

6.1
---

* added the component
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* added the component
* Add the component

@@ -29,6 +29,7 @@
"symfony/polyfill-mbstring": "~1.0",
"symfony/filesystem": "^5.4|^6.0",
"symfony/finder": "^5.4|^6.0",
"symfony/secret": "^6.1",
Copy link
Member

Choose a reason for hiding this comment

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

IMHO this should be an optional dependency (The FrameworkBundle does not require secrets to work).

But I'm not sure how we could provide a BC layer (migration path) without requiring it nor duplicating the code.

Copy link
Contributor

Choose a reason for hiding this comment

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

can it be also enabled/disabled via a new framework config key?

Copy link
Member

Choose a reason for hiding this comment

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

can it be also enabled/disabled via a new framework config key?

That's already the case.

The point of NOT making it a required dependency is to avoid downloading everything "just in case". Otherwise, symfony/framework-bundle will become the next symfony/symfony

Copy link
Contributor

Choose a reason for hiding this comment

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

oki I got it thx for explanations :)

Copy link
Member

@derrabus derrabus Feb 28, 2022

Choose a reason for hiding this comment

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

Let's make it an optional dependency in 7.0 then? Otherwise we would need to duplicate the code for BC and lose the advantage of the optional dependency in terms of download size.

Copy link
Member

Choose a reason for hiding this comment

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

@derrabus agreed, but how triggering a deprecation if the user did not require the deps. Otherwise, bumping symfony to 7.0 will uninstall symfony/secrets

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me

Copy link
Member

Choose a reason for hiding this comment

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

I think, we've had similar problems when we removed messenger transports into bridge packages. How did we solve this issue back then? 🤔

Copy link
Member

Choose a reason for hiding this comment

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

We made messenger require the bridges (hard dep) until 6.0

{
"name": "symfony/secret",
"type": "library",
"description": "Provide a vault to keep sensitive information secret",
Copy link
Contributor

Choose a reason for hiding this comment

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

what bout adding some keywords as well?

@chalasr chalasr modified the milestones: 6.1, 6.2 May 8, 2022
@94noni
Copy link
Contributor

94noni commented Jul 14, 2022

@casahugo hey any news on this PR ? Thank you

@nicolas-grekas
Copy link
Member

I'm sorry to come that late on the proposal but I don't feel like we should add it to Symfony.
Creating a new component would increase the maintenance and the responsibility of the project and I don't think this is desired on this topic.

I created a repository to extract the implementation of the symfony secrets. I just copied the code but it's not a viable long term alternative: casahugo/secrets

I like that and I think that's the way to go. OSS dynamics FTW.

👎 on my side.

@AndreasA
Copy link
Contributor

AndreasA commented Aug 2, 2022

@nicolas-grekas would it at least be possible to remove the @internal from the secret vault classes? that way they could be used directly, even though the full framework would need to be downloaded?

@nicolas-grekas
Copy link
Member

Would work for me, please send a PR to have a discussion about this.

@AndreasA
Copy link
Contributor

AndreasA commented Aug 3, 2022

@nicolas-grekas Ok. Target branch 6.2?

@nicolas-grekas
Copy link
Member

6.2 yes

@AndreasA
Copy link
Contributor

AndreasA commented Aug 9, 2022

@nicolas-grekas Great. Might take me a few weeks to get to it but I think a few weeks to find the time but I guess it doesn't matter as long as it happens before the next LTS release 😄

@casahugo casahugo deleted the secret-component branch August 15, 2022 11:51
nicolas-grekas added a commit that referenced this pull request Sep 12, 2022
…ctly outside Symfony (AndreasA)

This PR was squashed before being merged into the 6.2 branch.

Discussion
----------

[FrameworkBundle] Allow secrets vaults to be used directly outside Symfony

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

This PR removes the internal tag from the secrets vaults.

This allows developers to use them directly without the need to use Symfony config etc. They still have to install the whole framework bundle but that just means an overhead during download, they are still able to directly instantiate the vault using `new SodiumVault(....)` for instance.

Furthermore, by removing internal from the AbstractVault, it is possible to add a custom vault and specify it replacing the `secrets.vault` service for instance.

See ticket: #44151
and previous PR: #45571

Commits
-------

df953f0 [FrameworkBundle] Allow secrets vaults to be used directly outside Symfony
symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Sep 12, 2022
…ctly outside Symfony (AndreasA)

This PR was squashed before being merged into the 6.2 branch.

Discussion
----------

[FrameworkBundle] Allow secrets vaults to be used directly outside Symfony

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

This PR removes the internal tag from the secrets vaults.

This allows developers to use them directly without the need to use Symfony config etc. They still have to install the whole framework bundle but that just means an overhead during download, they are still able to directly instantiate the vault using `new SodiumVault(....)` for instance.

Furthermore, by removing internal from the AbstractVault, it is possible to add a custom vault and specify it replacing the `secrets.vault` service for instance.

See ticket: symfony/symfony#44151
and previous PR: symfony/symfony#45571

Commits
-------

df953f038e [FrameworkBundle] Allow secrets vaults to be used directly outside Symfony
symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Jul 28, 2023
…ctly outside Symfony (AndreasA)

This PR was squashed before being merged into the 6.2 branch.

Discussion
----------

[FrameworkBundle] Allow secrets vaults to be used directly outside Symfony

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

This PR removes the internal tag from the secrets vaults.

This allows developers to use them directly without the need to use Symfony config etc. They still have to install the whole framework bundle but that just means an overhead during download, they are still able to directly instantiate the vault using `new SodiumVault(....)` for instance.

Furthermore, by removing internal from the AbstractVault, it is possible to add a custom vault and specify it replacing the `secrets.vault` service for instance.

See ticket: symfony/symfony#44151
and previous PR: symfony/symfony#45571

Commits
-------

df953f038e [FrameworkBundle] Allow secrets vaults to be used directly outside Symfony
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RFC] Move SECRETS in a new components📦️
10 participants