Bug#841525: vlc-plugin-skins2: arch-dependent file in "Multi-Arch: same" package

[Sebastian Ramacher]

On 2016-10-21 14:13:31, Jonas Smedegaard wrote:
> Quoting Sebastian Ramacher (2016-10-21 13:25:45)
> > On 2016-10-21 13:16:10, Jonas Smedegaard wrote:
> > > Quoting Jakub Wilk (2016-10-21 12:52:57)
> > > > Package: vlc-plugin-skins2
> > > > Version: 2.2.4-7
> > > > Severity: important
> > > > User: multiarch-devel at lists.alioth.debian.org
> > > > Usertags: multiarch
> > > > 
> > > > vlc-plugin-skins2 is marked as "Multi-Arch: same", but the following file is 
> > > > architecture-dependent:
> > > > 
> > > > /usr/share/vlc/skins2/default.vlt
> > > > 
> > > > An example diff between i386 and amd64 (generated by diffoscope) is attached.
> > > 
> > > The diff seems to reveal the package was not built in a pristine chroot!
> > 
> > No, it doesn't. It just reveals that it was a upload including 
> > binaries since it had to go through NEW.
> > 
> > The offending code is in share/Makefile.am which creates default.vlt.
> 
> Right. Bug is not that content varies (it was created in a shared 
> makefile, and diff attached to original bugreport also shows identical 
> _content_).  Bug is also not that it was built in a non-pristine 
> environment - but it is a _hint_ about the underlying bug that the user 
> "sebastian" is the owner and group for the files in the diff.

No, it is not. default.vlt is a tar archive owned by root as it is supposed to
be. However, the content of default.vlt is not generated in a correct way. It
leaks the user and time information of the build.

> It is a real¹ bug that a non-bunNMU package inherits access rights from 
> the user account where it is built!

It doesn't. It does not inherit the access rights.

> It seems that every time you build the package as a non-binNMU it has a 
> security hole in that a user named "sebastian" in any target system gets 
> write access to some files intended to be writable only by root!

No. That's not the case. The bug is about content of default.vlt and nothing
else. No user get's additional write access.

> Likely the fix is to change debian/rules and/or patch upstream install 
> routines to use "install" with appropriate arguments, instead of "cp".

It has nothing to do with install or cp. It's a matter of passing the right
options to tar to sanitize default.vlt.

Cheers
-- 
Sebastian Ramacher