instead of keeping it always == 1. (The ifile version number is
increased on vfree.) May address PR #7213, but I haven't been able to
test thoroughly enough to say for sure.
references (locked for VOP_INACTIVE at the end of vrele) and it's okay.
Check the return value of lfs_vref where appropriate.
Fixes PR #s 10285 and 10352.
rpcbind version 3 and 4 clients will try broadcasts using both the old
and new protocol for IPv4, the double amount of packets may come in,
causing bogus "service looping" events in inetd.
pull in just about all of the differences from the crypto-us telnet
suite (which includes Kerberos 4 and connection encryption support).
Also bring in the Kerberos 5 support from the Heimdal telnet, and
frob a little so that it can work with the non-Heimdal telnet suite.
There is still some work left to do, specifically:
- Add Heimdal's ticket forwarding support to the Berkeley Kerberos 4
module.
- Add connection encryption support to the Heimdal Kerberos 5
module. Hints on this can be taken from the MIT Kerberos 5
module which still exists in crypto-us.
However, even with the shortcomings listed above, this is a
better situation than using the stock Heimdal telnet suite,
which does not understand the IPSec policy stuff, and is also
based on much older code which contains bugs that we have already
fixed in the NetBSD sources.
- for bold characters, only blit the leftmost ftwidth pixels per character
cell row. The rightmost row which used to be printed would have been
overwritten formerly by the next character on sequential output, so no
visible change will result most of the time.
This fixes two problems:
* USE_C_BFOPS (which only works for 8 pixel wide fonts) blits the same
for bold characters now... it used to print the rightmost 8 pixel columns
of the bold-smeared characters
* we no longer need a reserved 1 pixel column at the right end of the screen.
That is, a 640x400 screen will hold 80x50 charactes with the 8x8 font.
des_new_random_key(), and des_init_random_number_generator()
from the crypto-us libdes.
While I'm here, fix a serious bug in des_init_random_number_generator()
whereby the accumlated data to be hashed was zero'd *before* actually
being hashed. NOTE: The bug only affects people who are not using the
rnd(4) in-kernel random number generator, and it is worth noting that
the resulting keys are not always the same, but are likely easy to
determine.
