Comment 8 for bug 909488

Hi,

On Wed, 07 Mar 2012, Steve Langasek wrote:
> - The precise package stores dropboxd in a central location instead of
> keeping one copy per user. This is in principle the preferred way to do
> so in the distribution, but has the side effect that users who don't
> have admin privileges are unable to ever get updates. Unless an admin
> user runs 'dropbox update' for them, or there is an upgrade of the
> package, the user will then be using an out of date and possibly
> insecure version of dropboxd.

I fail to see why it's important that users who don't have admin
privileges can't update dropbox, they also can't update any other
packages that might have security issues.

Also I modified dropbox update to request admin privileges via policy kit.

> - The precise package drops the maintainer script code to automatically
> add an apt sources entry for the dropbox upstream repository. This is
> obviously the correct thing to do for a distro package; packages in the
> distro distribution channel should not be automatically enabling third-
> party repositories, and while it's understandable that third parties
> would do this in their own .debs because it's the least-bad available
> option for ensuring software updates for the user, it does distinctly
> undermine the security model of the distribution (cf. the session at the
> UDS discussing this and related issues). Nevertheless, the result of
> not enabling this repository is that users of the distribution package
> only get updates when a distro maintainer uploads them. That leaves the
> users dependent on Ubuntu for security updates to the package as well,
> and there has been no committment in Ubuntu to *provide* those security
> updates in a timely fashion. (Indeed, it's not clear that such updates
> would comply with our policies for such.)

This part is completely irrelevant. The package only contains a nautilus
wrapper and not dropboxd which is the daemon that Dropbox would
like to have auto-updated.

When dropbox (the company) wants to push an update, it's dropboxd that
replaces itself in ~/.dropboxd/. They do not push a new version of
nautilus-dropbox in their APT repository.

I have tried to convince upstream to modify dropboxd to execute
"dropbox update" (with a prior display of an explanation) instead
but they were not ready to do this. :-(

> As a result, despite the changes to the package all being sensible
> things to do on their own, the net effect is that the user experience
> when using the distro package is worse than if they had downloaded it
> from the dropbox website. Since the reasons for this are rooted in
> fairly fundamental policies of the archive, I think this is pretty
> clearly a case where Ubuntu should blacklist the nautilus-dropbox
> package in favor of the upstream one.

What would this mean? The Ubuntu repository would not contain
nautilus-dropbox at all? Or the upstream packages would replace it?

> Do you see any reason this should not be the case?

What about users who would like to use a policy compliant package?

It seems also weird to blacklist a package that a community member
was actively maintaining.

Anyway, I have an alternative suggestion for you. One that I suggested
to upstream too (in order to try to bring closer the packages
in Debian/Ubuntu and the one that they are providing) but that they did
not pick on (without explanations IIRC).

I can add a weekly crontab that will auto-update the package. This would
be deactivated by default on Debian but I can activate it by default on
Ubuntu if you think that is the right thing to do.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/