CONFIG_SAE implicitly requires SHA features that are not declared

Neil Tallim red.hamsterx at gmail.com
Tue Jun 27 15:33:50 PDT 2023


Hello, this is probably a pretty easy thing to address, but I'm not
sure my solution is as clean as it should be.

When preparing a custom build of wpa_supplicant, based on the 2.10
tag, I enabled CONFIG_MESH, which defines CONFIG_SAE. Nothing
surprising there.

However, CONFIG_SAE requires SHA256[_KDF], SHA384[_KDF], and
SHA512[_KDF], but the configuration path for it doesn't specify any of
these:

ifdef CONFIG_SAE
CFLAGS += -DCONFIG_SAE
OBJS += ../src/common/sae.o
ifdef CONFIG_SAE_PK
CFLAGS += -DCONFIG_SAE_PK
OBJS += ../src/common/sae_pk.o
endif
NEED_ECC=y
NEED_DH_GROUPS=y
NEED_HMAC_SHA512_KDF=y
NEED_DRAGONFLY=y
ifdef CONFIG_TESTING_OPTIONS
NEED_DH_GROUPS_ALL=y
endif
endif

I suspect this was missed because CONFIG_DPP is usually enabled, which
is one of the paths to ensure the SHA objects get built.

I worked around it by adding the following to the CONFIG_SAE ifdef:

NEED_SHA256=y
NEED_HMAC_SHA256_KDF=y
NEED_SHA384=y
NEED_HMAC_SHA384_KDF=y
NEED_SHA512=y

This may be a bit overly broad (I don't even know if NEED_SHA256 is a
real flag), but it resolved the immediate deficiency and allowed
compilation to complete, producing a usable binary.

I doubt this is an issue that affects many people, but it didn't seem
right to let it go unreported. Hopefully this helps in some way.

-Neil Tallim



More information about the Hostap mailing list