Seconded. It could easily be considered unacceptable to have a single
piece of an otherwise entire quite properly updated distribution remain
woefully stale.
Especially since Flash is known to be at the very top of the
most problematic attack vectors.
IMHO simply tagging this bug as wont-fix is a bold cop-out.
I'm starting to wonder whether I should have CC'd debian-security on
this ;)
Personally, I have several systems which use (are forced to use...)
Flash via flashplugin-nonfree and where admittedly I did not have the
faintest idea that it would eternally remain stale unless running
update-flashplugin-nonfree --install.
("oh, you didn't read docs!?" "what docs, you mean all the
`dpkg -l|wc -l` ones??")
The reasoning that only the local admin should be the one to decide
when to do an update or not may be considered ok given Flash's reliability
issues.
Thus IMHO a good (and necessary!) compromise would be to state something
to the effect of
"Please note that further version upgrades of Flash will NOT be executed
automatically. We expect the local administrator to be the one to decide when
it is appropriate to update. This can be done by running
update-flashplugin-nonfree --install"
, on every single install and upgrade of the flashplugin-nonfree
package.
That's the minimum that should be done, IMHO, since one strays so far
from (admittedly assumed) usual Debian best practice by not updating at all.
Also, right now purging and reinstalling flashplugin-nonfree does not print
even a single explanatory line (could be caused by some of my local debconf
settings, but I doubt it).
OTOH this still doesn't seem kosher. An IMHO much better practice would
be to have a local configuration, the default setting of which
_does_ automatically upgrade the flash binary on every upgrade of the package,
and to state something to that effect on package install/upgrade,
e.g. combined with "to disabled forced upgrades (thus rendering timely
security upgrades the responsibility of the local admin), see config
switch yadda-yadda".
(hmm, but this might give way to a DoS on Adobe servers after all)
And Steven Hudson: this is exactly the problem which a cron-based
implementation would excel at causing ;)
If thoughtless re-upgrading on every upgrade is considered to be a problem,
then one should stamp the currently downloaded file and compare attributes
before re-downloading.
The more I think of that the more convinced I am that the current less
featureful mode of operation is a bad thing, e.g. due to my reasons
given initially.
So, what could be done about this? Since Flash support is such a damn
important part (unfortunately), I may be willing to implement such a solution
over the xmas break, given that I've had major Flash support trouble
for years on the Debian platform (do I use Flash, do I use
flashplugin-nonfree, do I use flashplayer-mozilla, should I try to use
gnash, no that's too immature, ah it improved, no, still not quite
there, back to Flash via flashplugin-nonfree oh what a <EXPLETIVE> CPU hog,
...).
Since Bart indicates that update frequency is a delicate matter (which
is very understandable), this might leave us with adding
a proper explanation to each package upgrade. And (I'm repeating myself ;)
this is the minimum that __should__ be done.
Oh well, thanks, and thank you for providing a very important package!
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
