Observations about colour-coding with FPA v1.6.5

[sozzled]

See a more detailed explanation of the issues at https://forum.joomla.org/viewtopic.php?f=804&t=996920

Two issues to address or discuss:

1) "Password missing" in red-coloured font when using PC-hosted J! websites; and

2) Warning about "apache2handler" (ditto for Wampserver)

[RussW]

Whilst I appreciate and understand your concern when operating within a specific local development environment. However, within a production environment, IMHO both of these items are problematic and noteworthy to the degree that their assigned colour designations convey (warning/orange : danger/red).

1. Password Missing : any database instance that does not require a password is potentially open to exploit and subsequently compromise
   • no-password "root" accounts are not default (or recommended) from any database developer/provider
   • no Cloud Management or Hosting Control Panel allows production database accounts without a password
   • this is a serious security exposure for the user account and potentially the whole database instance
   • the user should be made aware of this (Danger/Error)
2. apache2handler : any production system still using the apache2handler module is reducing functionality, performance and security, particularly within a shared hosting environment
   • the use of this module limits the use of user management and security modules
   • is unable to make use of later PHP (v8 or above) & MySQLi/MariaDB JIT & multi-thread capabilities
   • is very likely to produce ownership/permissions issues
   • the user should be warned of the use of this old architecture (Warning/Beware)

My Observation In my personal opinion, No Change is required or desired (unless others disagree and then lets discuss!). Any changes would only serve to;

• invite poor practices (perceived as misleading on poorly/lazily configured environments)
• create confusion when moving between development & production environments
• misinform users of potential security risks or poor hosting configurations creating a false sense of security

Obviously open to others opinions and discussion for a final resolution.

[sozzled]

Thanks, Russ. I don't want to argue with you. I'm only saying for PC-hosted environments, esp. Wampserver and XAMPP ones (and possibly others):

(a) the default SQL username is root with a null password; and (b) there's no easy mechanism to change from apache2handler to something else (something "better).

While there's no argument about how efficient PC-hosted environments may be (compared to commercial setups), the only point I'm making is that J! works quite well with them: there's no real security issue if the SQL username is "root" with a null password (in a "one-man-band" operation) and there's no "reduced functionality" issue(s) in using apache2handler. Fair point that these things should be addressed when using a commercial setup (esp. on a shared hosting environment as you say), but these matters are moot when we're discussing a privately-operated, PC-hosted environment created for website development/testing purposes.

You are probably right that

• no-password "root" accounts are not default (or recommended) from any database developer/provider

but this is the default in Wampserver and most PC-hosted setups.

Some "default" settings in Wampserver cause problems (and they need to be changed), e.g. Max. Upload Size, Max. POST Size, Max. Execution Time and Memory Limit. If those things are not changed, people cannot update from one version of J! to another because the default PHP quotas for these things are inadequate. I would like to discuss those matters at another time.

When J! forum "experts" see red things in the FPA, they're likely to hammer the person who posted the FPA report and say, "Your SQL username has a missing password and you need to fix it." Yes, sure, if the FPA report relates to a commercially-hosted platform, from a security perspective, that's a fair point. What's most important, from a diagnostic perspective, is whether the J! website filesystem can interoperate with the database; in other words, if the database connection credentials fail, that's the real problem. It's not so much a problem that the password is "missing" or insecure, is it? That's a user responsibility and that is beyond the purposes for which the FPA was intended to be used.

I'm suggesting that the colour-coded severity for the items we're talking about here are probably inapplicable in a PC-hosted environment. In much the same way as the FPA report no longer highlights elevated file permissions (viz. 777) for Windows-based environments—which was one of the changes between v1.6.4 and 1.6.5 (mentioned in https://github.com/ForumPostAssistant/FPA/pull/120)—I'm saying that for PC-hosted setups, the implied severity is not really an issue. That's all I'm saying.

Fair enough to have the FPA make recommendations, I agree. The main purpose of the FPA reports (when used on the J! forum) is to assist the forum users in quickly identifying known problem areas. And yes, we could discuss until the cows come home about "lazy practices" of which we're all guilty.

And, to be completely honest with everyone, I'm lazy: I haven't bothered to change the SQL root password to non-null or setup a new SQL username/password for Wampserver. Y'know, I spend more time mucking around with maintaining Wampserver than I do actually using the websites that I host on it! :laughing:

[RussW]

Let's leave this open and see if anyone else chimes in with their opinion and see what direction that takes us in?

I do understand you point of view though, particularly within a purely local development perspective, but correct me if I am misunderstanding when you say "PC-Hosted setup" that you are meaning "also made publicly available through open ports on your own PC to the internet", which effectively means that it is accessible to "bad actors" just like any other commercially hosted site, therefore it has the same risks, if not more, as any normal website/host online, so for me I think it should be treated as such.

The apache2handler, for me is a little "so so" but the "missing password", as it is more directly security based, is important to highlight still.

[sozzled]

I understand what you're saying. Sure, if we're talking about a website hosted on someone's PC that extends beyond the CAT5 blue cable into the wild, wild internet or if we were discussing a website operated inhouse within a LAN where you had any number of people developing different aspects of the company's intranet, then one must address inhouse (as well as networked) security. However, that's not the purpose for which the FPA was developed.

I'm discussing a closed system: a PC-hosted testing laboratory that's on the blue side of the firewall. Wampserver, out-of-the-box is set up the way I set it up (a few mouse-clicks, follow the screen prompts). It works. For sure, if I really wanted to get jiggy with Apache (or MySQL for that matter) and deliver the ultimate security for an environment that consists of a dozen or more throwaway websites, then traffic-light, colour-coded self-assessment diagnostics might be "interesting".

As I wrote before, I'm lazy. I built my testing environment for me and when I post an FPA report on the J! forum based on that, I don't want a panel of "experts" telling me I need to have a non-null password simply because there's a red-coloured notice about it on the report.

I'm only saying that the red-coloured "password missing" text on the FPA report—all other things being equal and that the database connection credentials are valid—in a PC-hosted environment is not relevant, just like red-coloured 777 file permissions on a Windows-based, PC-hosted testing, self-contained/firewall-protected environment is not relevant, either. Unfortunately, the FPA script has no knowledge about whether the environment is exposed to the wild, wild internet or even if the website owner could be "interested" in changing their database credentials (just to get the FPA's approval).

[frostmakk]

@sozzled Unless you can provide a code example for the FPA to safely detect that the wamp/xamp stack is in fact a closed system not exposed to anything outside "the box", I believe the missing password should remain red. There are people out there hosting web sites on wamp.

[RussW]

ok, so I'm seeing a few other things here beyond the directly addressing @sozzled concerns regarding colour assignments of "Missing Password" & "apache2handler" module.

There appears to be some, somewhat misinformed, assumptions at play here;

1. the FPA was designed to cater for both "Development" and "Production" environments
   • whilst this was never explicitly stated. It was not intended to fully support Development environments, my intention for the FPA was only ever to assist end-users with issues observed on Production environments.
   • whilst the FPA does take in to account the hosting platform (Windows/ Linux/ Other) where possible, it does not and cannot consider any specific combined/bundled/virtual delivery mechanism of a Development application.
2. that all Development environments are "local PC" based or use bundled applications and as such do not need to adhere to any industry best practices.
   • even behind firewalls and within sandboxed corporate environments, full and extensive security measures are in place and web-serving applications are adequately managed to conform to industry standards and best practices, potentially unlike any individual "Local PC Hosting" environments delivered by bundled applications.
3. that any Development environment does not need to adhere to Production environment standards.
   • this is not only fool-hardy but poor practice and only invites unexpected issues upon deploying in to a production environment.
   • the FPA is not designed, nor do I believe should its integrity be compromised in such a manner, as to offer/provide "over-confidence" within a development environment that will allow compromise within the production environment.

Again, sorry @sozzled for me personally, it's still a NO as Production accuracy wins over lax Development environments every time.

Pending further opinions, discussion and/or qualified justification

[sozzled]

Thank you, Russ. Excellent explanation.

I'm content to leave this alone—not requiring any change to the FPA on the matters I've raised above. :sunglasses:

While I would respectfully submit that red-coloured text intuitively indicates some kind of "show stopper", I agree that it's a security risk for anyone to deploy a website in a production (internet or corporate intranet) environment with the default [root] database username with a null-password. Just for information, in connection with the site I referred to in https://forum.joomla.org/viewtopic.php?f=804&t=996920 earlier, the FPA scored it with a "B" even with the red-coloured text. So it's not an absolute show stopper but, if we apply the "missing password" test as a factor to obtain a confidence score, the overwhelming majority of PC-hosted websites would be rated "F". I don't think we want that outcome.

I agree that if a careless website owner were to deploy a site in a production environment with root/null as the DB connection credentials, I would score that site with a solid "F"! But not, in a local environment. The next thing you know, all our "A", "B", "C" development sites would turn "F" and we'll have complaints from now until doomsday. For the time being, unless you can tweak the FPA to score differently for production as opposed to development sites, no changes there either.

It may be an idea to add the gist of your explanation (about how the FPA was intended to be used) as a disclaimer in the FPA documentation, along the following lines, perhaps:

---

Intended usage of Forum Post Assistant

1. The FPA was designed for both Production (i.e. internet-based and corporate intranet) environments and Development (i.e. local, PC-based) environments to assist end-users with issues they may observe. The primary focus of the FPA is to analyse websites in Production environments; the FPA was not designed to fully support Development environments. Whilst the FPA does take into account the hosting platform (Windows/ Linux/ Other), where possible, it does not and cannot consider any specific combined/bundled/virtual delivery mechanism of a Development application.
2. Development environments are "local" (i.e. PC-based) or use bundled applications for personal use and, as such, generally not adhere to industry best practice. Website operators must also consider broader security measures, even for Development environments located behind firewalls and within sandboxed corporate environments, to ensure web-serving applications are appropriately managed to conform to industry standards and best practice. That is to say, bundled applications for personal use usually do not, or do not necessarily need to, adhere to Production environment standards.
3. The FPA was not designed, nor do we believe should its integrity be compromised in such a manner, to suggest any level of confidence within a Development environment that could compromise a Production environment. It is imprudent, in our view, to rely on FPA reports generated in Development environments, or infer anything in reports generated therein when deploying websites in Production environments.

---

What do you think about that suggestion? By explicitly outlining the FPA's intended usage, this may help to defuse divisive expert "opinion"—often leading to furious "panel discussions—on the J! forum. :question:

[RussW]

@sozzled now you've completely lost me, the Confidence rating only tests the hosting environment for its suitability of successfully running Joomla! Testing for a "Missing Password" within this section is not only irrelevant, but is not related to this area of function of the FPA.

So, as with the colour changes, personally I can see no reason to either qualify, disclaim or further describe the FPA's use, intention or suitability beyond the GPL Warranty disclaimer and License currently in use.

I'm not a fan of the "Nanny State" or "Lowest Common Denominator" practices and as such see this type of thing as being a bit excessive and needless. As ever though, lets see what everyone else thinks.

[sozzled]

Now you've completely lost me.

Perhaps I should not have used the word "disclaimer"? Replace the word with "usage notes", maybe?

I'm trying to get a handle on the way that some forum experts nit-pick the FPA report, esp. when they observe red-coloured text. If we explain what the red-coloured text means, in the context of the report generated on a development website in contrast to the report generated on a production one, everything you've written earlier in this topic makes complete sense. The problem that I have is that "experts" on the forum focus on red-coloured text without discounting the intended use of the FPA which is primarily for production websites (as opposed to development ones). Do you understand the question and the concerns that I have?

A straightforward explanation of the intended usage—as you wrote,

Production accuracy wins over lax Development environments every time

—would, in my very view, help. You see, if expert opinion about "red-coloured text" appears on the J! forum categorically states that something or other needs to be changed in their current environment (whatever that may be), the poor novices who ask their questions may be led to believe they've done something wrong. I'm not advocating a "nanny-state" as you've characterised it; I'm advocating an explanation that people can refer to.

This is not about diluting the value of the FPA. This is about defusing fractious and unnecessary bagging among forum users who implicitly place their faith in FPA reports to the exclusion of the context in which it was generated.

[sozzled]

On further reflection, this is probably not a matter for the FPA developers. It's a matter for the J! forum.

The questions that were in my mind at the outset were these: 1) Do novice users know what are the intended uses for the FPA reports posted on the J! forum? 2) Do expert users understand the intended uses of FPA reports posted on the J! forum? 3) Is it feasible to clear up misunderstandings that people may have about FPA reports posted on the J! forum?

As far as the general disclaimer and limitation of liability is concerned,

Forum Post Assistant script comes with ABSOLUTELY NO WARRANTY. This is free software; and covered under the GNU GPLv2 or later license.

You are welcome to redistribute it under certain conditions. For details read the LICENSE file included in the download package with this script. A copy of the license may also be obtained at http://www.gnu.org/licenses/.

Which says it all.

As far as the J! forum is concerned, that's a whole separate matter that is covered with

USE AT YOUR OWN RISK Accuracy and completeness of this script and documentation is not assured and no responsibility will be accepted for any damage, issues or confusion caused by using any FPA versions contained within these branches.

We can probably close this topic now with my thanks to you, Russ, for setting me on the right path forward. Cheers.

[RussW]

Closed to no further comments, suggestions or discussion within 20 days, with no changes to FPA.