csplit, expand, factor, fmt, fold, join, md5sum, nl, od, paste, pathchk, pinky, pr, printf, sha1sum, shred, sum, tac, tail, test, tsort, unexpand, users The above list of files are located in /bin. They should not be there. They are not owned by any package. As such, as /bin appears before /usr/bin in ${PATH}, upgrades to the packages which are supposed to own the aforementioned binaries don't actually upgrade the binary which gets used. The same also goes for /usr/sbin/gcc-config. They are put there, as far as I can tell, by extracting the stage tarball. These files, in the interests of security (amongst other things), should be removed from the stage tarballs on all architectures. If a security flaw in one of the above files is found, an upgrade does not replace it. Whether it is the case that the above are in the wrong place, or coreutils is installing things in the wrong place, is a matter I leave to you. For the security reason I have marked this as "major"; if you feel this is inappropriate please feel free to change it.
EDIT: Also, if I've assigned this incorrectly, I apologise, and please move it on to where it should be.
so delete them off your system somewhere an upgrade went out of sync leaving those files stranded as you say, no package owns them (and they dont exist on my system anymore)
Not on my system, either.
I did delete them off my system. But they're still on everyone else's system. I suspect that these may actually be part of the AMD64 stage tarballs - reopening and marking AMD64-specific until I can verify or otherwise.
As an AMD64 devel I've verified that these files do not exist in /bin on my system. If another AMD64 user can verify that they do not exist, we will mark it as invalid and assume this was isolated.
Rob et. al. I have the files on my system, as does herbie64 in #g-amd64. Lv does not. HOWEVER... I personally have recovered from broken glibc with tarballs and played with all manner of stage-tarballs on this box, so I suspect it was an isolated incident that led to this occurance on my box. Are you sure that maybe you too haven't b0rk3n your system in the past and tried to copy the /bin from the LiveCD?? I checked all the 2004.2(-testing) stage-tarballs for tsort and it's in /usr/bin in each.
I have these files lurking in my /bin also. I happened to still have the stage tarball I used to install: 55f82e96d0945afe1b9a75df9cf84879 stage1-amd64-2004.1.tar.bz2 and they are indeed contained within.
This was a problem with the 2004.1 stage tarballs, but isn't with the (pre-)2004.2 stage tarballs. I would suggest that special note is taken of this bug if coreutils ever gets hit by a critical bug of any sort, as those erroneous files in /bin will prevent any security fixes, for example, to the above files taking effect. For now, changing bug status to REMIND.