Re: [Quilt-dev] setup command (was: Quilt translation update)

[Andreas Grünbacher]

Am So., 11. Feb. 2024 um 23:11 Uhr schrieb Jean Delvare <jdelvare@suse.de>:
> Hi Andreas,
>
> On Sat, 10 Feb 2024 22:24:48 +0100, Andreas Grünbacher wrote:
> > I'm all for better documentation. But the setup command is severely
> > broken right now. Executing the %prep section in the current working
> > directory is just insane. (...)
>
> Because...?

Because it may leave additional artifacts around that have nothing to
do with what the setup command is expected to do, and it may destroy
existing files. The code in the %prep section doesn't expect to be run
in a directory that already contains random stuff, and it's allowed to
do arbitrary things in that directory. Isn't that obvious enough?

> Note that you can always use option -d if you want to execute the %prep
> section in a different directory. The reason why it defaults to the
> current directory is because this is where the original (slow)
> implementation was ultimately preparing the working tree, and I wanted
> to make the transition to the new (fast) method as smooth as possible.

The original implementation only expanded the tarball(s) in the
working directory, it didn't execute random code there. That's a very
significant difference.

> I proposed this implementation 10 years ago, and nobody objected. It's
> the default for 2 years now, and nobody complained.

I didn't notice that breakage until now, especially not how bad things
actually are. But now I'm indeed complaining.

> (Actually, there was a report about "quilt setup" being unsafe:
>  https://savannah.nongnu.org/bugs/?56969
>  However my understanding is that this is caused by rpmbuild allowing
>  arbitrary commands in spec files, and not related to slow mode vs.
>  fast mode implementation details.)

Protecting against malicious code in %prep would indeed be much harder
... it would require creating an environment that contains all the
tools that %prep expects, and that can differ from package to package.
I don't think we can do that.

Thanks,
Andreas