Re: [Quilt-dev] setup command

[Jean Delvare]

On Mon, 12 Feb 2024 00:02:42 +0100, Andreas Grünbacher wrote:
> Am So., 11. Feb. 2024 um 23:11 Uhr schrieb Jean Delvare <jdelvare@suse.de>:
> > 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?

Doesn't seem to be a problem in practice, and if it is, then again you
can use option -d to work in a dedicated, initially empty directory.

The code in the %prep section can do anything the running user can do,
including modifying or deleting files outside of both the current
directory and the target directory, so you simply shouldn't run "quilt
setup" (or rpmbuild for that matter) on a spec file which you do not
trust. This is actually something we should document.

Note that even the old, slow setup method can overwrite files in the
current directory, if the unpacked archive contains files at the root
level. And it can also create, modify or delete any file in the home
directory of the user, for example, due to the insecure design of rpm
spec files.

> > 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.

Indeed, and one effect of this was that the resulting working tree
wasn't always what people expected, because the effects of some
commands run in the temporary directory were never reflected to the
working tree. This is a limitation my new implementation lifted.

> > (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.

The %prep section of spec files can contain anything. If you don't
trust a given spec file, don't run "quilt setup" on it, period. I see
no point in adding complexity and slowing things down to deal with
hypothetical situations when the whole thing is inherently unsafe in
the first place.

-- 
Jean Delvare
SUSE L3 Support