Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
Re: roucaries bastien > The problem is the base64 encoded binary. I agree that base64 there is weird, but does that really need an explicit mention in the policy? If I were you, I'd just remove that weirdness and move along. Christoph
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
> "Bill" == Bill Allombert writes: Bill> What if the user change their CPU afterward ? This should Bill> probably be tested at boot time instead. There was a long thread on debian-devel about the potential issues with isa-support: https://lists.debian.org/yj5dazgacdgtp...@angband.pl So, what you say is true, but isa-support has an existing interface it needs to stay consistent with that involves checking at install time. I think we're all agreed that we want to find alternatives to that interface, but the policy question is about what ways of implementing the existing interface are consistent with policy.
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
On Tue, Aug 16, 2022 at 07:22:21AM -0600, Sam Hartman wrote: > > "Bastien" == Bastien Roucariès writes: > Bastien> I will like to stress that this kind of stuff is bad: > Bastien> > https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec- > Bastien> support.preinst.in#L10 > > How would you do better in that instance? > I think everyone knows it's bad, but I'm guessing that the maintainer > didn't have a better approach for detecting whether the referenced > instructions worked on the installed system. > > I'm assuming that if feature tests in /proc/cpuinfo were sufficient they > would have been used. What if the user change their CPU afterward ? This should probably be tested at boot time instead. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
roucaries> No the problem is not probing the cpu/cpuinfo... Well, if the CPU info could be probed from shell, I'd argue that's better than unpacking a binary. roucaries> The problem is the base64 encoded binary. Why is this bad. I agree that it is esthetically displeasing, but *in this instance*, why is it harmful? roucaries> I ma solving this by pre-depends on a binary package and roucaries> run the binary from the preinstalled package. I would have been less caustic in my reply than Adam, but made the same point. Having multiple packages is more complex, especially in a situation where the binary in question is only used by the preinst. It may be there are concerns I'm not seeing that make the current arrangement worse than taht. But let's actually articulate them.
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
On Wed, Aug 17, 2022 at 08:09:09AM +, roucaries bastien wrote: > Le mar. 16 août 2022 à 13:22, Sam Hartman a écrit : > > > "Bastien" == Bastien Roucariès writes: > > Bastien> I will like to stress that this kind of stuff is bad: > > Bastien> > > https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec-support.preinst.in#L10 > > > > How would you do better in that instance? > > I think everyone knows it's bad, but I'm guessing that the maintainer > > didn't have a better approach for detecting whether the referenced > > instructions worked on the installed system. > The problem is the base64 encoded binary. > > I ma solving this by pre-depends on a binary package and run the > binary from the preinstalled package. So you think having 10 binary packages instead of 5, all of them shipping just a single file, and a Pre-Depends between them, is preferable to unpacking a temporary file? The choice was obvious to me. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
Le mar. 16 août 2022 à 13:22, Sam Hartman a écrit : > > > "Bastien" == Bastien Roucariès writes: > Bastien> I will like to stress that this kind of stuff is bad: > Bastien> > https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec- > Bastien> support.preinst.in#L10 > > How would you do better in that instance? > I think everyone knows it's bad, but I'm guessing that the maintainer > didn't have a better approach for detecting whether the referenced > instructions worked on the installed system. > > I'm assuming that if feature tests in /proc/cpuinfo were sufficient they > would have been used. No the problem is not probing the cpu/cpuinfo... The problem is the base64 encoded binary. I ma solving this by pre-depends on a binary package and run the binary from the preinstalled package. > > --Sam
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
> "Bastien" == Bastien Roucariès writes: Bastien> I will like to stress that this kind of stuff is bad: Bastien> https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec- Bastien> support.preinst.in#L10 How would you do better in that instance? I think everyone knows it's bad, but I'm guessing that the maintainer didn't have a better approach for detecting whether the referenced instructions worked on the installed system. I'm assuming that if feature tests in /proc/cpuinfo were sufficient they would have been used. --Sam
Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff
Package: debian-policy Version: 4.6.1.0 Severity: important Dear Maintainer, I will like to stress that this kind of stuff is bad: https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec- support.preinst.in#L10 base64 encoded binary in maint script and mktemp on /usr/lib I have no idea about documentating why it is bad. But for the sake of history we must learn of mistake, and document it Bastien -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 4.5.0-4 Versions of packages debian-policy suggests: pn doc-base -- no debconf information
