There are a number of modules listed as dependencies of Guardr Core that aren't strictly necessary for day-to-day usage, e.g. Hacked and Diff. Some of them are only really useful for auditing a site, some of them are extras that many sites just don't need.

I propose the following:

  • Guardr Core: Day-to-day security improvements, e.g. password policy, etc.
  • Guardr Audit: Things for performing a security audit, e.g. Hacked, Security Review, etc.
  • Guardr Extra: Optional things, e.g. Update, Database Logging, Diff, etc.
CommentFileSizeAuthor
#2 guardr_core-n3159974-2.patch1.6 KBdamienmckenna

Issue fork guardr_core-3159974

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

DamienMcKenna created an issue. See original summary.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Active » Needs review
StatusFileSize
new guardr_core-n3159974-2.patch1.6 KB

This removes Diff and Hacked from composer.json, removes Diff and Update from the info.yml, and then tidies the remaining dependencies to make it easier to see what's documented.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

It might also be worth considering separating the functionality into three groups, each with its own module:

  • Day-to-day security improvements, should go in Guardr Core.
  • Things for performing a security audit, e.g. Hacked, Security Review, etc.
  • Optional things, e.g. Update, Database Logging, Diff, etc.
damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Title: Move optional pieces into Guardr Extras » Split Guardr into Guardr Core, Guardr Audit, Guardr Extras
Issue summary: View changes
the_g_bomb’s picture

the_g_bomb commented

Things I'd like to see in a D9 version of Guardr core:
autologout
email_confirmer
encrypt
field_permissions
flood_control
login_security
mass_pwreset
no_autocomplete
password_policy
realname
remove_http_headers
r4032login
seckit
session_limit
tfa
token
view_profiles_perms
user_registrationpassword
username_enumeration_prevention
x_originating_ip

No D8/9/10+ Version available (yet):
clear_password_field - #2204443: Port Clear saved password field to Drupal 8
ejectorseat - #2410423: Ejector Seat Drupal 8
hide_php_fatal_error
revision_all - #3112107: Drupal 8 port
session_expire - #3304405: D8/9/10/11 Version

Things I'd like to see in a D9 version of Guardr Audit:
config_log
logging_alerts
login_history
permission_watchdog
role_watchdog
state_log

Guardr Extras
diff
hacked
paranoia
security_review

No D8/9/10+ Version available (yet):
diskfree - [Abandoned, D8 branch available but not released]

Removing

duo - use TFA instead.
email_confirm - Removed in favour of email_confirmer
entitycache - No longer needed due to core improvements
remove_generator - #2676164: Remove Generator META tag & X-Generator for Drupal 8 version! Removed in favour of remove_http_headers
semiclean - No longer needed due to core improvements
settings_audit_log - Removed in favour of State Log and Config Log
tfa_basic - use ga_login with TFA instead

the_g_bomb opened merge request !7

the_g_bomb’s picture

the_g_bomb commented

I have some more suggestions for consideration:

To improve the monitoring on a site:
monolog module
monitoring module

To meet the PCI requirement (8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.)
user_expire module

the_g_bomb’s picture

the_g_bomb commented

TFA Module now includes TOTP/HOTP plugins, so ga_login is no longer needed when using TFA.

shrop’s picture

shrop commented

Appreciate all the work in this issue. I think we need to work on some changes and this covers many of them. What do you think about working on this for a 3.x version of Guardr Core? Seems like that would be a good break. Right now, I would like to get Guardr 2.x to D10 compatibility and then we could do this as a D10 compatible version at 3.x.

the_g_bomb’s picture

the_g_bomb commented
Version: 8.x-1.x-dev » 2.x-dev

This MR returns many of the modules from the D7 version. At a guess, they were removed as D8 versions weren't available at the time. I haven't done any work to split out the modules yet as I thought a conversation was probably needed about how to split them out and what approach to take. Do we remove the modules for the Guardr audit and make a new module? Or do we make a submodule and get all the dependencies in at once?

As it stands, this MR is basically a D9 version of the module as it was in D7.

the_g_bomb closed merge request !7

the_g_bomb opened merge request !12

the_g_bomb’s picture

the_g_bomb commented

This can be tested using:

composer create-project --no-interaction --no-install drupal/recommended-project:^9.5 guardrtest
cd guardrtest
composer config repositories.guardr_core vcs git@git.drupal.org:issue/guardr_core-3159974.git
composer require drupal/guardr_core:dev-3159974-split-guardr-into -W

the_g_bomb closed merge request !12

the_g_bomb’s picture

the_g_bomb commented

Closing the PR, until a direction can be determined.
I would like to see the some of the modules that were included in D7 guardr back in the module, at least. Most are now available for D8/9 when the 8.x branch was created, I suspect.
This list is now currently out of date.
https://www.drupal.org/docs/distributions/guardr/security-features-and-s...