[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070427/24ffb992/attachment.sig>