On Wed, 26 Jun 2019, Reynir Björnsson wrote:
> Hello,
>
> I have noticed a potential NULL pointer dereference in the recent code
> for ssh key shielding. Essentially, during error handling
> explicit_bzero(enc, enclen) is called. This should be fine when enc is
> NULL as long as enclen is zero. H
We have two variables with the same meaning. db_active is used in way
more places, so let's nuke db_is_active.
Now that db_active is in for a while already and not
guarded by DDB anymore, take the opportunity to clean up some places
that use it.
---
sys/arch/macppc/dev/zs.c | 8 ++
Hi.
Your diff looks correct. I can't see a reason for the "ar_datalen == -1"
special case here.
According to my tests, gethostbyname() with a bogus nameserver (not
responding, not reachable, ...) now fails with TRY_AGAIN, but still
fails with HOST_NOT_FOUND if "bind" is not set on the lookup
dire
The VPN encoded address families (SAFI 128) were not implemented in the
mrt dump parser. Since the regress test actually dumps some of those it is
time to also parse them. This diff implements that.
I stared to pass the verbose flag down instead of failing hard with
errx(). I'm still debating with
Hello,
I have noticed a potential NULL pointer dereference in the recent code
for ssh key shielding. Essentially, during error handling
explicit_bzero(enc, enclen) is called. This should be fine when enc is
NULL as long as enclen is zero. However, there is one spot in the code
where a malloc() cal
Found this yesterday while playing with a dnsbl filter for smtpd during
network outage and found that gethostbyname returns HOST_NOT_FOUND.
Glibc, musl, and FreeBSD return TRY_AGAIN.
This is annoying because for a DNSBL I need to be able to differentiate
between a resolver not being available and
