Bug 2338934

But %verify(not size filedigest mtime) will hide *any* change performed to /etc/phpMyAdmin/config.inc.php - which I treat as bad/wrong. The %post only exists, because the assumed majority of phpMyAdmin users is too lazy to configure phpMyAdmin properly. There is no difference if a script performs this, or the user/administrator. And the %post is actually a configuration change, thus I personally treat "S.5....T." as valid.

Hi !

Can you not patch the config file and add a "require_once '/etc/phpMyAdmin/config.secret.inc.php';" ?
And generate it, like we do for the Docker version: https://github.com/phpmyadmin/docker/blob/5043535036cd122dbce41184b2794a9ac2ff0235/docker-entrypoint.sh#L4-L8

William,
phpMyAdmin team member

Which benefit do you see by having yet another configuration file?

> Which benefit do you see by having yet another configuration file?

It would be easier to know if the user did change the initial config or not ?
Is that not the warning that you are trying to remove ?

If "S.5....T." is the default state, then displaying this file as modified makes RPM verification less useful in this particular case. Either way, we can't tell from rpm -V if the admin has modified this file or not, and whether it needs review during upgrades.

To my understanding, %verify(..) only affects the output of rpm -V, but not what happens to the file during upgrades or removals. I think even with %verify(not..) and without manual changes by the admin, .rpmnew and .rpmsave would be created. So overall, I agree that showing "S.5....T." hides less information than not showing it.

Taking a step back, compared to the current situation, would not tracking config.inc.php at all and creating it in %post have any disadvantages or violate any rules? phpMyAdmin works without it and just displays a warning about the missing secret key. Arguably, that makes it a drop-in configuration file, as it's not included in the source package, albeit with a fixed name..

William's solution sounds good to me; the benefit is a clean separation of
- configuration added by maintainer,
- automatically generated configuration,
- and manual configuration,

w.r.t. rpm file tracking.

(In reply to William Desportes from comment #4)
> Is that not the warning that you are trying to remove ?

That's what the bug reporter would like to see. Any chance that "require_once '/etc/phpMyAdmin/config.secret.inc.php';" (or similar) makes it upstream?

For reference in Debian: https://sources.debian.org/src/phpmyadmin/4%3A5.2.1%2Bdfsg-1/debian/postinst/#L64-L81

Loaded by https://sources.debian.org/src/phpmyadmin/4%3A5.2.1%2Bdfsg-1/debian/conf/config.inc.php/#L40-L42

You can also introduce /etc/phpmyadmin/conf.d
Supported by Debian and Docker now: https://sources.debian.org/src/phpmyadmin/4%3A5.2.1%2Bdfsg-1/debian/conf/config.inc.php/#L159-L162


> Any chance that "require_once '/etc/phpMyAdmin/config.secret.inc.php';" (or similar) makes it upstream?

I do not think so, for now each distributor does it the way that they want. Until now phpMyAdmin never does edit to it's own config.
Except generating an initial config in the web setup.

Personally, I'm not a fan of patching config.inc.php. Shouldn't libraries/vendor_config.php be able to cover the include behaviour without patching config.php on downstream side? Aside of this...not sure if Remi has some opinion here.

Well config.inc.php does not even exist in the distributed version, so I was a bit incorrect in using the term "patching".
Users create it manually.
But as you said you can can patch the vendor config to load another file: https://sources.debian.org/src/phpmyadmin/4%3A5.2.1%2Bdfsg-1/debian/patches/debian.patch/#L52

Lets say /etc/phpMyAdmin/config.vendor.inc.php that you will provide.
And that will include /etc/phpMyAdmin/config.secret.inc.php and /etc/phpMyAdmin/config.inc.php if the file exists.

1/ about using %verify

I don't think this make sense

File was altered and this should be reported to raise admin attention
Also I don't want to break rpmsave/rpmnew behavior on this file.

2/ about a separate file for secret

Can work, but need to ensure not breaking configuration on upgrade


BTW, I don't see any huge benefit
this secret file will be reported as altered by rpm.
and will add another point of failure


So need strong arg to be convinced ;)

phpMyAdmin is packaged this way for years, and this is the first request about this

Files showing as modified directly after package installation, without admin intervention, defeats the purpose of RPM verification, does it not?

It seems that any clean solution without upstream changes necessitates the creation of an untracked file and a patch to include said file.

Slightly off-topic, phpMyAdmin is the only software I know that requires the admin to generate a static random value manually for secure cookie authentication. Improving on this upstream would also work.