Re: Bug#405997: should executables be permitted to update themselves?
> Ian Jackson wrote:
>> I don't know what azareus's UI for this is like but depending on the
>> situation it might be best to make a configuration option, set by
>> default, which suppresses it. For example, if the current
>> code presents dialogues nagging to be allowed to update from upstream,
>> then we should definitely disable that by default. OTOH if it's an
>> obscure menu option then just adding `(not recommended!)' in an
>> appropriate string might be sufficient.
Jamin Collins wrote:
> I just tested an absolutely default install of Azureus from the current
> package in testing (2.5.0.0+0-1). Without changing any configuration
> settings from the prompted defaults, I'm presented with a dialog to
> download a newer version of both the "Core Azureus Version" and
> "azupdater/Azureus Update Support" automatically. There is no
> indication that doing so will deviate from the provided Debian
> packaging. Nor, did I as a user select to have the application go out
> and check for updates.
> Allowing the application to download the update resulted in no
> indication that it would be updating in my home directory instead of the
> system-wide location.
> After relaunching for the update the following error (not present prior
> to the update appeared):
> Error
> SWT library loaded from "/usr/share/java" can't be automatically updated
> from version 3235 to 3318 (must be loaded from
> "/home/jcollins/.azureus"). Please see the wiki for details.
> So, no only does the application default to checking for and suggesting
> updates, allowing it to do so appears to result in some form of
> dependency problem with the SWT library.
i think that this is proof that what azureus is doing is a very bad thing.
their updater circumvents debian's normal quality assurance checks and
balances, and leads to errors, warnings, and breakages as well as
potential security holes.
Manoj wrote:
> If azereus is going out and adding things to the users home
> dir without the users knowledge, that would be one thing. But in this
> case the users has initiated the action -- and trying to save the
> user from themselves is not only a lost cause, it is wrong headed:
> we do not remove the -rf options from rm; and nor should we dumb down
> application so users may not do dangerous things if they so desire.
the user did not initiate the action. azureus went out and checked for
updates, then told the user that they should update. and it does this every
time the application starts up unless the user chooses to update (at that
point, i don't think it is choice because the user can either say "yes" and
get rid of the annoyance or continue to be annoyed). i understand that we
should not attempt to limit anyone's freedom of choice, and we are not. we
are preserving the security, quality, and maintainability of the packages as
distributed and supported by debian. it is still possible for the user to
choose to download the upstream jar, and run with "java azureus.jar" if they
so choose. they also have an alternative choice to use the newer azureus
from sid via apt-pinning. i am not suggesting we prevent either of those
options.
Manoj wrote:
> Why doe4s that not apply to iceweasel and gcc?
iceweasel does the same to prevent updates to the debian package from upstream,
but the user always has the option to download the prebuilt firefox binaries.
this is the same thing. as for gcc, there is no auto updater, and there should
not be because a lot would break should gcc be updated without considering the
effect on dependent packages. if you are aluding to the idea that we would
for some reason want to prevent the user from using gcc to compile things to
prevent them from shooting themselves in the foot, i don't believe anyone
would agree with that, and its not close the same thing as the azureus issue.
lets get this bug fixed. should it be considered Release Critical? i
wouldn't want to see this package behave like this in the released version of
etch.
mike
Reply to: