FreeBSD 5.3-BETA6 available
ma at dt.e-technik.uni-dortmund.de
Mon Sep 27 08:11:47 PDT 2004
Scott Long <scottl at FreeBSD.org> writes:
>> 1. /bin/sh "unset" is still in violation of IEEE Std 1003.1, 2004
>> edition. FIX IS AVAILABLE, bug has been open for many months, has
>> persisted in BETA4 and 5.
> I'll defer this to the standards folks.
Finally someone picks these up -- much appreciated, thank you very
much, it's a relief to be at least heard.
The fix for this has been pending for almost two years now, was filed
against 4.7, the fix is _trivial_ and was filed on 2002-11-26.
Given that this has been lying unattended for another ten days on
-standards already, can't we just commit this on probation and back out
as problems arise in BETA7?
I cannot imagine anyone relying on the bug in /bin/sh, but some test
scripts in third-party software stumble across this when trying to
sanitize their environment and need to resort to ugly workarounds such
as SOMEVAR= ; unset SOMEVAR.
The standard is clear, see 5th paragraph in DESCRIPTION of
(Julian Elischer inquired if someone had taken interest last Tuesday but
the report is still assigned to freebsd-bugs, so he hasn't claimed it
yet, so I presume he hasn't sufficient interest or commit permission to
>> 2. tcpdump IPv6CP segfaults are still open as of BETA5, FIX IS
> Looks pretty straight-forward. Anyone want to import the fix from the
> tcpdump CVS tree?
I don't have a commit bit (nor am I asking for one but I'd take one if
>> 3. data corruption on unaligned block access bug, kern/60313,
>> is still open and unpatched AFAICS
> Is this actually an issue in FreeBSD 5? In the audit trail of the PR,
> Bruce Evans seems to concede that GEOM checks block alignment
I'll try again with a current beta and follow up on this with what I've
found; at the time I filed it, there was a problem with a different
If someone else has a SCRATCH partition that can lose all data, (comment
out swap and reboot then you'll have one), a test program is part of
http://www.freebsd.org/cgi/query-pr.cgi?pr=60313 -- if someone checks
first, please Cc: me to avoid duplicated effort.
>> 4. NIS is still faulty in pretending users aren't there when in fact
>> cannot tell if an account exists; bin/46866 is still open and unpatched
> While it's a compelling argument to follow the Solaris behavior, it's
> also a compelling argument to have a reasonable timeout on password
The problem is that the system cannot communicate the difference between
"temporary failure, try again" and "no such user", and can lead, for
instance, to a bogus _PERMANENT_ reject of a mail, which, in turn, can
trigger an unsubscription -- to name just one failure case I've
>> 5. default inetd configuration denial of service bug, conf/33670, is
>> open and unpatched AND A LAST CHANCE TO FIX NOW
> inetd is not turned on by default.
OK, I'll consider this closed. Feel free to close conf/33670; I'd
suggest that the inetd documentation mentions that an connection rate
limit doesn't bound the absolute client count and can result in DoS.
> What do OpenBSD and NetBSD do?
> What does Linux do with xinetd?
Depends on the distribution. I cannot say anything about OpenBSD or
NetBSD, SuSE Linux 9.1 doesn't automatically start services from inside
inetd or xinetd AFAICS.
>> 6. (portsmgr issue) no "yes or no" or whatsoever for my inquires
>> ports/72017 can be committed in spite of the freeze. It's a
>> bugfix-only update.
>> Please state which of these will be fixed before 5.3-RELEASE and what
>> further help is needed with these.
Pav has claimed this and is waiting for portmgr approval which I already
asked about when filing the bug, no-one stirred themselves yet.
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
More information about the freebsd-current