Patch #41331
open
Gemfile patch: fix for handling (security related) ERB expressions in database.yml
0%
Description
Redmine installations that use ERB expressions (like `<% %>`) in their database.yml file may encounter issues during parsing.
To address this, we've applied a patch to the Gemfile that ensures compatibility when handling files containing such special characters, thus preventing common errors.
This patch modifies the way the database.yml is processed, ignoring lines that contain ERB expressions.
This is particularly useful for installations where the database configuration might contain sensitive data managed via Rails' encrypted credentials or other mechanisms that use ERB.
Index: Gemfile
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/Gemfile b/Gemfile
--- a/Gemfile (revision 277728afc979a7123eef8d1a8ac54d74c235c5fc)
+++ b/Gemfile (date 1727590462090)
@@ -61,7 +61,7 @@
require 'yaml'
database_file = File.join(File.dirname(__FILE__), "config/database.yml")
if File.exist?(database_file)
- yaml_config = ERB.new(IO.read(database_file)).result
+ yaml_config = ERB.new(IO.readlines(database_file).reject { |line| line =~ /<%.*%>/ }.join).result
database_config = YAML.respond_to?(:unsafe_load) ? YAML.unsafe_load(yaml_config) : YAML.load(yaml_config)
adapters = database_config.values.filter_map {|c| c['adapter']}.uniq
if adapters.any?
Files
Updated by Holger Just 6 days ago
The patch would remove the ability to specify ERB-evaluated data in the database.yml file which may be relevant to the parsing done in the Gemfile
With encrypted credentials as proposed by you in How_to_use_encrypted_database_credentials, the credentials are not available "outside" of Rails, such as when the Gemfile is evaluated at the very beginning of the Rails startup. In any case, I don't believe that using encrypted credentials for the password in database.yml increases the security of the entire system much, as Rails still needs runtime-access to the key used to encrypt the plain password. Potential attackers which may read the unencrypted password from the database.yml could then also just read the key and the encrypted password. The only way this could be more secure is
- if you HAVE to store the encrypted password with your code in the same repository rather than setting it just on the server
- if you have a way to secure the key
Instead of this approach, a more secure solution could be to set the password in an environment variable in a way that the raw data is not readable on disk by the application process. This may require some workarounds to start Redmine to ensure that the environment variables are available there.
Finally, while I can see the desire to encrypt some sensitive data such as passwords, I believe that the approach proposed here does not sufficiently resolve the issue and instead may cause further parsing errors in the Gemfile.