This commit reverts the previous change to use system provided
entropy, as (SYS_)getrandom is very slow on Linux because it is
a syscall.
The change introduced in this commit adds a new call isc_nonce_buf
that uses CSPRNG from cryptographic library provider to generate
secure data that can be and must be used for generating nonces.
Example usage would be DNS cookies.
The isc_random() API has been changed to use fast PRNG that is not
cryptographically secure, but runs entirely in user space. Two
contestants have been considered xoroshiro family of the functions
by Villa&Blackman and PCG by O'Neill. After a consideration the
xoshiro128starstar function has been used as uint32_t random number
provider because it is very fast and has good enough properties
for our usage pattern.
The other change introduced in the commit is the more extensive usage
of isc_random_uniform in places where the usage pattern was
isc_random() % n to prevent modulo bias. For usage patterns where
only 16 or 8 bits are needed (DNS Message ID), the isc_random()
functions has been renamed to isc_random32(), and isc_random16() and
isc_random8() functions have been introduced by &-ing the
isc_random32() output with 0xffff and 0xff. Please note that the
functions that uses stripped down bit count doesn't pass our
NIST SP 800-22 based random test.
- Replace external -DOPENSSL/-DPKCS11CRYPTO with properly AC_DEFINEd
HAVE_OPENSSL/HAVE_PKCS11
- Don't enforce the crypto provider from platform.h, just from dst_api.c
and configure scripts
The three functions has been modeled after the arc4random family of
functions, and they will always return random bytes.
The isc_random family of functions internally use these CSPRNG (if available):
1. getrandom() libc call (might be available on Linux and Solaris)
2. SYS_getrandom syscall (might be available on Linux, detected at runtime)
3. arc4random(), arc4random_buf() and arc4random_uniform() (available on BSDs and Mac OS X)
4. crypto library function:
4a. RAND_bytes in case OpenSSL
4b. pkcs_C_GenerateRandom() in case PKCS#11 library
Replace dns_fixedname_init() calls followed by dns_fixedname_name()
calls with calls to dns_fixedname_initname() where it is possible
without affecting current behavior and/or performance.
This patch was mostly prepared using Coccinelle and the following
semantic patch:
@@
expression fixedname, name;
@@
- dns_fixedname_init(&fixedname);
...
- name = dns_fixedname_name(&fixedname);
+ name = dns_fixedname_initname(&fixedname);
The resulting set of changes was then manually reviewed to exclude false
positives and apply minor tweaks.
It is likely that more occurrences of this pattern can be refactored in
an identical way. This commit only takes care of the low-hanging fruit.
Emit fatal failures on locale to ACE encoding
Separate idnout support, disable it for libidn2 < 2.0
Add custom path to libidn. Leave default path for multilib support.
Allow turning off IDN input processing by dig option
Improve documentation, fix support in host
Fix configure changes to adjust help text
Use strlcpy with size guard
Improve IDN variants choosing. Fix idn2 function name.
Remove immediate idn_locale_to_ace and idn_ace_to_locale.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Added two new configure options:
--with-libidn2 - to enable IDN using GNU libidn2
idnkit, libidn and libidn2 support can not be used at the same time.
NOTE: libidn2 does not support punycode back to Unicode
characters, so support for this is missing.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Removed iconv, convert directly from locale to ACE
Fix libidn2 and idnkit origin appending
Make IDN options in help less different
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Added new configure option:
--with-libidn - to enable IDN using GNU libidn
Renamed configure option:
--with-idn to --with-idnkit to make the option usage more clear
idnkit and libidn support can not be used at the same time.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
4756. [bug] Interrupting dig could lead to an INSIST failure after
certain errors were encountered while querying a host
whose name resolved to more than one address. Change
4537 increased the odds of triggering this issue by
causing dig to hang indefinitely when certain error
paths were evaluated. dig now also retries TCP queries
(once) if the server gracefully closes the connection
before sending a response. [RT #42832, #45159]