A Debian bug report [1] noted some insecurities in how Tucan handles plugins (quoting from the report):

Tucan comes with "plugins" to handle downloads from the various
download sites it supports. These plugins are basically python modules
which run with the same permissions as the user running tucan. The
tucan package comes with a set of such plugins in
/usr/share/default_plugins/, but it downloads updates of these plugins
via http/https and places them in ~/.tucan/plugins/. This means that
after an update, debian-packaged code is effectively replaced by code
directly from the upstream repository. This in itself is problematic,
but because the update mechanism is implemented in an insecure
fashion, a remote attacker could use it introduce a malicious plugin
which executes arbitrary code with the permissions of the user running
tucan.

The plugins tucan downloads are unsigned, so a remote attacker could
introduce a plugin containing malicious code either by compromising
the remote sites where the plugins are stored, or by means of a
man-in-the-middle attack on the http/https connection from tucan to
the site holding the updates (tucan doesn't seem to check the server
certificate on SSL connections). Tools for automating this kind of
exploit exist, e.g. https://code.google.com/p/ippon-mitm/

The best way to address this problem is probably to disable the update
mechanism entirely in the debian package, and distribute updated
plugin files via apt. (Upstream might want to look into signing their updates,
and possibly making changes to the program's design so that the plugins
run in some kind of sandbox rather than with full user permissions.)



I agree with the reporter; this kind of update mechanism is susceptible to MITM, and because these plugins are python scripts, almost anything could be done when they are unwittingly executed by the user.  We may want to look into disabling this insecure update mechanism ourselves.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656388