Re: AppDevUploadProcess Automatic reviews
On Thursday, September 06, 2012 05:43:41 PM Michael Hall wrote: On 09/06/2012 05:07 PM, Scott Kitterman wrote: On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K No, the uploader must claim either ownership of the copyright or approval from those who do to distribute it via Ubuntu. After that it is their responsibility to convey licensing information to their users. It is not rare for free software projects to copy code from other projects and reuse it if it has a compatible license (and sometimes when it doesn't). Does this mean that projects that reuse code from other projects aren't eligible for this process? Checking for proper documentation of licenses and copyright (even if it's all one project/person) is the most labor intensive part of the New package review process that Ubuntu archive administrators do. It's also the part that's critical from a legal perspective because it's how we know that it is legal for Ubuntu (really Canonical and the Ubuntu mirror partners) to distribute. If someone checks a box and claims ownership, that doesn't mean they really have it nor does it mean that all the code is legally distributable, so I'm not sure what you mean when you say it's their responsibility. It's still Canonical doing the distribution. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
On 09/07/2012 07:55 AM, Scott Kitterman wrote: On Thursday, September 06, 2012 05:43:41 PM Michael Hall wrote: On 09/06/2012 05:07 PM, Scott Kitterman wrote: On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K No, the uploader must claim either ownership of the copyright or approval from those who do to distribute it via Ubuntu. After that it is their responsibility to convey licensing information to their users. It is not rare for free software projects to copy code from other projects and reuse it if it has a compatible license (and sometimes when it doesn't). Does this mean that projects that reuse code from other projects aren't eligible for this process? Projects with code reuse will be allowed. The requirement is that they be the original author or a proper representative of the upstream project. Since the only form of quality control we will have is the Ratings Reviews, we don't want a project's reputation to be harmed by an unaffiliated person uploading packages for it to USC. Checking for proper documentation of licenses and copyright (even if it's all one project/person) is the most labor intensive part of the New package review process that Ubuntu archive administrators do. It's also the part that's critical from a legal perspective because it's how we know that it is legal for Ubuntu (really Canonical and the Ubuntu mirror partners) to distribute. Because these apps will be in Extras, it will only be Canonical distributing them (as far as I know, Extras isn't being mirrored). The final wording of the agreement will be decided by Canonical's legal team, but I'm confident that one can be made that will protect both Canonical and Ubuntu in the event somebody mis-uses code or misrepresents themselves during this process. If someone checks a box and claims ownership, that doesn't mean they really have it nor does it mean that all the code is legally distributable, so I'm not sure what you mean when you say it's their responsibility. It's still Canonical doing the distribution. Scott K Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
Al 07/09/12 13:55, En/na Scott Kitterman ha escrit: On Thursday, September 06, 2012 05:43:41 PM Michael Hall wrote: On 09/06/2012 05:07 PM, Scott Kitterman wrote: On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K No, the uploader must claim either ownership of the copyright or approval from those who do to distribute it via Ubuntu. After that it is their responsibility to convey licensing information to their users. It is not rare for free software projects to copy code from other projects and reuse it if it has a compatible license (and sometimes when it doesn't). Does this mean that projects that reuse code from other projects aren't eligible for this process? Checking for proper documentation of licenses and copyright (even if it's all one project/person) is the most labor intensive part of the New package review process that Ubuntu archive administrators do. It's also the part that's critical from a legal perspective because it's how we know that it is legal for Ubuntu (really Canonical and the Ubuntu mirror partners) to distribute. If someone checks a box and claims ownership, that doesn't mean they really have it nor does it mean that all the code is legally distributable, so I'm not sure what you mean when you say it's their responsibility. It's still Canonical doing the distribution. Upon creation of an account in MyApps, the app developer needs to agree to the terms of service [1] (something that already happens today): The developer will also be required to agree to terms and conditions that will clearly outline what content is acceptable and unacceptable, and that the software can be removed if questionable, illegal, or infringing content is found. Once approved the developer will be provided with upload access for that specific application to extras. https://wiki.ubuntu.com/AppDevUploadProcess#How_App_Devs_Upload_Their_Apps I am not a legal or copyright expert, so I cannot give an authoritative answer, but we do have an Ask the legal team to check if the terms of service need any changes as a result of the new process work item covered in the spec. Cheers, David. [1] https://myapps.developer.ubuntu.com/dev/tos/ signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
On Friday, September 07, 2012 03:55:54 PM David Planella wrote: Al 07/09/12 13:55, En/na Scott Kitterman ha escrit: On Thursday, September 06, 2012 05:43:41 PM Michael Hall wrote: On 09/06/2012 05:07 PM, Scott Kitterman wrote: On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K No, the uploader must claim either ownership of the copyright or approval from those who do to distribute it via Ubuntu. After that it is their responsibility to convey licensing information to their users. It is not rare for free software projects to copy code from other projects and reuse it if it has a compatible license (and sometimes when it doesn't). Does this mean that projects that reuse code from other projects aren't eligible for this process? Checking for proper documentation of licenses and copyright (even if it's all one project/person) is the most labor intensive part of the New package review process that Ubuntu archive administrators do. It's also the part that's critical from a legal perspective because it's how we know that it is legal for Ubuntu (really Canonical and the Ubuntu mirror partners) to distribute. If someone checks a box and claims ownership, that doesn't mean they really have it nor does it mean that all the code is legally distributable, so I'm not sure what you mean when you say it's their responsibility. It's still Canonical doing the distribution. Upon creation of an account in MyApps, the app developer needs to agree to the terms of service [1] (something that already happens today): The developer will also be required to agree to terms and conditions that will clearly outline what content is acceptable and unacceptable, and that the software can be removed if questionable, illegal, or infringing content is found. Once approved the developer will be provided with upload access for that specific application to extras. https://wiki.ubuntu.com/AppDevUploadProcess#How_App_Devs_Upload_Their_Apps I am not a legal or copyright expert, so I cannot give an authoritative answer, but we do have an Ask the legal team to check if the terms of service need any changes as a result of the new process work item covered in the spec. Cheers, David. [1] https://myapps.developer.ubuntu.com/dev/tos/ The current goal for the Ubuntu archive is to prevent distribution of content which Canonical and the mirror providers don't have legal authorization to distribute. Changing from a proactive verification model (which is what we use now, although it relies generally on self assertions in the code so it's imperfect) to a reactive model where code is considered distributable based on a third party assertion until someone complains seems like a very substantial change. Even in the case where we
Re: AppDevUploadProcess Automatic reviews
Scott, am Fri, Sep 07, 2012 at 10:07:28AM -0400 hast du folgendes geschrieben: The current goal for the Ubuntu archive is to prevent distribution of content which Canonical and the mirror providers don't have legal authorization to distribute. Changing from a proactive verification model (which is what we use now, although it relies generally on self assertions in the code so it's imperfect) to a reactive model where code is considered distributable based on a third party assertion until someone complains seems like a very substantial change. I think that's also because we ask people to mirror stuff that Debian (and by extension Ubuntu) does proactive checks. IANAL either, but this seems risky to me. At the very least, I'd suggest engaging them early to make sure they are comfortable with the concept of not checking (new work item) and you'll need to figure out how you'll deal with take down requests (another new work item). If it turns out applications have been distributed illegally, do you intend a way to remotely remove them? I don't think there is any requirement to remotely remove such content (except if it's malicious, maybe). On the contrary I think people would be yelling at you, especially if they paid for the content (c.f. Amazon). For Android you mainly risk your sign-up fee given that with every upload you state that you have the necessary rights. If the distribution point ceases to distribute the 3rd party content when he's made aware of a violation that seems to be fair. However that wouldn't work go along well with mirroring this repository. Kind regards Philipp Kern signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
On Friday, September 07, 2012 05:35:44 PM Philipp Kern wrote: Scott, am Fri, Sep 07, 2012 at 10:07:28AM -0400 hast du folgendes geschrieben: The current goal for the Ubuntu archive is to prevent distribution of content which Canonical and the mirror providers don't have legal authorization to distribute. Changing from a proactive verification model (which is what we use now, although it relies generally on self assertions in the code so it's imperfect) to a reactive model where code is considered distributable based on a third party assertion until someone complains seems like a very substantial change. I think that's also because we ask people to mirror stuff that Debian (and by extension Ubuntu) does proactive checks. I think that's part, but not all of it. Simply ceasing to distributing works that are not legally distributable, except in very specific circumstances (safe harbor) isn't enough to get an entity off the legal hook entirely. IANAL either, but this seems risky to me. At the very least, I'd suggest engaging them early to make sure they are comfortable with the concept of not checking (new work item) and you'll need to figure out how you'll deal with take down requests (another new work item). If it turns out applications have been distributed illegally, do you intend a way to remotely remove them? I don't think there is any requirement to remotely remove such content (except if it's malicious, maybe). On the contrary I think people would be yelling at you, especially if they paid for the content (c.f. Amazon). For Android you mainly risk your sign-up fee given that with every upload you state that you have the necessary rights. If the distribution point ceases to distribute the 3rd party content when he's made aware of a violation that seems to be fair. However that wouldn't work go along well with mirroring this repository. I agree it's not necessary and I wasn't trying to imply it was. I also agree that there would be, at a minimum a lot of yelling. I asked because it's one way to deal with parts of the problem, not that it's inherently necessary. It may be sufficient (IANAL, still), but I think the potential legal questions involved go well beyond checking if the ToS need to be updated and the spec should reflect that work. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
AppDevUploadProcess Automatic reviews
Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. -- Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: AppDevUploadProcess Automatic reviews
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
Re: AppDevUploadProcess Automatic reviews
On 09/06/2012 05:07 PM, Scott Kitterman wrote: On Thursday, September 06, 2012 04:00:25 PM Michael Hall wrote: Most of the conversation on the previous thread has been about package isolation, but I wanted to make sure the other topics in the spec were also being discussed. One of our primary goals was to eliminate every bottleneck we could. To that end we detailed a series of restrictions, sandboxing and automated checks that would allow us to trust that these application could not do any accidental harm to the user or the user's system. Human intervention has always become a bottleneck, as man-hours are one resource we can't scale up as the need arises, so removing that from the process has been a key driver for this spec. Besides package isolation, the other important method for protecting our users is with the mandatory use of an AppArmor profile. We, together with the security team, have identified what additional work needs to be done to provide a trustworthy sandbox for applications, and ways of informing the user about what access they those applications will need. Furthermore the AppArmor profile itself will be generated on our servers (MyApps) based on the developer's input, and incorporated into their package automatically. This assures us that the profile is both correctly made and correctly installed, without the developer having to learn how to do it. 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. 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. Those parts of the spec seemed reasonable to me. You'll have a hard time automating review of copyright/licensing information though. Is there a plan for that? Scott K No, the uploader must claim either ownership of the copyright or approval from those who do to distribute it via Ubuntu. After that it is their responsibility to convey licensing information to their users. Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
