FeatureSpecification: apt-third-party

Tristan Wibberley maihem at maihem.org
Fri Apr 7 23:31:29 BST 2006


We need to define a trust web mechanism to reduce the number of entities
involved in any given installation down to, preferably, one - where
there could be three to start with (page containing url, stanza-file,
repository). That way the user gets told "you need to trust *this*
person before installing".

I'll probably repeat myself a bit in my answers below, sorry in advance.

Jerry Haltom wrote:
>> The user should never install software that they don't trust, but the
>> user will trust anything unless they can justify exactly *why* they
>> shouldn't be trusting it. That means you have to provide a reasonably
>> effective means of differentiating between something the user can trust
>> and something the user can't. That means letting the user know exactly
>> who he needs to trust to be able to trust the software and its
>> installation. Otherwise you may as well not pop up the warning dialogue
>> because the user will just click "Install Anyway".
> 
> We have no way to verify what the user should or should not trust,
> again, as the entire point of the specification is to trust new people
> which are unknown.

I don't know which email you just read, but it coudln't have been the
one you just quoted. The user needs to decide whether the software can
be trusted, but the user needs information that they can use. If you can
narrow it down to "the repository admin for *this* repository is the one
and only person you need to trust before installing the software", then
the user will be able make a decision. Otherwise the user will just
install anything at all. And that is a security nightmare.

> Any third party the user goes to is untrusted simply
> because it is a third party.

No it isn't, the BBC is a third party, but I would trust any software it
put up for download, I wouldn't, however, trust any arbitrary software
they linked to off-site. Most users can't determine this, and webmasters
need to be able to keep things on different domains even though they
control them all, so the useragent should have a method to examine the
metadata about the four data sources (repository, stanza file,
url-to-stanza-file, url-containing-url-to-stanza-file) and present to
the user a list of who they need to trust before pressing "Install".

For arbitrary third party repository support, a method must be provided
for the user to work out whether a given installation set can be
trusted. As the proposal stands, it would be difficult for even an
experienced user to make a reliable decision.

> It doesn't matter if it installs from an
> Ubuntu repository, or a new repository, the user either accepts the
> installation, with the understanding that the installation can do harm,
> or rejects it. When he accepts it he is giving the .apt file permission
> to modify his system as root.

The user should never be expected to accept that the installation might
do harm. It is nearly always wrong for the user to install software
where he has no way of working out whether it is likely to do harm or
not. But the reputation of the supplier (repository admin) *can* be used
by the user to make a reasonable decision, so my proposals are intended
to ensure that the user can know that the trustworthyness of the
installation set is defined by the repo admin. Thus the user can work
out whether he can trust the installation set.

> Any other method, such as maintaining a list of trusted repositories,
> defeats the entire goal of the specification, and makes the
> specification more similar to the existing third-party-packages
> specification, where Ubuntu maintains a centralized list of software.

I have not proposed that even *once* so I don't know why you are even
using it to debate my idea. I strongly suspect you didn't read my email
very carefully.

> The best we can do is provide the user with the best information we can.

And my proposals are intended to do exactly that. So what is it about
them that makes you think they don't do that?

> Having the possibility of having a third party's public key signed by
> Ubuntu is a possibility, but is parallel to the existing proposal: which
> is that you shouldn't be required to gain Ubuntu's blessing to have
> users install your software.

I don't think that is robust. That requires Ubuntu to decide whether the
third party repository admin will remain responsible for an extended
period into the future, and that is impossible too.


> The obvious warning that users will just click "install" anyways is
> valid. They might. They might also download a .bin file from the same
> third party and run it without us providing the .apt file. The reason
> a .apt file is desired vs a .bin files is so that we have a place to
> explain to the user what they are about to do... it is so Ubuntu can
> step into the middle and give a speech to the user over what is
> currently a dangerous process: installing untrusted third party
> software.

Speeches don't work. You have to make it obvious what the user needs to
decide on. I think my two proposals do that in a scalable decentralised
way. Reducing the users decision to "do I trust this repository" or "do
I trust the webpage that contained the link".

Either way, Ubuntu does not need to be involved in the trust web at all.

In that space we can do a lot of things. We can have the
> Install button only enable itself after 15 seconds UNLESS the key is
> signed by Ubuntu, stuff like that. If nothing else it at least does our
> users a service by making the process consistent. It doesn't make it any
> safer than it already is.

But if it is really easy to get stuff, and appears to be
end-user-friendly, the user will think it is normal to install software
without any way to determine whether they can trust the installation
set. As it is, it is an obscure and mysterious process and at least they
understand that it is not like cleaning the car where there are no
concequences.



-- 
Tristan Wibberley




More information about the sounder mailing list