URL:
https://github.com/SSSD/sssd/pull/846
Title: #846: crypto: unconst key in sss_encrypt and sss_decrypt
alexey-tikhonov commented:
"""
The key parameter was made const in
[
8aa0dfd](https://github.com/SSSD/sssd/commit/8aa0dfdf6e36fa90855c0f35a4df...
but it produces errors:
/home/pbrezina/workspace/sssd/src/util/crypto/nss/nss_nite.c:96:38: error: passing
argument 3 of ‘nss_ctx_init’ discards ‘const’ qualifier from pointer target type
[-Werror=discarded-qualifiers]
Thanks for the catch.
I guess it wasn't caught by CI because it produces warning (not an error) with configs
of CI machines. But I wonder how did it pass covscan check. I was pretty sure I checked
both nss and openssl builds...
But anyway, this has to be fixed, of course.
Making the parameter const also in `nss_ctx_init` will produce
another error which is out of our control thus removing the const.
I don't think this the best solution.
Making `key` parameter to be non-const in public API says that function is eligible to
modify this parameter and imposes additional burden on user of those functions. But
that's not the case.
This is especially pity as we are going to drop NSS support soon anyway.
I would offer to change `MAKE_SECITEM` macro instead to make copy of sdata (if non NULL)
in sitem context (and would move this macro inside `nss_util.c`). This context is freed
along with `sss_nss_crypto_ctx`.
This is sub-optimal performance wise, but really doesn't matter here. And again, we I
going to drop NSS support anyway. So I think it is better to keep API sane instead of
tweaking it for NSS codepath needs.
Please, let me know what do you think and if I should make those changes.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/846#issuecomment-509202699