Re: Debian Jessie - Incorrect permissions on /bin directory
On 02/03/16 12:46, Yves-Alexis Perez wrote:
> On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
>> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
>> Yves-Alexis Perez <firstname.lastname@example.org> (2016-02-03):
>>> On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
>>>> I didn't check the whole archive, but doing so might be interesting.
>>> I did a quick check on a local mirror (which might be incomplete), and
>>> three packages with errors:
>>> dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
>>> drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
>>> dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$
>>> drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
>>> dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
>>> drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
>>> Note that lintian complains a lot about them:
>>> lintian sed_4.2.2-4+b1_amd64.deb
>>> W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
>>> Binary-only - copying to XS-Binary-only"
>>> W: sed: latest-debian-changelog-entry-without-new-date
>>> E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
>>> W: sed: description-synopsis-starts-with-article
>>> W: sed: non-standard-dir-perm bin/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip
>>> W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
>>> W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
>>> W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
>>> W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
>>> (or pipe to a file/program)
>>> W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
>>> It looks like an umask problem at package build time. Right now it doesn't
>>> seem to have obvious security issues (like world writable /bin) but I'm
>>> too sure there are not other stuff hidden.
>>> I guess it'd make sense to do an archive-wide lintian run to look for that
>>> kind of mistakes, and then ask for stable binNMUs of the relevant
>> It seems to me that lintian looks at testing/unstable (at least looking
>> at https://email@example.com#sed_4.2.2-6),
>> so I'm not sure this would help for stable.
>>> What do you think?
>> I think debian-release@ needs to be in the loop, doing so.
> so as far as I can tell there was no reaction from -release (although I can
> understand noone's really sure what to do here). Is it at least possible to
> schedule binNMUs in stable for those affected packages so future installs
> don't end up with bad permissions like these?
Would it make sense to start autorejecting packages that have this tag?