Re: allowed uses of non-baseline CPU extensions
On Tue, Oct 24, 2017 at 4:25 AM, Philipp Kern wrote:
> I think that's a very important observation. I don't think you can
> necessarily conclude that the system where the package is initially
> installed is the system were the code is executed.
Indeed.
> You argued in #873733[1] that you'd rather see the package installation
> fail. I see the appeal of that, especially to alert the admin. But there
> needs to be some kind of switch to flip to ignore these. Right now it
> seems that switch is IGNORE_ISA in the environment. But given the
> attempts to get a cleaner environment for dpkg, I'm not sure that's the
> best file. I.e. it'd be better to also have a flag file.
The discussion on IRC between myself, apt folks and Adam was leaning
towards an apt config & cmdline option.
There was an interesting idea about pinning, but in the end it was
concluded that this wouldn't be workable because the pinning would
only be generated after apt had already started.
>From there the discussion moved towards integrating this into apt, but...
There is still the question of if we want to allow deviation from the
baseline at all and if we don't, who is going to do the work to
achieve the goal of falling back on baseline code at runtime for all
upstreams.
> As a side note I'm also amazed that there's literally a uuencoded blob
> in the preinst that contains binary code that is unpacked and executed,
> just like any malware would do. :)
It cannot use files from the package, since those are not available in preinst:
https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: