Localizations should not need to worry about the default secret key

[nacin]

Currently localizations must define $wp_default_secret_key in a $locale.php file in order to translate the key placeholder strings and not weaken wp_salt().

This is less than ideal. Let's automagically detect whether the default value is still being used, even if it has been translated, and prevent the need for the $wp_default_secret_key global.

See #14024.

We could check if the same (non-empty) value is used for more than two secret keys and assume it's $wp_default_secret_key then.

19599.patch is an attempt to implement this.

19599.2.patch goes a bit further and cleans up repeated defined() and '' != ... checks.

Coding logic still seems a bit dense and repetitive, but it's a good start. I agree with the angle, though we could probably go with two keys, rather than more than two. SECRET_KEY should be excluded from the count, as it is not one of the eight.

Refreshed the patch to include the suggestions.

I've also removed the checks for empty values for the count, seems they are unnecessary.

Simplified logic in 19599.4.patch

19599.2.diff rewrites wp_salt().

1. DB fallback is provided for the eight main keys and salts, and also SECRET_KEY, since it is used for custom schemes.

2. If any two keys or salts match in value, the fallback is triggered.

3. If any key or salt matches 'put your unique phrase here', the fallback is triggered.

Now, local builds. We want to eliminate the need for $locale.php files, so we want to avoid $wp_default_secret_key. Additionally, #14024 has caused translators to instead override default-constants.php. This is even less desirable.

Point 2 ensures that a localized 'put your unique phrase here' only works if the value is used exactly once — say, if the other 7 are properly unique. However, it could also be that the only one defined is SECRET_KEY (perhaps the install started with 2.5), and either way, we should try to mitigate this.

So, Point 4: For 3.4 localized builds, we will append $wp_secret_key_default to version.php, the same way we append $wp_local_package to version.php. We will use this variable to ensure that for all fresh local installs of 3.4 or higher will end up covered.

For installs prior to 3.4, we cannot use the existing $wp_default_secret_key, as otherwise we will re-introduce #14024. again, point 2 is strong enough to mitigate any issues.

In [19771]:

Provide a DB fallback for keys in wp_salt(). Fall back when any secret is used more than once. Change how we detect a localized 'put your unique phrase here' -- eliminate $wp_default_secret_key and introduce $wp_secret_key_default to be added during the localized build process, not by translators. fixes #19599.

This could potentially cause a log-out after an upgrade, and based on how $wp_locale_package can get overridden in an upgrade, we may need to store default keys in the DB.