On Thu, Apr 26, 2007 at 09:43:57PM -0500, Michael E Brown wrote: > On Fri, Apr 27, 2007 at 02:26:08AM +0200, Axel Thimm wrote: > > > In contast the bin64 proposal does not even have to look into the > > specfile (unless the specfile hardcoded /usr/bin or does other > > forbidden things we already have purged away from Fedora), no > > subpackage inflation, no overcmplicated intra- and interpackage > > depency relations, no tadpole loop depedencies. > > The biggest issue I see with any bin64 issue is that you have a *huge* > installed base of legacy software (and legacy software developers) who > just assume that you can set a clean PATH to /usr/bin:/bin, and possibly > /usr/sbin:/sbin. Lots of security-conscious software will do things like > reset the PATH. That's correct, but how many packages will that affect? cron and what else? It's a low count number, and if the package does not allow to tune these during build it's questionable anyway, since there is no "one true and only path". For example we already have the very non-canonical legacy kerberos path example, and kerberos does count as security related. Did the non-canonical path of kerberos really block its introduction? > Now all of a sudden, that no longer works. You have to either trust that > PATH isnt set maliciously, or you have to know the arch you are on and > that arch's specific peculariarities: prefer bin32 or bin64? etc. No, never trust the path, and never detect at runtime. The bin64 proposal does the work at build time. rootkit.x86_64's resetting will have both paths, and rootkit.i386 only the non-bin64 paths. > This sounds like a lot of pain and agony for lots of people and > third-party software. Ask yourself if that was that the case with kerberos, too. Ask yourself how "big" the pain with /usr/X11R6/bin was. Compare that "pain" with the pain we are having now with multilib, or we would have with rewriting each and every specfile that has any bin components. No solution is just pressing a button, but there are some that require like 10% work of others with better results. -- Axel.Thimm at ATrpms.net
Attachment:
pgpSuP3865dca.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
