In the real world they are typically managed separately from the code base and often by people who may not be programmers (I realise your use case is simpler than the typical one).

You're still keeping sensitive information in your code base, so that's not a configuration file

Ah yes...I see the difference...

However, I don't see what practical difference it makes assuming there is no encoding going on. If the code has access to the file that holds the sensitive information then surely the developer has access to the contents of that file either directly or through their code. I feel I am missing something here.

In the 'real' code for the module, the only things that are pulled out of the module code are the database schema name, username and password. I only took table names out to share it in a public place for security purposes. Currently these are contained in a Perl module that does nothing but hold this kind of information and it would be good if I could amend this to a 'better', more secure arrangement especially as I am refactoring one of the sites that needs this information and now would be the perfect opportunity to do it.

If the code has access to the file that holds the sensitive information then surely the developer has access to the contents of that file either directly or through their code.

The developer is not developing on the production system^* and therefore does not have access to either the production DB credentials or indeed the production DB itself. Putting this in a config file which is just data and not something to be executed allows the developer to test on the dev system with the dev DB credentials and the dev DB without any leak of sensitive information. All the code may be shared between development and production quite safely and only the config files (which are now not code) are kept separately.

^* If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production.

---

🦛