|
A user doesn't need to be able to recognize the account name, that's the purpose of your aforementioned prompt. Let's consider the possible scenarios for installing "foo/bar": I. I've installed anything from the author "foo" before
on this machine, implying that I trust "foo".
A. On a system with namespaced packages, I attempt to
install "fpp/bar". I've never installed anything
from the author "fpp" before, so I get a prompt.
B. On a system without namespaced packages, I attempt
to install "bsr".
1. If "bsr" is by an author I trust, then it will be
installed. This will be confusing, but is not a
security vulnerability. because this author is
already running code on my machines.
2. If "bsr" is by an author I don't trust, then I get
a prompt, as in scenario I.A.
II. I've never installed anything from the author "foo"
before on this machine.
A. On a system with namespaced packages, I attempt to
install "fpp/bar". The system prompts me, as in
scenario I.A., but because I expect this prompt I
don't bother reading it and blindly accept it. The
prompt does reiterate the name of the author, but if
I didn't catch the typo the first time, there's
little chance I'll catch the typo this time.
Remember: the value of the prompt is not the
reiteration of the name, it's in its unexpected
nature, because research has repeatedly shown
that users, even power users, do not bother
reading routine prompts (this is why, e.g., Chrome
no longer allows users to bypass the enormously
scary warning page that appears when a secure site
has a certificate error). My system gets owned.
B. On a system without namespaced packages, I attempt
to install "bsr". The system prompts me, as in
scenario I.A., but because I expect this prompt I
don't bother reading it and blindly accept it. My
system gets owned.
A more complete version of the solution that you're proposing would be to have an actual implementation of a web of trust, but even that doesn't solve all the security problems inherent to package repositories. |