Krikri::PluginHelpers::CryptHash::CryptFacade
The runtime half: which crypt library got loaded, and whether it is libxcrypt (has crypt_gensalt) or a bare libc crypt() (musl).
Constants
Same order as ansible's _CRYPT_LIBS: libxcrypt by soname first,
then (non-darwin only) the process's own libc - where a musl host's
crypt() lives - then macOS's two Homebrew libxcrypt paths. The
musl-specific sonames stand in for ansible's bare ctypes.CDLL(None):
dlopen'ing a glibc libc.so by name into a static musl process would
initialize a second libc, which is not something to risk.
libxcrypt's own struct crypt_data is small, but musl's crypt_r expects ~128K of it and ansible allocates that size, so match it.
crypt(3)'s "invalid salt"/"unsupported scheme" return values.
ansible's own output buffer for crypt_gensalt_rn.
Constructors
Class methods
Test seam (and the only reason this is a property): a spec can point the module at a facade built from a specific library list.
Test seam (and the only reason this is a property): a spec can point the module at a facade built from a specific library list.
Instance methods
Ansible's HAS_CRYPT: no library at all means password_hash cannot be used on this host.
crypt(): nil for every outcome ansible turns into an error (a null pointer, an empty string, or crypt's "*" failure tokens).
crypt_gensalt(): nil when the library has no gensalt entry point at all or when it refuses the prefix/rounds.
Ansible's _crypt_facade.has_crypt_gensalt: false on a musl host, so
the salt string gets built by hand instead of by libxcrypt.