Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 486592 - multilib-build.eclass sets IFS which breaks paludis
Summary: multilib-build.eclass sets IFS which breaks paludis
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Michał Górny
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-30 16:43 UTC by Philipp
Modified: 2017-11-08 09:30 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Log of failing resolve (cave-log.txt,37.69 KB, text/plain)
2013-09-30 16:57 UTC, Philipp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp 2013-09-30 16:43:36 UTC
The following commit

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/multilib-build.eclass?r1=1.20&r2=1.21

breaks useq of paludis because IFS is being changed. portage is not affected because it sets IFS=$' \t\n'. The question to ask here is where a package manager is supposed to set IFS.
Comment 1 Philipp 2013-09-30 16:57:51 UTC
Created attachment 359810 [details]
Log of failing resolve
Comment 2 Timothy Jones 2013-09-30 19:28:06 UTC
Same issue here.
Comment 3 Ciaran McCreesh 2013-09-30 19:33:46 UTC
We should probably specify in PMS whether the PM should deal with strange values in IFS and other variables. Portage is fairly random in where it does and doesn't set its own IFS, which makes me think this has been one of those "work around it as bugs show up" problems, which is of course the wrong thing to do.

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=04f8e1e2
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-10-01 17:44:51 UTC
I've changed the way splitting is done to avoid changing IFS. This should work-around the issue for Paludis users.

Re-assigning to Paludis maintainer, since it is still a bug in Paludis. Since PMS doesn't say a thing about IFS, it is incorrect for Paludis helpers to rely on any particular value of it.
Comment 5 Ciaran McCreesh 2013-10-01 17:51:25 UTC
We should be deciding this properly and speccing it, and for all helper functions. Portage is rather arbitrary about where it does and doesn't sanitise IFS in helpers. Also, this was a fairly recent Portage change, so it's not something that's "been that way all along".
Comment 6 Ulrich Müller gentoo-dev 2013-10-01 18:36:51 UTC
(In reply to Ciaran McCreesh from comment #5)
> We should be deciding this properly and speccing it, and for all helper
> functions.

But what should we specify? IFS only? I'd guess that also some of the shopt or set options can induce breakage.
Comment 7 Ciaran McCreesh 2013-10-01 18:41:50 UTC
Yeah, that's the annoying bit. PATH could also screw with things in some cases too. From a spec perspective, it might be easiest to just say "if ebuilds screw around with stuff, they have to undo it for helper calls"...
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-10-01 18:52:21 UTC
And we get to the point when we provide users with opaque helper bits which can rely on almost anything being untouched, and we basically gain nothing.
Comment 9 Ciaran McCreesh 2013-10-01 18:56:08 UTC
Yeah, it's that or we specify eeeeeverything and keep going back and checking carefully each time we change bash versions.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-10-01 19:02:11 UTC
...or we expect PM authors to sanitize the environment inside helper functions as necessary.
Comment 11 Ciaran McCreesh 2013-10-01 19:07:47 UTC
How do we define "as necessary"? Are we including PATH, for example? What about weird shopts?
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-10-01 19:19:02 UTC
(In reply to Ciaran McCreesh from comment #11)
> How do we define "as necessary"? Are we including PATH, for example? What
> about weird shopts?

Sure, whatever is necessary. PM has to set it all up for the build process anyway, there's no reason it couldn't reset it locally within the helper. Most of it would be solved if helpers were actually external executables rather than functions.

As for PATH, the current wording makes helpers reside in PATH defined by the PM. Therefore, users can't clear it from the default.
Comment 13 Ulrich Müller gentoo-dev 2013-10-01 19:20:20 UTC
Not sure if there's even an effective way to sanitise the shell's state, given that there are creative ways to redefine shell builtins or define aliases.
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-10-01 19:25:36 UTC
(In reply to Ulrich Müller from comment #13)
> Not sure if there's even an effective way to sanitise the shell's state,
> given that there are creative ways to redefine shell builtins or define
> aliases.

I think the most effective way is to run an external helper. Unless I'm missing something, this shouldn't pass anything through except for exported environment variables.
Comment 15 Ciaran McCreesh 2013-10-01 19:30:40 UTC
Don't we specify some of these to be builtins? Pretty sure we had to in the old days because external commands couldn't die.
Comment 16 Ulrich Müller gentoo-dev 2013-10-01 20:11:18 UTC
(In reply to Ciaran McCreesh from comment #15)
> Don't we specify some of these to be builtins?

We do. Some of them cannot be external commands because they modify environment variables.

I tend to go with comment #7, because restoring the state is much easier in the caller than in the called function. Also, calling random functions with changed IFS _is_ bad style.
Comment 17 Ulrich Müller gentoo-dev 2017-11-08 09:30:08 UTC
OTOH, the spec is quite clear about the "use" command:
"Returns shell true (0) if the first argument (a USE flag name) is enabled, false otherwise. If the flag name is prefixed with !, returns true if the flag is disabled, and false if it is enabled."

So the PM should make sure that its behaviour for word splitting e.g. of IUSE_EFFECTIVE is sane, and should sanitise IFS if necessary.