geoff@utstat.uucp (Geoff Collyer) (06/13/89)
Disclaimer: Henry and I do not subscribe to the patch-of-the-day club. We are even less happy about software whose patches precede it. However, the following bugs, all involving control messages, need fixing. We know of no other bugs in the production release. These fixes will appear in the comp.sources.unix distribution, to appear after Usenix. Sites making C news available for uucp, ftp, etc. are asked to update their C news distributions (often just cnews.Z). The old cnews.Z was 380319 bytes; the new one is 380755 bytes. The updated distribution can be retrieved from: utzoo!~/dtr/cnews.Z, utgpu!/usr/spool/uucppublic/cnews.Z, and uunet!~/news/cnews.Z by uucp, also known as uunet.uu.net:~ftp/news/cnews.Z by ftp. The copy on neat.ai.toronto.edu for ftp will be updated when neat.ai comes up after its latest disastrous crash. The copy on radio.astro.toronto.edu for ftp should be updated soon. 1. relay/mkpdir couldn't invoke itself because it was not found by its own PATH. Jean-Francois Lamy reported this one. 2. relaynews dumped core from not invalidating the last-newsgroup cache in active.c. This was found thanks to Mark Moraes's malloc. 3. control messages always got the default environment variables, even on a test system, because control.c used standard() to clear the environment. Now it uses closeall(1) instead since PATH and IFS are set at start up. The plain diffs are just 34 lines in total; they appear first and equivalent context diffs follow them. --- relay/aux/mkpdir --- 7c7 < PATH=$NEWSCTL/bin:$NEWSBIN:$NEWSPATH ; export PATH # must include this file's dir. --- > PATH=$NEWSCTL/bin:$NEWSBIN/relay:$NEWSBIN:$NEWSPATH ; export PATH # must include this file's dir. --- relay/control.c --- 173,174c173,174 < * Enforce at least minimal security: standardise the environment, < * including PATH and IFS using standard(), a local addition to libc; --- > * Enforce at least minimal security: the environment was standardised at > * startup, including PATH and IFS; close non-standard file descriptors; 184c184 < standard(); /* close most files, etc. */ --- > closeall(1); --- relay/active.c --- 36a37,40 > static struct lastngcache { > char *lnc_ng; /* newsgroup name */ > char *lnc_line; /* matching active file line */ > } lnc = { NULL, NULL }; 50,53d53 < static struct lastngcache { < char *lnc_ng; /* newsgroup name */ < char *lnc_line; /* matching active file line */ < } lnc = { NULL, NULL }; 135c135,136 < * Write back to disk the active file cache, if any. --- > * Write back to disk the active file cache, if any, and flush the > * last-newsgroup-cache, since it refers to the (now invalid) active file cache. 142a144 > lnc.lnc_ng = lnc.lnc_line = NULL; *** relay/active.c.old Mon Jun 12 04:12:47 1989 --- relay/active.c Mon Jun 12 04:12:49 1989 *************** *** 34,39 char actrelnm[] = "active"; static FILE *actfp = NULL; /* * return a pointer to the active file entry for ng --- 34,43 ----- char actrelnm[] = "active"; static FILE *actfp = NULL; + static struct lastngcache { + char *lnc_ng; /* newsgroup name */ + char *lnc_line; /* matching active file line */ + } lnc = { NULL, NULL }; /* * return a pointer to the active file entry for ng *************** *** 47,56 { register char *ngline, *ng, *flag; register int loopbreak = 100; - static struct lastngcache { - char *lnc_ng; /* newsgroup name */ - char *lnc_line; /* matching active file line */ - } lnc = { NULL, NULL }; if (lnc.lnc_ng != NULL && STREQ(lnc.lnc_ng, ang)) return lnc.lnc_line; --- 51,56 ----- { register char *ngline, *ng, *flag; register int loopbreak = 100; if (lnc.lnc_ng != NULL && STREQ(lnc.lnc_ng, ang)) return lnc.lnc_line; *************** *** 132,138 } /* ! * Write back to disk the active file cache, if any. */ statust actsync() --- 132,139 ----- } /* ! * Write back to disk the active file cache, if any, and flush the ! * last-newsgroup-cache, since it refers to the (now invalid) active file cache. */ statust actsync() *************** *** 140,145 register statust status = ST_OKAY; if (actfp != NULL) { status |= actfsync(actfp); if (nfclose(actfp) == EOF || status != ST_OKAY) { warning("error writing `%s'", ctlfile(actrelnm)); --- 141,147 ----- register statust status = ST_OKAY; if (actfp != NULL) { + lnc.lnc_ng = lnc.lnc_line = NULL; status |= actfsync(actfp); if (nfclose(actfp) == EOF || status != ST_OKAY) { warning("error writing `%s'", ctlfile(actrelnm)); *** relay/control.c.old Mon Jun 12 05:08:34 1989 --- relay/control.c Mon Jun 12 05:08:34 1989 *************** *** 170,177 * runctlmsg is called from a child of relaynews, so it must always * call _exit() rather than exit() to avoid flushing stdio buffers. * ! * Enforce at least minimal security: standardise the environment, ! * including PATH and IFS using standard(), a local addition to libc; * reject shell metacharacters in ctlcmd. */ STATIC void --- 170,177 ----- * runctlmsg is called from a child of relaynews, so it must always * call _exit() rather than exit() to avoid flushing stdio buffers. * ! * Enforce at least minimal security: the environment was standardised at ! * startup, including PATH and IFS; close non-standard file descriptors; * reject shell metacharacters in ctlcmd. */ STATIC void *************** *** 181,187 register char *cmd; register int cmdstat; ! standard(); /* close most files, etc. */ if (!safecmd(ctlcmd)) { (void) fprintf(stderr, "%s: control `%s' looks unsafe to execute\n", progname, ctlcmd); --- 181,187 ----- register char *cmd; register int cmdstat; ! closeall(1); if (!safecmd(ctlcmd)) { (void) fprintf(stderr, "%s: control `%s' looks unsafe to execute\n", progname, ctlcmd); *** relay/aux/mkpdir.old Mon Jun 12 21:07:27 1989 --- relay/aux/mkpdir Mon Jun 12 21:07:28 1989 *************** *** 4,10 # =()<. ${NEWSCONFIG-@<NEWSCONFIG>@}>()= . ${NEWSCONFIG-/usr/lib/news/bin/config} export NEWSCTL NEWSBIN NEWSARTS ! PATH=$NEWSCTL/bin:$NEWSBIN:$NEWSPATH ; export PATH # must include this file's dir. umask $NEWSUMASK --- 4,10 ----- # =()<. ${NEWSCONFIG-@<NEWSCONFIG>@}>()= . ${NEWSCONFIG-/usr/lib/news/bin/config} export NEWSCTL NEWSBIN NEWSARTS ! PATH=$NEWSCTL/bin:$NEWSBIN/relay:$NEWSBIN:$NEWSPATH ; export PATH # must include this file's dir. umask $NEWSUMASK -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu ``... skill such as yours is evidence of a misspent youth.'' - Herbert Spencer
jbuck@epimass.EPI.COM (Joe Buck) (06/14/89)
In article <1989Jun13.034954.144@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Disclaimer: Henry and I do not subscribe to the patch-of-the-day club. >We are even less happy about software whose patches precede it. >However, the following bugs, all involving control messages, need >fixing. We know of no other bugs in the production release. Geoff, if you were a member of the patch-of-the-day club, you would know how to issue a patch. The patch you post does not change any version numbers or strings, does not modify a "patchlevel" file, or anything of the sort. It will be extremely difficult for people to ascertain which version of C news they have if you persist in handling bug fixes in this fashion; we'll be back to the bad old days of 2.10.2 news with a different set of local hacks on every system on the net. Please, for the sake of your own reputation, be more careful in the future as to how you distribute patches. Larry Wall's system actually does work; he successfully got the net as a whole to apply 40 (count 'em, 40) patches to rn and the sucker actually works, because there are version strings and a patchlevel file and other stuff that lets you have confidence that the patch was done right. -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
geoff@utstat.uucp (Geoff Collyer) (06/14/89)
Henry and I discussed modifying version numbers and the like yesterday, but decided that we don't want to *have* multiple versions of C news in the field, if we can avoid it. (We don't particularly like version numbers like C news 3.11vr2 and do not want to buy into the patchlevel bureaucracy, since it encourages patches by making them easy. We want C news to rapidly converge on a stable version.) One can distinguish the initial production distribution from the updated one by size or by grepping for "/relay" in relay/aux/mkpdir; it you find one, you have the updated one. Given that Henry is at Usenix this week, and thus difficult (though not impossible) to reach, I am going to continue this policy for the rest of the week (or until Henry and I decide otherwise): any other bugs fixed will be fixed on the usual ftp or uucp distribution sites (utzoo, utgpu, uunet, utai, radio.astro, osu-cis, etc.) as soon as possible, posted to news.software.b and comp.sources.d, mailed to our beta testers, and mailed to Rich Salz for inclusion with the comp.sources.unix release (he's at Usenix too this week). The comp.sources.unix release (which will match the ftp and uucp distributions) will be the base release for any future changes. Consider also that yesterday's fixes (ignoring updates to comments) amounted to moving 4 lines of code, changing 2 lines, and adding 1 line. If you don't trust the patch program to apply the context diffs, it's easy to fix the sources by hand. We have had a couple bug reports today. Sigh. One I need to investigate and the other seems to be configuration problems which Henry will have to sort out. We do want to stop issuing patches as soon as we can. If we are unfortunate enough to have to issue patches after the comp.sources.unix release, we will have to reconsider version numbers or patchlevel files or something. If we are fortunate, it should not be an issue. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu ``... skill such as yours is evidence of a misspent youth.'' - Herbert Spencer
Makey@LOGICON.ARPA (Jeff Makey) (06/14/89)
In article <1989Jun13.211659.11139@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Henry and I discussed modifying version numbers and the like yesterday, >but decided that we don't want to *have* multiple versions of C news in >the field, if we can avoid it. Realistically, you can't avoid it (you said that bug reports are already coming in). There *will* be multiple versions of C news in the field, so you might as well make it easy to distinguish between them by using version numbers. The sooner you start doing this, the less painful it will be. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
tneff@bfmny0.UUCP (Tom Neff) (06/14/89)
In article <1989Jun13.211659.11139@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Henry and I discussed modifying version numbers and the like yesterday, >but decided that we don't want to *have* multiple versions of C news in >the field, if we can avoid it. Well intentioned but this is a doomed policy. News is too complex to survive out here in reality without patches and versions. > (We don't particularly like version >numbers like C news 3.11vr2 and do not want to buy into the patchlevel >bureaucracy, since it encourages patches by making them easy. The reality is that if C news needs patching and you do not assume control of the process is a responsive way, the process will go forward unofficially and even more chaos will result. Do you really want "samizdat patches" to get Suns or Strides or whatever working right? > We want C >news to rapidly converge on a stable version.) The stability of a version derives from the quality and thoroughness of the software as distributed - not from the unavailability of fixes. I agree it's possible to get carried away with patch fever - there should be firm goals, say one patchlevel every 6 months for a while, then every year or two - but version numbers MUST exist reliably or things will become a hopeless muddle. Grepping for "/relay" on THIS version, something else NEXT version is no answer. Infrequent updates should be a practical goal, not an obsession. -- You may not redistribute this article for profit. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET
dtynan@altos86.Altos.COM (Dermot Tynan) (06/17/89)
I can't say that I agree with you on your ideas of version control. However, I *do* have to admit that YOU are the one who did the work, and all I can do is comment. With that said... In article <1989Jun13.211659.11139@utstat.uucp>, geoff@utstat.uucp (Geoff Collyer) writes: > Henry and I discussed modifying version numbers and the like yesterday, > but decided that we don't want to *have* multiple versions of C news in > the field, if we can avoid it. (We don't particularly like version > numbers like C news 3.11vr2 and do not want to buy into the patchlevel > bureaucracy, since it encourages patches by making them easy. I agree with your first statement. Multiple versions are rather painful. As evidenced by the "#ifdef OLD" stuff in B news. However, not buying into the patch phenomenon (which, by the way, I consider a fascinating piece of code!) because it encourages patches, can be compared to current controversies over contraceptives encouraging sex. > We want C > news to rapidly converge on a stable version.) One can distinguish the > initial production distribution from the updated one by size or by > grepping for "/relay" in relay/aux/mkpdir; it you find one, you have the > updated one. When a product (such as C news) goes into mass-distribution it is only natural that some problems will be found. Even with extensive beta-site testing. This is the legacy of Murphy. Trying to identify what version one has, is *very* easy when one can look at 'patchlevel.h'. Having to grep for keywords is not a very good revision policy. Ask Andy Tanenbaum about the problems associated with 'size' comparisons. I doubt you will find many sites which have similar sized archives, for whatever reason. Having patchlevels ensures that a) patches are applied, and b) that they are applied in the right order. > Consider also that yesterday's fixes (ignoring updates to comments) > amounted to moving 4 lines of code, changing 2 lines, and adding 1 line. > If you don't trust the patch program to apply the context diffs, it's > easy to fix the sources by hand. > > Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu What you can do, is use patch to apply the changes, and diff the file against file.orig. If the changes aren't too extensive, you can thus audit the work done by patch. I find this much more reasonable than trying to apply patches by hand. Usually, though, patch will complain if it finds anything wrong. Therefore, if you run it, and it completes quietly, you can be pretty confident that the changes were made correctly. Comments... - Der -- My address: dtynan@altos86.Altos.COM (Hopefully!) Otherwise: {altnet,amdahl,pyramid,sun}!altos86!dtynan --- "May the blessings of Jeyes Fluid fall upon you" ---
henry@utzoo.uucp (Henry Spencer) (06/20/89)
In article <14400@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >>... we don't want to *have* multiple versions of C news in >>the field, if we can avoid it. > >Well intentioned but this is a doomed policy. News is too complex to >survive out here in reality without patches and versions. I fear you are probably correct. I had some ideas on how to deal with it, but I had hoped that the issue could be postponed until I was back from Usenix and the comp.sources.unix version had gone out to the world. Stay tuned. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (06/21/89)
In article <3309@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >Geoff, if you were a member of the patch-of-the-day club, you would >know how to issue a patch... This one is more my fault than Geoff's. I had some plans for how to deal with the situation, but I'd hoped that the first patch would hold off until I was back from Usenix and had time to do something about it. (Things got very hectic in the last few days before my departure.) Unfortunately, the first patch was serious enough that it seemed inadvisable to wait. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu