Re: Bug#827487: bytes-circle_2.2-1_amd64.changes REJECTED
Hi Sean,
>I think that we should avoid thinking that one purpose of source-only
>uploads is to deal with DDs and DMs intentionally subverting security by
>means of dodgy binaries. We already place a great deal of trust in
>those who can upload packages, and it doesn't make sense to say that,
>despite this trust, we need to block uploading binary .debs in case the
>DD/DM decides to intentionally upload something dodgy.
you proposed a good case, but sometimes security is subverted not by purpose.
e.g. I see almost everyday DDs uploading on Jessie-bpo binaries built on top
of Stretch (just look at the bpo mail list).
People uploading on sid from a wheezy or jessie environment (this is trivial
to fix, just a binNMU)
look for binNMU with "rebuild in a clean environment" message
Other people builds not in a clean environment, this means other packages might be installed, so
the package might build with some more "features" enabled, because detected during configure
this will likely cause a mismatch of the functionalities between architectures.
And much more, e.g. the developer might have a non-up-to-date environment, where some libraries are not
kept up-to-date (security-wise), so it might introduce vulnerabilities just because he didn't dist-upgrade
before (and running sid doesn't make dist-upgrade a good thing to do).
Allowing source only uploads will move the build in a common environment, regardless
of the Developer and its machine
(how many times I saw backtraces with gdb pointing to /home/foo/build/program/fakeroot/source.c" or similar.)
the only way to exclude that might be to require binary uploads (for new), but rebuild them anyway on buildds
(just discard them as mentors does).
Gianfranco, who really likes the ppa/Ubuntu way of rebuilding stuff.
Reply to: