Skip to content

[RFC] Move SECRETS in a new components📦️ #44151

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
casahugo opened this issue Nov 20, 2021 · 12 comments
Closed

[RFC] Move SECRETS in a new components📦️ #44151

casahugo opened this issue Nov 20, 2021 · 12 comments
Labels
FrameworkBundle RFC RFC = Request For Comments (proposals about features that you want to be discussed)

Comments

@casahugo
Copy link

Description

I really like the principle of symfony secrets, so much that I would like to use it with other frameworks.

In my case, I would like to use it with phalcon and php 7.1. The problem is that I don't need to have all the components of the FrameworkBundle.

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: https://github.com/casahugo/secrets

Thank you for your work.

Example

Create new repository symfony/secrets (or symfony/vault) in packagist to run the command

composer require symfony/secrets

Extract the files

├── composer.json
├── LICENSE
├── phpunit.xml.dist
├── README.md
├── src
│   ├── AbstractVault.php
│   ├── Command
│   │   ├── SecretsDecryptToLocalCommand.php
│   │   ├── SecretsEncryptFromLocalCommand.php
│   │   ├── SecretsGenerateKeysCommand.php
│   │   ├── SecretsListCommand.php
│   │   ├── SecretsRemoveCommand.php
│   │   └── SecretsSetCommand.php
│   ├── DotenvVault.php
│   └── SodiumVault.php
└── tests
    ├── DotenvVaultTest.php
    └── SodiumSecretTest.php

composer.json

{
    "name": "symfony/secrets",
    "license": "MIT",
    "require": {
        "php": ">=7.2.5",
        "paragonie/sodium_compat": "^1.17",
        "symfony/console": "^4|^5"
    },
    "require-dev": {
        "phpunit/phpunit": "^7.5.20",
        "symfony/dotenv": "^4|^5"
    },
    "autoload": {
        "psr-4": {
            "Symfony\\Secrets\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Symfony\\Secrets\\Tests\\": "tests/"
        }
    }
}

In https://github.com/symfony/framework-bundle edit composer.json to avoid a BCBreak.

...
"require": {
        ...
        "symfony/secrets": "~1.0"
 }
@jderusse jderusse added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Nov 21, 2021
@jderusse jderusse changed the title [Secrets] Extract in other repository 📦️ [RFC] Extract SECRETS in other repository 📦️ Nov 21, 2021
@jderusse jderusse changed the title [RFC] Extract SECRETS in other repository 📦️ [RFC] Move SECRETS in a new components📦️ Nov 21, 2021
@derrabus
Copy link
Member

Thank you for your proposal. This issue is open for quite some time now and I think we should decide on it.

I think it would make sense to extract the secrets-related classes into a dedicated component to make it reusable.

Regarding your use-case however:

In my case, I would like to use it with phalcon and php 7.1

If a dedicated component is released, it would as of now be released as part of Symfony 6.1 which requires PHP 8 already. If a PHP 7.1 backport is what you need, your fork would be the way to go.

@AndreasA
Copy link
Contributor

AndreasA commented Jan 31, 2022

@derrabus For me, it would be enough to extract them for future Symfony versions and PHP versions. It would really be helpful to use it without the framework-bundle, as a separate component.

Not sure about others but extracting them is definitely a new feature so not something that needs to be part of 5.4
Of course, the @internal phpdoc has to be removed then 😄

@chalasr
Copy link
Member

chalasr commented Jan 31, 2022

Makes sense to me as well.
For the one who will be working on this, consider having a look at #39344.

@wouterj
Copy link
Member

wouterj commented Jan 31, 2022

Btw, I'm not sure if a new component is needed for this. Wouldn't it make more sense to integrate this with the Dotenv component (if we want to separate it from the framework bundle)?

@derrabus
Copy link
Member

@wouterj possibly

@chalasr
Copy link
Member

chalasr commented Jan 31, 2022

I wouldn't make secrets a Dotenv concern. Dotenv's job is to handle dotenv files, while secrets don't necessarily have to be in dotenv files. I think a dedicated component makes sense even if it is small at first, that would open more possibilities regarding how secrets can be loaded and dumped.

@AndreasA
Copy link
Contributor

AndreasA commented Jan 31, 2022

Hmm. strictly speaking I could use the SodiumVault without ever needing DotEnv at all. This might be different for the DotEnv vault but the sodium would work standalone and DotEnv itself doesn't necessarily require the vaults.

EDIT: Actually, even the DotEnvVault can be used independently from DotEnv.

@AndreasA
Copy link
Contributor

Any news regarding when the component will be created? Will it be ready for 6.2?

@wouterj
Copy link
Member

wouterj commented Feb 23, 2022

@AndreasA Symfony is open source, there is no plan. If you're motivated to contribute this to Symfony, feel free to start a pull request.

@AndreasA
Copy link
Contributor

AndreasA commented Feb 23, 2022

@wouterj OK. I might do so but how would I best go about creating a separate component for it? and what should the name be? otherwise it makes no sense 😄 I guess I would move it into src/Symfony/Component, e.g. src/Symfony/Component/SecretVault and the name could be symfony/secret-vault?

should the current classes still be available at the beginning (for BC) or can I just remove them altogether in this case as they are marked internal anyway?

@wouterj
Copy link
Member

wouterj commented Feb 23, 2022

Don't worry too much about the PR not being perfect at the start - almost no PR is (especially the ones introducing new components). As long as there is a starting point to the discussion, it's great.

This means the most important thing to demonstrate is: the classes as-is are usable as a standalone component (e.g. they don't depend on things from the bundle or framework).

I would suggest following the description of this issue as start: symfony/secret And then move the classes to this directory in src/Symfony/Component. For internal classes, this is all that is needed. Any non-internal class needs a BC layer - but we can help with that if you open the PR :)

You also need to copy some basic files from another component - e.g. README, LICENSE, phpunit.xml.dist, etc. We have a CI check to see if all metadocuments are copied correctly, so even here you don't have to worry too much - CI will tell you if you're missing something.

@nicolas-grekas
Copy link
Member

Closing as explained in #45571 (comment), thanks for proposing.

@nicolas-grekas nicolas-grekas closed this as not planned Won't fix, can't repro, duplicate, stale Jul 29, 2022
nicolas-grekas added a commit that referenced this issue 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 issue 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 issue 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
Labels
FrameworkBundle RFC RFC = Request For Comments (proposals about features that you want to be discussed)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants