Message-ID: Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 In-Reply-To: X-RT-Interface: Web Content-Disposition: inline References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 1380 On Fri Nov 10 17:55:57 2017, stephen wrote: > Although this switch may go away (if the proposal to make the presence > of OpenSSL a mandatory requirement goes ahead), => IMHO you mean a crypto library a mandatory requirement (BTE with native PKCS#11 there is no choice: PKCS#11 is always used for hash and hmac). > --enable-openssl-hash and --disable-openssl-hash have no effect on the > outward functionality of BIND: hash values are calculated whatever the > setting of the switch, the only difference being the functions that > calculate them. In both cases, the tests pass. So how can we be > certain that the correct function is being picked up? => the only way is indirect: OpenSSL is faster. I recommend the iterated hash (NSEC3) as it makes the most visible difference. > One way (without modifying the code to output a log message) is to > look > at the undefined symbols in an object file where the hash is > calculated > (e.g. lib/isc/hmacsha.o). If HMAC_CTX_init is undefined, BIND is using > an external provider (i.e. OpsnSSL) to calculate the hash function; if > it > does not contain the undefined symbol, it is using its internal hash > functions. => this works too. > This is probably not something that fits easily into the BIND test > suite and may be best done by an external test. => as the effect is not so visible perhaps we should simply give up?