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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel