Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter snazzylene

    (@snazzylene)

    I don’t know if the “trusted user” thing applies to other mailers. sendmail last I saw was still 80% of installations, and sendmail usage is so commonplace that it could not hurt to add a label such as “sendmail_send_as_user”. As many other mailers as might need something “out of band” like this can have their own label. We’re talking about 3 or 4 mailers, so the task is not daunting.

    Access to the config file is for system people doing setup, and this is setup. The labels contained in the file don’t alter the security of the file. Apache is configured not to serve out PHP files as text (that’s .phps), presumably other servers are as well. The config file lives in the home directory and contains the database password. On Unix the file has to be made “no-read others” to prevent users on the server machine from seeing the same data.

    Thread Starter snazzylene

    (@snazzylene)

    circumstances, plain old usage of the site (any access.)

    PHP 7.0.6.

    Thread Starter snazzylene

    (@snazzylene)

    If they had anywhere said “we suggest everyone reset their passwords now to prevent incompatibilities with future versions”, I missed it, but figure most people did too.

    Thread Starter snazzylene

    (@snazzylene)

    The passwords appeared to //cease// working – for at least one user – with the site code unchanged. Which makes no sense. Then more users reported this, and in debugging that problem I upgraded the code (did they fix something? Which still makes no sense.)

    Early on after I had manually reset a password hash on an older blog and it still wouldn’t work, in poring thru the code I ran across a code blurb that appeared to be the “fix a raw MD5 password to be cooked” and there was a comment about a new mechanism – php-something, not SHA256 – so I saw that as being in play. Would the new (bleeding new 4.9.8) like its own passwords? Sure enough, it did, so I created (with the NEW code) another user with the desired password and used that hash in the older blog’s database and bang! it worked.

    The WP code itself could not upgrade that hash – the sentient user who knew the password would have to do it. So I figure something got lost somewhere. In that code blurb, the “raw” MD5 was detected by virtue of having length 32 — but I did NOT see a distinction made between a “cooked” MD5 hash (having the $P$B prefix) and the new-style hash, so I think cooked MD5 hashes were accidentally being run thru the new validation code, and of course that would fail.

    Yes, it was odd. One person reported an issue a couple weeks back, but with no site code changes, this should not have been able to “break down” as it seems to have.

    Thread Starter snazzylene

    (@snazzylene)

    Each of the strings in the above “define” are quoted between an accent-grave (backtick) and apostrophe. The backtick seems not be be displayed above.

Viewing 5 replies - 1 through 5 (of 5 total)