Nominating as a Final blocker per "The installer must be able to detect (if possible) and install to supported network-attached storage devices" - https://fedoraproject.org/wiki/Fedora_39_Final_Release_Criteria#Network_attached_storage .

Hum, correction: I'd forgotten how we actually set up the server end of the test. We use 'scsi-target-utils', not iscsi-initiator-utils. 'scsi-target-utils' is really https://github.com/fujita/tgt , which...appears to support MD5 and SHA1, nothing more (using its own 14-year old implementations of both, which, yikes). It is unclear to me how it decides which to use, or what it expects to do when it's given this list of algorithms to try...we could file a ticket upstream, perhaps?

So the blivet commit was added just as a courtesy to fix possible MD5 CHAP auth issues in the FIPS mode. I'll have a look why the other algorithms are not used, however the preferred algs string was taken from iscsid.conf sample config.

It's entirely possible blivet is DTRT and this is actually a quirk of / bug in scsi-target-utils and doesn't really need to block release (since 'real world' iSCSI use presumably doesn't really use it), but I just haven't had the time to get back and give it another look yet, unfortunately. When I get time I will try and poke about the scsi-target-utils code a bit, and also see if it'd be possible to redesign the test to use iscsi-initiator-utils or something else...

I've built a simple testing environment and so far it looks like tgtd is refusing any auth alg other than SHA1 and MD5. Sadly instead of falling back to weaker alg, a failure is reported right away. My testing was done entirely with iscsiadm, outside of blivet and udisks, still getting the same results.

Steps to reproduce:
 1. Setup a tgtd target as described in comment 0
 2. On initiator side:
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 -o update -n node.session.auth.username -v test
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 -o update -n node.session.auth.password -v weakpassword
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 -o update -n node.session.auth.authmethod -v CHAP
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 -o update -n node.session.auth.chap_algs -v SHA3-256,SHA256,SHA1,MD5
 3. Try logging in:
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 --login 
    Logging in to [iface: default, target: iqn.2016-06.local.domain:support.target1, portal: 192.168.122.1,3260]
    iscsiadm: Could not login to [iface: default, target: iqn.2016-06.local.domain:support.target1, portal: 192.168.122.1,3260].
    iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
    iscsiadm: Could not log into all portals
 4. Weaken the auth algs:
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 -o update -n node.session.auth.chap_algs -v SHA1,MD5
    # iscsiadm --mode node --portal 192.168.122.1 --targetname iqn.2016-06.local.domain:support.target1 --login 
    Logging in to [iface: default, target: iqn.2016-06.local.domain:support.target1, portal: 192.168.122.1,3260]
    Login to [iface: default, target: iqn.2016-06.local.domain:support.target1, portal: 192.168.122.1,3260] successful.

The target is Gentoo sys-block/tgt-1.0.86

Testing against the kernel LIO target, everything works with the full 'SHA3-256,SHA256,SHA1,MD5' alg set.

Now since MD5 is disabled in FIPS mode, I think we can live with "SHA1,MD5" defaults in Blivet. It'll be still an improvement from previous state with no algs available in FIPS mode.

FWIW, my testing environment is based on QEMU + iPXE with a nice EFI-based iSCSI initiator configuration. Testing against both the tgtd and LIO exporting a single LUN with Fedora 38 netinst ISO, I can make it boot with IBFT on both targets but CHAP auth only works against LIO. Haven't found a way to define CHAP auth algs in the iPXE setup, I suppose it's facing the same problem as above.

Proposed blivet changes: https://github.com/storaged-project/blivet/pull/1148

it seems a shame to drop the SHA256 support just because tgtd doesn't allow a proper fallback. Is tgtd usage for this in the real world common? I honestly have no idea; as I said I just picked it for the openQA testing as it was there and I could get it to do the job. I'm not stuck on using it for openQA, if there's an alternative.

If we're sufficiently worried about real-world use of tgtd with this bug, then okay, makes sense (and makes my life easier). If not, we can look at fixing tgtd/libiscsi to allow a proper fallback, or switching to something else for the openQA tests?

btw, thanks a lot for testing this out and confirming the details! I really appreciate when somebody else does that :D

(In reply to Adam Williamson from comment #8)
> it seems a shame to drop the SHA256 support just because tgtd doesn't allow
> a proper fallback. Is tgtd usage for this in the real world common? I
> honestly have no idea; as I said I just picked it for the openQA testing as
> it was there and I could get it to do the job. I'm not stuck on using it for
> openQA, if there's an alternative.
> 
> If we're sufficiently worried about real-world use of tgtd with this bug,
> then okay, makes sense (and makes my life easier). If not, we can look at
> fixing tgtd/libiscsi to allow a proper fallback, or switching to something
> else for the openQA tests?

Well it's udisks2 in the background doing the heavy lifting through a downstream libiscsi that noone else ships. It's known to be buggy (I'm debugging just another segfault right now), leaking and unsupported. We do plan to improve libopeniscsiusr that is part of the open-iscsi project and port udisks onto. So there's a high chance that the auth fallback might work afterwards. Until then, I suggest to keep the auth alg list minimal for compatibility.

I still think only MD5 alone was used until the point we started making changes. In any case, if you do plan some FIPS testing, you'd find soon enough.

that makes sense. yes, it was MD5 only before, so SHA1 then MD5 is still an improvement, just SHA256 would be nicer :D but given the info on libiscsi, I agree it makes sense to just go with SHA1->MD5 for now and re-evaluate after the port is done.

This is merged now, so marking POST.

Included in python-blivet-3.8.1-1.fc39:

* Thu Aug 03 2023 Vojtech Trefny <vtrefny> - 3.8.1-1
- Ignore new false positives with the latest pylint (vtrefny)
- iscsi: Rename storaged to udisks (tbzatek)
- iscsi: Rework UDisks iscsi module activation (tbzatek)
- iscsi: Make sure to modprobe iscsi_ibft (tbzatek)
- iscsi: Downgrade default CHAP auth algs to SHA1,MD5 (tbzatek)
- iscsi: Save firmware initiator name to /etc/iscsi/initiatorname.iscsi (vtrefny)
- spec: Bump release to 99 to be always ahead of Fedora in nightly (vtrefny)
- tests: Improve iscsi_test.ISCSITestCase (vtrefny)
- Make sure that LUKS.has_key always returns a boolean value (vtrefny)
- Squashed 'translation-canary/' changes from d6a40985..5bb81253 (vtrefny)
- Add btrfs subvolume specification to devicetree.resolve_device (vtrefny)
- Revert "Makefile cleanup" (vtrefny)

A couple more iscsi-related changes are included in that build, feel free to report any discrepancies.