Re: FreeBSD 5.3-BETA6 available

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.
>>    http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/45738
>>    http://lists.freebsd.org/pipermail/freebsd-current/2004-September/037819.html
>
> 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 
http://www.opengroup.org/onlinepubs/009695399/utilities/unset.html

(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
address this.)

>> 2. tcpdump IPv6CP segfaults are still open as of BETA5, FIX IS
>> AVAILABLE:
>>    http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/71453
>>
>
> 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
someone insisted).

>> 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
> properly.

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
symptom.

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
>> NIS
>>    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
> lookups.

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
experienced.

>> 5. default inetd configuration denial of service bug, conf/33670, is
>> still
>>    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
>> whether
>>    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.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)