Date: Mon, 27 Sep 2004 17:11:41 +0200 From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> To: Scott Long <scottl@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: FreeBSD 5.3-BETA6 available Message-ID: <m3brfr691u.fsf@merlin.emma.line.org> In-Reply-To: <415812AD.2090901@FreeBSD.org> (Scott Long's message of "Mon, 27 Sep 2004 07:16:29 -0600") References: <415720FD.8080603@samsco.org> <m3oejs3tom.fsf@merlin.emma.line.org> <415812AD.2090901@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long <scottl@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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3brfr691u.fsf>