Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
Дата
Msg-id CAEudQAqg_rfJvx6U+Ys4hmwVvgOssRAhBX2vRkzRYBrCtxZezg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier <michael@paquier.xyz> escreveu:
On Sat, Feb 13, 2021 at 05:37:32PM -0300, Ranier Vilela wrote:
> IMO there is no necessity in back-patching.

You are missing the point here.  What you are proposing here would not
be backpatched.  However, reusing the same words as upthread, this has
a cost in terms of *future* maintenance.  In short, any *future*
potential bug fix that would require to be backpatched in need of
using this function or touching its area would result in a conflict.
Ok. +1 for back-patching.

Any future maintenance, or use of that functions, need to consult the api.

scram_HMAC_init(scram_HMAC_ctx *ctx, const uint8 *key, int keylen);
scram_HMAC_update(scram_HMAC_ctx *ctx, const char *str, int slen);
scram_HMAC_final(uint8 *result, scram_HMAC_ctx *ctx);

See both "result" and "ctx" are pointers.
Someone can use like this:

scram_HMAC_init(&ctx, key, keylen);
scram_HMAC_update(&ctx, str, slen);
scram_HMAC_final(&ctx, result); // parameters wrong order

And many compilers won't complain.

regards,
Ranier Vilela

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Detecting pointer misalignment (was Re: pgsql: Implementation of subscripting for jsonb)