Fix order of enabling FIPS in try

[The-Mule]

It is recommended to run FIPS prepare feature after all test dependencies are installed to prevent issues with packages using FIPS-incompatible digests. This only applies to tmt try but a note into FIPS prepare feature is added too.

Pull Request Checklist

• implement the feature
• write the documentation
• extend the test coverage
• update the specification
• adjust plugin docstring
• modify the json schema
• mention the version
• include a release note

[gemini-code-assist]

Code Review

This pull request adds an order parameter to the FIPS data preparation in tmt/trying.py. Feedback suggests documenting the magic number 99 to clarify its execution order relative to package installation.

[LecrisUT]

This only applies to tmt try but a note into FIPS prepare feature is added too.

Can you elaborate on why this is so?

[The-Mule]

Can you elaborate on why this is so?

It would be best to have the default order of fips prepare feature but it seems not possible at the moment (see #4760 (comment)). On the other hand one can make sure the order is just right be specifying it in the plan. This is not possible in tmt try though and hence we might want to have the default at least there.

I actually hit the problem with tmt try --fips - it first enabled FIPS mode and then proceeded to installing test dependencies and eventually failed to install some beakerlib library from beaker task library because its rpm had SHA1 digest that is rejected in FIPS mode.

[LecrisUT]

Can you elaborate on why this is so?

It would be best to have the default order of fips prepare feature but it seems not possible at the moment (see #4760 (comment)). On the other hand one can make sure the order is just right be specifying it in the plan. This is not possible in tmt try though and hence we might want to have the default at least there.

I actually hit the problem with tmt try --fips - it first enabled FIPS mode and then proceeded to installing test dependencies and eventually failed to install some beakerlib library from beaker task library because its rpm had SHA1 digest that is rejected in FIPS mode.

My main question here is why is it only affecting tmt try? Even with the example, it sounds like it would affect tmt run as well. Ah, is it that it is indeed an issue but it cannot be addressed currently?

The failure does sound like it is doing what it is supposed to be doing (catching improperly signed packages?). Are there other opt-outs that can be provided to fips to say some repos should be checked? Or maybe just disabling gpgcheck on the beakerlib task library would also help?

[happz]

My main question here is why is it only affecting tmt try? Even with the example, it sounds like it would affect tmt run as well. Ah, is it that it is indeed an issue but it cannot be addressed currently?

We can enforce order of phases we add, to install requirements, we could enforce order of prepare/feature phases easily, but not the prepare/feature-but-only-if-it's-fips. We can override PrepareFeatureData.order field and set it to something else then the default value, but that would affect all features owned by the prepare/feature plugin, not just FIPS. Programmatically distinguishing between various phases would be more work.

[The-Mule]

In modern infrastrucute it does not matter if FIPS is enabled before or after package installations because nobody should really use MD5 or SHA1 for rpm signatures. But we are dealing with old infractructure that uses these insecure algorithms and to work around it we need to postpone enabling FIPS mode. While tmt plans allow us to do this only when it's actually needed there is no way to do it in tmt try. It feels like this is a workaround, I see it as a way to make try a bit more robust.

[LecrisUT]

Ah ok, I kinda understand it now. I will leave the how should fips be handled to those more familiar with it, but yeah, this makes sense enough to me now.

[tcornell-bus]

/packit build

[tcornell-bus]

LGTM, works as expected after fix

[happz]

/packit build