On Tue, Apr 26, 2022 at 03:15:24PM +0200, Daniel Gustafsson wrote: > On 26 Apr 2022, at 03:55, Michael Paquier <mich...@paquier.xyz> wrote: >> I am a bit annoyed to assume that having only a localized >> ERR_clear_error() in the error code path of the init() call is the >> only problem that would occur, only because that's the first one we'd >> see in a hash computation. > > It's also the only one in this case since the computation won't get past the > init step with the error no? The queue will be cleared for each computation > so > the risk of cross contamination is removed.
I was wondering about the case where an error is applied while updating or finishing the cryptohash, not just the creation or the initialization. But cleaning up the queue when beginning a computation is fine enough. >> Okay. I did not recall the full error stack used in pgcrypto. It is >> annoying to not get from OpenSSL the details of the error, though. >> With FIPS enabled, one computing a hash with pgcrypto would just know >> about the initialization error, but would miss why the computation >> failed. It looks like we could use a new error code to tell >> px_strerror() to look at the OpenSSL error queue instead of one of the >> hardcoded strings. Just saying. > > I looked at that briefly, and might revisit it during the 16 cycle, but it > does > have a smell of diminishing returns to it. With non-OpenSSL code ripped out > from pgcrypto it's clearly more interesting than before. Clearly. For the sake of the archives, this patch series has been applied as 17ec5fa, 0250a16 and ee97d46. -- Michael
signature.asc
Description: PGP signature