Usage of apturl in the documentation

[Dougie Richardson]

Matthew,

> I don't think that's true - I was pointing out that fooling a user
> into installing a potentially risky package is already possible, so
> it's relevant that it hasn't happened so far.

But the current system doesn’t offer the ability to obfuscate nor does it preclude the knowledge of how to work at the very least a command prompt.

> Say there is a package called "mysql-openallports" which has a known
> vulnerability. A user can be fooled into installing it in either of
> the following ways:
> 
> * To give your desktop serious bling, install the "mysql-openallports"
> package by typing "sudo apt-get install mysql-openallports".
> * To give your desktop serious bling, install the
> [[apt:mysql-openallports compiz]] package

* Type "command_i_dont_know apt-get install mysql-openallports" somewhere unspecified.

OR

* Click this familiar hyperlink.

1. For many users two the extremely unfamiliar user the command line is a bit of a no go.
2. For users comfortable enough to have used it, the word openallports doesn't sound right.

> In the second example, which is the situation that you're concerned
> about, the only difference from the first example is that the
> malicious editor can disguise the name of the package in the wiki
> page. But most beginners will equally happily follow the first
> instruction.

The prevalence of Phishing attacks is based around the obfuscation of hyperlinks and we should not underestimate laziness.
 
> > If you are saying that it's a minor concern and the benefits outweigh
> any concern then that's a different position. However at the moment
> you're accusing me of paranoia
> 
> The word paranoia in my email wasn't intended to be directed at you.
> I'd intended simply to make the point that we should be careful about
> building up risks which are small or unlikely (from the spec - "the
> security implications are small"), or which are already present.

Well, really I'm making two points - this could be abused but from controlled sources such as the system docs and h.u.c. then that’s fine but from the ever expanding un-monitored community documentation this is a risk.

IMHO this is not a small risk from the point of view of the community docs which have been abused in the past. God help us if it was in the forums - there were plenty of people affected by the sudo rm -fR /* stuff last year.

> Why? The Ubuntu development team has a specific security team who
> looks at these issues, and as a team is stock full of Linux technical
> experts. The documentation team (by its very nature) simply doesn't:
> it has writers. That's not a disservice at all, it's just a fact.

Why - because it promotes the notion that there is a hierarchy and that certain contributions are more valuable than others. As much as I appreciate their work, it didn't stop the security issue with ssh keys earlier this year - that is the sort of thing that can be picked up when it comes to documentation - I know from development projects I've worked on that I often cannot see the wood for the trees.

> That's not to say that there is no one in the team with that type of
> technical knowledge, I'm sure there is, but we can't (and shouldn't)
> have the same resources as the development team.

What resources are you talking about? If this issue has been discussed then why does the spec not include a rational for discounting the possible vulnerability?

> > that doesn't preclude me from voicing an opinion
> 
> Of course not! That's why I was keen for Vadim to start this thread in
> the first place.

It doesn't feel like a discussion at this point.

Regards,

Dougie Richardson