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 <cor...@debian.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 >>> found >>> 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 >>> bin/$ >>> 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 >>> usr/share/doc/sed/changelog.Debian.gz >>> 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 >>> not >>> 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 >>> packages. >> It seems to me that lintian looks at testing/unstable (at least looking >> at https://lintian.debian.org/full/cl...@debian.org.html#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. >> > Hey, > > 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? Emilio
