On Fri, Mar 31, 2017 at 04:40:07PM +0300, Aleksander Alekseev wrote:
> > > And it seems to me that this is caused by the routines of OpenSSL.
> > > When building without --with-openssl, using the fallback
> > > implementations of SHA256 and RAND_bytes I see no warnings generated
> > > by scram_build_verifier... I think it makes most sense to discard that
> > > from the list of open items.
> >
> > FWIW a document of the function says that,
> >
> > https://www.openssl.org/docs/man1.0.1/crypto/RAND_bytes.html
> >
> > > The contents of buf is mixed into the entropy pool before
> > > retrieving the new pseudo-random bytes unless disabled at compile
> > > time (see FAQ).
> >
> > This isn't saying that RAND_bytes does the same thing but
> > something similar can be happening there.
>
> OK, turned out that warnings regarding uninitialized values disappear
> after removing --with-openssl. That's a good thing.
Does this remove the noise under --with-openssl?
--- a/src/port/pg_strong_random.c
+++ b/src/port/pg_strong_random.c
@@ -104,7 +104,10 @@ pg_strong_random(void *buf, size_t len)
*/
#if defined(USE_OPENSSL_RANDOM)
if (RAND_bytes(buf, len) == 1)
+ {
+ VALGRIND_MAKE_MEM_DEFINED(buf, len);
return true;
+ }
return false;
/*
> What about all these memory leak reports [1]? If I see them should I just
> ignore them or, if reports look false positive, suggest a patch that
> modifies a Valgrind suppression file? In other words what is current
> consensus in community regarding Valgrind and it's reports?
Pass --leak-check=no; PostgreSQL intentionally leaks a lot.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
