right now. new address-of-packed-member and format-overflow
warnings have new GCC_NO_ADDR_OF_PACKED_MEMBER amd
GCC_NO_FORMAT_OVERFLOW variables to remove these warnings.
apply to a bunch of the tree. mostly, these are real bugs that
should be fixed, but in many cases, only by removing the 'packed'
attribute from some structure that doesn't really need it. (i
looked at many different ones, and while perhaps 60-80% were
already properly aligned, it wasn't clear to me that the uses
were always coming from sane data vs network alignment, so it
doesn't seem safe to remove packed without careful research for
each affect struct.) clang already warned (and was not erroring)
for many of these cases, but gcc picked up dozens more.
The brackets are required when using numeric IPv6 addresses as they
contain colons as part of their syntax. We do not enforce that the
thing in the brackets is a numeric IPv6 address - this matches scp
syntax and behavior.
from rename (for existing target) and calling setback is not
appropriate in that context. Do that call instead directly in the
callers (remove, rmdir).
From Nicola Girardi, part of PR/54829.
advance in AUTOVAR, do it right before we need them. Do no reuse tags.
If we are going to use sequential tags, we might as well try to make
them really sequential.
newly opened fid as it's already there. This is redundant and also
seems to confuse inferno when issued against the root directory. Now
you can ls the mount point of
styxlisten -A 'tcp!*!styx' export /
While here fix the seek logic to actually repeatedly seek forward
instead of always doing it from zero.
in the raw device using the new -J option. This avoids the use of
getdiskrawname which is not particularly rump safe in this context and
insures that the rump container device is used for cleaning, not the
outer device.
The implementation enables to work with a server talking 9P2000.u. However, it
doesn't use the extended fields yet; it just ignores those of received messages
and sets "please ignore" values to those of sending messages such as zero-length
strings and maximum unsigned values.
The feature is enabled by the -u option.
Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
msaitoh