Is this a regression from Satellite 6.9?

It is not a regression from Satellite 6.9.

Here is a summary. It works as expected for a host without any hg:

> Host.create!(name: "grub-pass", root_pass: "test")
=> #<Host::Managed:0x00000000159446b0
 id: 3,
 name: "grub-pass",
 last_compile: nil,
 last_report: nil,
 updated_at: Tue, 12 Oct 2021 06:41:01 UTC +00:00,
 created_at: Tue, 12 Oct 2021 06:41:01 UTC +00:00,
 root_pass: "[FILTERED]",
 architecture_id: nil,
 operatingsystem_id: nil,
 environment_id: nil,
 ptable_id: nil,
 medium_id: nil,
 build: false,
 comment: nil,
 disk: nil,
 installed_at: nil,
 model_id: nil,
 hostgroup_id: nil,
 owner_id: 2,
 owner_type: "User",
 enabled: true,
 puppet_ca_proxy_id: nil,
 managed: false,
 use_image: nil,
 image_file: nil,
 uuid: nil,
 compute_resource_id: nil,
 puppet_proxy_id: nil,
 certname: nil,
 image_id: nil,
 organization_id: nil,
 location_id: nil,
 type: "Host::Managed",
 otp: nil,
 realm_id: nil,
 compute_profile_id: nil,
 provision_method: nil,
 grub_pass: "$6$OvfLPeg45hRnI1Sa$G8Vx3CBtFFYvQuNfSuwnjUvs8msZo2wiL2YT7AkTCf48CG4l9HESIYjCQSUWStLkpwbgDTgO5tLfmZxNAA9e1/",
 discovery_rule_id: nil,
 global_status: 0,
 lookup_value_matcher: "[FILTERED]",
 openscap_proxy_id: nil,
 pxe_loader: nil,
 initiated_at: nil,
 build_errors: nil>

[19] pry(main)> Host.find(3).root_pass
=> "$5$lKYZNatltpksaQ9e$9QDHDK/xOArM5lqZtQPPuxZQjAFCCKZPnE8fUajgT95"
[20] pry(main)> Host.find(3).grub_pass
=> "$6$OvfLPeg45hRnI1Sa$G8Vx3CBtFFYvQuNfSuwnjUvs8msZo2wiL2YT7AkTCf48CG4l9HESIYjCQSUWStLkpwbgDTgO5tLfmZxNAA9e1/"
[21] pry(main)> "test".crypt("$6$OvfLPeg45hRnI1Sa")
=> "$6$OvfLPeg45hRnI1Sa$G8Vx3CBtFFYvQuNfSuwnjUvs8msZo2wiL2YT7AkTCf48CG4l9HESIYjCQSUWStLkpwbgDTgO5tLfmZxNAA9e1/"
[22] pry(main)> "test".crypt("$5$lKYZNatltpksaQ9e")
=> "$5$lKYZNatltpksaQ9e$9QDHDK/xOArM5lqZtQPPuxZQjAFCCKZPnE8fUajgT95"

I also tested hostgroup alone, works fine:

[25] pry(main)> Hostgroup.find(1).root_pass
=> "$5$5gB8jMY9BJpHIyqV$wFhqcic4ffcLC99c3hqfSjte69O/qbazLUuRBBNqNED"
[26] pry(main)> Hostgroup.find(1).grub_pass
=> "$6$EfcqnPlzWm0ESXAb$IPgp/TpTwdu9PoZ71NYpcRoqB3Q.kpEvJ7Yq5Ieg1bYECQDFIuRWTrnrbUyRGCScVFj7fs78vkb1m6osxqwBu/"
[27] pry(main)> "12345678".crypt("$5$5gB8jMY9BJpHIyqV")
=> "$5$5gB8jMY9BJpHIyqV$wFhqcic4ffcLC99c3hqfSjte69O/qbazLUuRBBNqNED"
[28] pry(main)> "12345678".crypt("$6$EfcqnPlzWm0ESXAb")
=> "$6$EfcqnPlzWm0ESXAb$IPgp/TpTwdu9PoZ71NYpcRoqB3Q.kpEvJ7Yq5Ieg1bYECQDFIuRWTrnrbUyRGCScVFj7fs78vkb1m6osxqwBu/"

Ah now I see the problem, when I create a host with a hostgroup and without root_pass set on the host (only on the hostgroup), the grub is copied from root:

[33] pry(main)> Host.create!(name: "grub-pass-w-hg", hostgroup_id: 1)
[31] pry(main)> Host.find(4).root_pass
=> "$5$5gB8jMY9BJpHIyqV$wFhqcic4ffcLC99c3hqfSjte69O/qbazLUuRBBNqNED"
[32] pry(main)> Host.find(4).grub_pass
=> "$5$5gB8jMY9BJpHIyqV$wFhqcic4ffcLC99c3hqfSjte69O/qbazLUuRBBNqNED"

Well, the reason for that is that when we save hostgroup, for security reasons we actually store the root password in the encrypted form which is by default SHA256 ("$5$XYZ") in the DB. When a host is created later, Foreman no longer has a clear password in order to rehash this into SHA512 ($6$XYZ"). It will rehash it only and only if you update the host with a new password, then it has access to cleartext password and can update both versions accordingly.

I believe this is not a problem, grub2 should support all crypt methods so $5$ should work just fine. At least it supported it some time ago. Anaconda documentation does not state which algorithms can be used:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax

So question for you: If you actually create a host that has no root password with a hostgroup that has a root (and grub) password set, provision it, will grub accept the root password set from the host group?

If not, then the only reasonable solution is to remove this feature from Foreman and only rely on encrypted host param.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.