Moving sensitive variables to a .env file

[pakricard]

In an environment where a company uses webERP and needs to hire external developers (could be my case in the coming months), besides transferring the private repository in GitHub to an organization, set teams, members, access rights, etc. another important requirement is the protection of sensitive information.

I have been investigating a bit, and it appears that the current “best practices” is the extensive use of .gitignore and the use of environment variables (.env), using a library as phpdotenv, via composer.

According to my readings, we should store all sensitive information in a .env file (at the root of the webERP installation) and the config.php, instead of

$DBPassword = 'My_Real_Password';
should have something like

$DBPassword = $_ENV['DBPASSWORD'];
This way, the .env file resides in the server and never ever added to Git.

So, I am asking if it seems the sensible way to go for the standard webERP, or would be an overkill and the community prefers to stay with the config.php.dist solution that, I guess, works OK for most situations.

R

[dalers]

Hi Ricard, why is the process we are using to develop webERP not sufficient? I believe a public or private repo in a personal GitHub account will be sufficient for most basic use cases. A git repo is easily hosted on your own server (only requires ssh login and to generate an ssh key pair) and GitHub can be avoided entirely if you wish (I did this for a recent embedded software project when I hired a remote contractor).

For a small dev team I'm satisfied with the status quo (by "small", I mean 3-5 devs with no "departments" or supervisors other than you), but also admit I don't understand the security issues that using .gitignore and .env files would resolve. I understand in a general way that they can be used for more efficient devevelopment with reduced confusion and errors, but I'm not familiar with specific security issues they resolve. Can you elaborate on your concerns?

[pakricard]

As example, if I share with you now my private GitHub repo where I have my customized webERP code, you will gain access to the DB passwords, IP of the server, etc. Information you most probably won't need to develop some script (or fix a bug), but is a breach of security for my company, as these sensitive pieces of info are distributed outside the organization. I could share the sensitive info regarding the test DB, but not the production one.

So, the goal is to isolate the sensitive info from config.php, without hiding too much to the developer.

Open question for those of you consulting / developing webERP for external companies: How do the companies protect the sensitive data from you?

Now, while writing this, I think it is probably easier having a file ConfigSecrets.php storing the real values of these variables and NOT adding this file to git would do the trick, without adding an extra dependency (.env).

R

[dalers]

So, the goal is to isolate the sensitive info from config.php, without hiding too much to the developer.

I don't understand why there is a need to share a config.php file with sensitive information to developers. I don't keep my production config.php file in my repo.

How do you envision the contract developers will interact with your private repo? Will they fork your private repo in GitHub, clone their fork to their dev machines and issue PRs from their GitHub forks back to your (origin) repo? Will they clone directly to their dev machines from your private repo? Will they they commit directly to your private repo?

For me., I would provide a test database of some sort to the developers, who would setup a local MariaDb db on their dev systems and create their own config.php file with the credentials. The test database would be the minimum needed for testing the developed feature, with no confidential information (such as actual company employees and passwords). If it's not possible or practical to create a test database, I would need to be very careful who I hired (I would have NDAs of course but more for formal legality than of practical benefit).

[timschofield]

I'm not sure I see the problem that this is trying to resolve. In my opinion, the config.php file should only be available on the production server (and of course any server backups). When sharing the code, such as on https://github.com/timschofield/webERP config.php is omitted.
However, that said, I don't see any problems with this, and I suppose congregating all these in one place make it easier to maintain them.

Tim

[pakricard]

I get your point, and it is probably an overkill. As I see it, in config.php we set some non-critical variables, and some are critical (DB names and passwords at least).

Checking more in detail, my repository is still tracking config.php, even if .gitignore contains the line

# Only config.distrib.php is to be distributed
/config.php

The possible cause for this is that the file was tracked before being ignored: If config.php was committed to the repository before adding it to .gitignore, Git will continue to track it. The .gitignore only prevents untracked files from being added, apparently.

I will just move DB names and passwords to another file an ignore that file via .gitignore.

Thanks for sharing your POV's
R

[timschofield]

Hi, running

git rm --cached config.php

and then committing this change should stop git tracking this file (assuming it is now in your .gitignore file)

Tim

[dalers]

Iiuc this will only remove config.php from head but not delete it from the repo entirely and it can still be recovered with the sensitive data if one looks for it. Removing the file from the repo entirely is possible but passwords in use should still be changed because of course the file will still exist in any prior clones.

From Gemini:

Remove from Git History (Permanent Purge)

If you accidentally committed sensitive data (like a password) or a very large file, standard deletion will not remove it from previous commits.

To erase it entirely from history:

Tool: Use git-filter-repo, which is the recommended modern tool for this task.

Command: git-filter-repo --path <file_path> --invert-paths

Warning: This rewrites history. All collaborators will need to re-clone the repository after you force-push the changes.

[pakricard]

Many thanks! Will try today.
R