On 27/11/2015 12:16, Gervase Markham wrote:
On 26/11/15 17:13, Mike Hoye wrote:
Stillman wrote some new code and put it through a process meant to catch
problems in old code, and it passed. That's unfortunate, but does it
really surprise anyone that security is an evolving process? That it
might be be full of hard tradeoffs? There is a _huge_gap_ between "new
code can defeat old security measures" and "therefore all the old
security measures are useless".
But the thing is, members of our security group are now piling into the
bug pointing out that trying to find malicious JS code by static code
review is literally _impossible_ (and perhaps hinting that they'd have
said so much earlier if someone had asked them).
That's not what they're saying. They're saying it is impossible to
guarantee with static analysis that code is not malicious. Nobody
disputes that, and nobody did before they started saying it, either. The
distinction is that the static code review finds *some* malicious JS
code. Dan's charge is that this is not useful because malware authors
will realize this (we tell them that their add-on got rejected and why!)
and try to bypass that review until they manage it.
This entire discussion is pretty orthogonal to the fact that we're
signing add-ons and the issues that Till and Thomas were talking about
anyway (which was basically: now add-ons need to be reviewed to be
signed and that review takes a long time, and that disrupts users and
add-on developers).
And not only that, but attempting it seems
to be causing significant collateral damage.
This is the interesting bit. The reason Dan is bringing this up is not
his concern for users' safety but the fact that the same automated
scanning is flagging things in his add-on that he claims aren't "real"
issues, this causes him to land in the "manual review" queue, and that
takes time.
To my mind, the logical conclusion of Dan's post is that he should want
all add-ons to be manually reviewed all the time. He claims that if
static analysis does not guarantee benign code, it is not worth having
it at all (something which I would dispute (see distinction drawn
above), but let's stick with it for now).
The reason we're drawing different conclusions is that I believe we
still want to do something about the issues caused by frontloaded
add-ons not distributed through AMO, and so we will need to do some kind
of review, and if we get rid of the static analysis, the logical thing
to do would be to use manual review.
Of course, having to manually review all the add-ons is going to cause
even more delays, and is therefore not in Dan's interest, so instead he
posits that we should just drop all our attempts to control issues
caused by frontloaded add-ons not distributed through AMO.
The interesting thing is that Dan is nominally talking about how we're
trying to moderate quality and safety in a space where we haven't before
(ie add-ons not distributed through AMO), but then says stuff like "And
it’s just depressing that the entire Mozilla developer community spent
the last year debating extension signing and having every single
counterargument be dismissed only to end up with a system that is
utterly incapable of actually combating malware."
which basically boils down to an ad-hominem on Mozilla and an indictment
of "the system" and signing and the add-ons space generally, when
really, all we're talking about right now is how/whether to review
non-AMO-distributed add-ons before signing them. Dan acknowledges
elsewhere in his post that signing has other benefits, but the polemic
tone sure makes it seem like the entire plan we have here is rubbish
from start to finish.
There's been a general trend there that Dan sees our attempts to try to
do something in that space as a one-way street where Mozilla should
basically make sure that all add-ons that used to work and weren't
distributed through AMO should not be disrupted, and we have been saying
that it's hard to improve user experience here if there are 0
restrictions, and so "something's gotta give". Dan wants a system where
he can (grudgingly) submit his add-on to AMO, and AMO gives it back to
him signed (ideally automatically via APIs) and nobody from Mozilla
(human or otherwise) reviews his code or tells him how to do stuff. And
we're trying to improve the state of non-AMO add-ons. Those two desires
are fundamentally very hard to reconcile. And that has very little to do
with whether or not static analysis can guarantee you non-malicious code
or not.
~ Gijs
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
