Most of the time this works just fine, however if Adobe have several flash updates in quick succession ( like just now mid 2011), then there might be a small lag.
/usr/sbin/update-flashplugin-nonfreemanually or put it in a regular cron.
My flash version is 10.3.181.14 and it is outdated.
The command to check in a convenient form for copy / paste is below:
strings /usr/lib/mozilla/plugins/flash-mozilla.so 2>&1 | \
grep LNX | sed -e "s,^,Flash Player version: ,"
...or an alternative version in two bulleted lines....
strings $FSO 2>&1 | grep LNX | sed -e "s,^,Flash Player version: ,"
verbose output from update-flashplugin-nonfree - version confirm:
As root run the following:
/usr/sbin/update-flashplugin-nonfree --install --verbose
In the output you should see a line that starts with Flash Player version: LNX , and tells you what version is being installed.
The output is useful for debugging, but a bit lengthy to reproduce in full in this article. If you want an example of such output, then you can find that here.
Adobe flash 10.3.181.22 - an example:
Here (above) we have a problem that we have manually detected, in that 10.3.181.14 is not the newest version available from Adobe.
( Detailed output showing a sha512 checksum failure is available here )
tar -O -zxf /var/cache/flashplugin-nonfree/install_flash_player_10_linux.tar.gz 'libflashplayer.so' | strings 2>&1 | grep LNX | sed -e "s,^,Flash Player version: ,"
...or an alternative version in three bulleted lines....
tar -O -zxf $TGZ $SO | strings 2>&1 | grep LNX | sed -e "s,^,FVer: ,"
The .tar.gz is cached on your system, I assume, to prevent the unnecessary repeated downloading of the same file.
However providing that bandwidth is not an issue, you should be removing the cached version before running...
Alternatively run the three commands to be sure of avoiding caching and having a good way of automating things for a cron job setup:
update-flashplugin-nonfree --install 2>&1 >> /var/log/update-flashplugin-nonfree.log;
The human in the chain and wisdom of bandwidth saving:
Automated update processes are often seeded and / or managed by humans.
Having a pgp check as part of the update process for flash seems reasonable, providing the plugin does not need updating too regularly.
If too many updates to flash are released, then the pgp check files are going to become tiresome to keep regenerating :|
Bandwidth saving is a noble goal, however in a process that has human management, it makes sense to be sure that the user is somehow informed of an out of date cached file.
Adobe would be less than happy if hundreds of thousands of daily crons were re-downloading the same .tar.gz daily.
Conversely having cached copies of the .tar.gz and a delay in the pgp file regeneration, might mean that many debian desktop users are blissfully unaware that their flashplugin is out of date even if they have a weekly cron running update-flashplugin-nonfree --install.
See my notes in earlier paragraph for cron suggestion and removing the cached .tar.gz file.
Notes and Further Reading:
strings is a program that finds and prints text strings, embedded in binary files such as executables.
On Debian you can find an 'after the fact' copy of what update-flashplugin-nonfree downloaded in directory /var/cache/flashplugin-nonfree/
- strings - description [ wikipedia.org ]
- Bug #629417 - No up to date sha512sum available [ bugs.debian.org ]
Having convenient Debian packaging should not lock you into a habit of expecting everything on your system, to just run automatically.
Reporting bugs is important, however running an outdated flash plugin, when a simple untar and mv can make your system secure again, is not advisable.