AppDevUploadProcess Automatic reviews

[Emmet Hikory]

Michael Hall wrote:
> The only part of the spec that still uses a human review is in verifying
> the identity of the user (though some process yet to be determined).
> This is important because, as I mentioned above, the other parts of the
> spec are only intended to prevent accidental harm, not intentionally
> malicious code. We believe that verifying the identity of the uploader,
> so that it is not an anonymous relationship between the uploader and
> Ubuntu, should prevent intentional abuse on their part.

    For Ubuntu Developers, the current identity check consists only of
ensuring there is a specific cryptgraphic secret associated with a given
launchpad account, and ensuring that all uploads are checked in a way that
requires access to this cryptographic secret, although we request that
participants provide a believable pseudonym for use in maintaining the
system.  Are the identity verification mechanisms being mooted for this
new process more stringent than that?  If so how and why?

    Separately, unless we intend to impose a requirement for physical
inspection of state-sponsored identity documentation in the presence
of the individual whose identity is being verified, trust our identity
reviewers to be familiar with these forms of documentation, and trust
the applicants to be submitting true documents, why does this step
require human review?  What are the hard problems involved that would
require human intelligence to resolve and cannot be automated?

    The specification appears to only require unsigned text submitted
to MyApps, and I suspect that one could write a program that generated
such text based on information available on an arbitrary project page.
While such a submission might be later disavowed by the individual whose
credentials had been borrowed for the purpose of submission, I am
unconvinced that the documented non-interactive process is sufficient as
a turing test, and would find it unfortunate if we expended human effort
without some assurance that our counterparties were also so required to
expend human effort.

> If there is a
> case of intentional abuse, we would be able to remove that app and
> prevent the submitter from using the system again.

    In the event of apparently intentional abuse, I'm unsure that the
appropriate resolution is to prevent the submitter from using the system
again: I'd prefer to see a limited cool-down period: for example 1 year,
during which we ask that the person refrain from use of the system, and
fail to accept their packages.  Further, I would suggest that whatever
terms of service are constructed indicate that the creation of new
apparent identities during this time are subject to being added to the
set of users whose packages will never be accepted.  There ought be a
well-defined appeal process, both for acceptance blocks and for the
associated removal of the software demonstrating the apparently
intentional abuse.

    I'm also curious if there has been discussion of apparently
unintentional abuse (ranging from excessively slow response to security
issues through unacknowledged and obfuscated mechanisms to provide those
with the appropriate knowledge access to run arbitrary code in the process
space of the application (perhaps tightly linked to some hard-coded data
source to avoid accidental detection)).  To take one example, I'm not sure
that we could differentiate, even with expert human code inspection, between
the various intents that might generate an easily exploitable buffer
overflow, nor accurately protect ourselves against subsequent social
engineering efforts.  We should have some means to remove such offending
code, or better, to patch it once the potential for problematic behaviour
has been identified (essentially forcing the software in question to be
collaboratively maintained, if perhaps only for potential security issues),
even in the case where there is a clear and persuasive argument that there
was no malicious intent on the part of the application developer (who, for
example, is willing to provide an overwhelmingly large volume of evidence
that they had nothing to do with that particular botnet).

-- 
Emmet HIKORY