Re: Fwd: ubuntu-default-settings and effects on flavors or remixes
On Thu, September 6, 2012 10:42 am, Scott Lavender wrote: -- Forwarded message -- From: Jeremy Bicha jbi...@ubuntu.com Date: Thu, Sep 6, 2012 at 9:09 AM Subject: ubuntu-default-settings and effects on flavors or remixes To: ubuntu-rele...@lists.ubuntu.com I wanted to make sure the other flavors were aware of this, since settings will be reverting back to the GNOME defaults unless overriden. For instance, Ubuntu Studio uses Totem so they may wish to copy Ubuntu's active-plugins (ie. default enabled plugins) setting or customize it for their needs. They'll probably want the gnome-settings-daemon overrides too. Since Edubuntu is a superset of ubuntu-desktop, they won't be affected. Scott, I have added ubuntu-default-settings to our seeds for now to keep us status quo. Please add: going through and adding these things to ubuntustudio-default-settings as blue print item for next cycle. This may give us a way to add Ubuntu Studio as a book mark to firefox as an example. It is too late to do this now this cycle as it is an all or nothing change. Perhaps branching to work on would be ok. Len -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
State of Sugar packages in Ubuntu
Hello everybody, a couple of merge proposals for various packages of various versions of the Sugar toolkit were submitted and it looked like many of the packages had been removed from Debian for a while. After some discussion on #ubuntu-motu it became clear that for some reason they had not been removed from Ubuntu yet and these series were abandoned Upstream as well. Would it be possible to remove these packages? Packages I found in the sponsoring queue were: sugar-0.84, sugar-0.88, sugar-base-0.86, sugar-datastore-0.86, sugar-toolkit-0.86 but I assume there are more. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote on 06/09/12 22:02: On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas wrote: ... Scott Kitterman wrote on 06/09/12 14:22: ... To pick just one example, rolling delivery of applications and offering multiple versions of the same package (which is what the BSD Unixes do, although not in a way I've personally found at all satisfying as a user) implies huge changes in package management. Not the least of which is the ability to support downgrades, including migrating per user settings back to previous versions. Windows, OS X, iOS, and Android all let an author issue a new or updated application within a week or so of wanting to, which I guess is what you mean by rolling delivery. This whole discussion is predicated on that being a requirement for a mass-market OS. On iOS and Android there's rather more extreme sandboxing than is being proposed here that make potential interactions between applications less of an issue. The term DLL hell was invented for Windows. I don't think it's at all obvious that replicating the existing systems is a path to success. DLL hell or no, Windows and (lesserly) Mac OS were both popular for decades before they both introduced sandboxing this year. But let's leave aside the definition of success. What kind of sandboxing, specifically, do you think would be necessary for hundreds of thousands of Ubuntu applications not to interfere with each other? It seems to me there are four possible points of contention: 1. package names (versus the OS archive, and versus each other) 2. installed files 3. saved documents and settings 4. resource use (memory, CPU, network, peripherals) while running. All four might have benefits, but for this particular goal I think it's sufficient to have technical measures for #1 and #2. Do you at least agree on that? There is an assumption here that there's a vast user base that awaits if only it weren't so hard to run the latest versions of things. That's a misunderstanding. There are, indeed, users who get annoyed when they can't play a game like Hedgewars online because the packaged version of the game is too old for the server. (Raises hand.) But the main motivation is that one of the things we need for a vast user base is an order of magnitude more and better applications. And one of the things we need to attract those application developers is the ability for them to issue new and updated applications at will. It's not sufficient, but it is necessary. ... None of those OSes offer application downgrades (though individual applications might). None of them migrate user settings to previous versions. (The file “iTunes Library” cannot be read because it was created by a newer version of iTunes. Would you like to download iTunes now?) And absent that settings problem, OS X is the only one that makes multiple application versions moderately easy (portable apps on Windows being the exception rather than the rule). That tells me that while they might be desirable, none of those three things is a requirement for a mass-market OS. It is also quite normal for things to get screwed up on other operating systems and people do a full reinstall to fix it. One of the fundamental design principles behind package management in Debian and by extension Ubuntu is that once installed, systems can just be upgraded. Reinstalls should not be needed. I think this is an important feature that should not be lightly abandoned. I think the implication of that is you've got to find a way to support downgrades. It is not an implication of that, because Debian and Ubuntu have never allowed downgrades. Upgradeability may be a design principle behind package management in Debian and Ubuntu, but downgradeability is not. Lack of rollback in general is a big problem: woe betide you if your battery runs out during an update. But again, that doesn't mean that problem is best solved together with the app developer upload problem. If you think it should be, now is the time to explain why. I think it's feasible, perhaps using something like etckeeper, but it would take work. Allowing areas where we beat the proprietary competition in quality/ capability to degrade to their level is not a recipe for success. Beat them how? Windows Installer allows rollback to a known-good state. dpkg does not. ... The current ARB process and this new proposal are focused on a specific class of applications that make use of some specific restricted features of the operating system. The current proposal is geared towards that. If the real goal though, is to deliver all applications this way, I think this proposal is not very useful because I don't think it's extensible in the ways it would need to be to grow into that. ... What else would it need? Be specific. - -- mpt -BEGIN PGP SIGNATURE-
Re: State of Sugar packages in Ubuntu
On Fri, Sep 7, 2012 at 12:35 PM, Daniel Holbach daniel.holb...@ubuntu.com wrote: Would it be possible to remove these packages? Packages I found in the sponsoring queue were: sugar-0.84, sugar-0.88, sugar-base-0.86, sugar-datastore-0.86, sugar-toolkit-0.86 but I assume there are more. This proposal sounds reasonable. Last I chatted with Luke F, the development platform had migrated to Fedora. Best, -Dan -- 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 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: Proposing a New App Developer Upload Process
On Friday, September 07, 2012 11:01:55 AM Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote on 06/09/12 22:02: On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas wrote: ... Scott Kitterman wrote on 06/09/12 14:22: ... To pick just one example, rolling delivery of applications and offering multiple versions of the same package (which is what the BSD Unixes do, although not in a way I've personally found at all satisfying as a user) implies huge changes in package management. Not the least of which is the ability to support downgrades, including migrating per user settings back to previous versions. Windows, OS X, iOS, and Android all let an author issue a new or updated application within a week or so of wanting to, which I guess is what you mean by rolling delivery. This whole discussion is predicated on that being a requirement for a mass-market OS. On iOS and Android there's rather more extreme sandboxing than is being proposed here that make potential interactions between applications less of an issue. The term DLL hell was invented for Windows. I don't think it's at all obvious that replicating the existing systems is a path to success. DLL hell or no, Windows and (lesserly) Mac OS were both popular for decades before they both introduced sandboxing this year. But let's leave aside the definition of success. What kind of sandboxing, specifically, do you think would be necessary for hundreds of thousands of Ubuntu applications not to interfere with each other? It seems to me there are four possible points of contention: 1. package names (versus the OS archive, and versus each other) 2. installed files 3. saved documents and settings 4. resource use (memory, CPU, network, peripherals) while running. All four might have benefits, but for this particular goal I think it's sufficient to have technical measures for #1 and #2. Do you at least agree on that? For this particular goal, #1 and #2 are essential. Some elements of #3 and #4 are important as well to meet the security goals associated with the proposal, which is a critical element of reducing review/allowing third parties more direct control, so I agree we have to have #1 and #2. It may even be sufficient to start with #1 and #2 designed and work out the details on #3 and #4 as the project matures. There is an assumption here that there's a vast user base that awaits if only it weren't so hard to run the latest versions of things. That's a misunderstanding. There are, indeed, users who get annoyed when they can't play a game like Hedgewars online because the packaged version of the game is too old for the server. (Raises hand.) We have mechanisms in place already to fix this problem, but that's a separate issue. But the main motivation is that one of the things we need for a vast user base is an order of magnitude more and better applications. And one of the things we need to attract those application developers is the ability for them to issue new and updated applications at will. It's not sufficient, but it is necessary. OK. I guess that's the crux of the argument. We need better/more applications (personally, I think better is far more important than more, but I guess that's a detail) and you believe more users will attract the developers to achieve that. I suspect that helps more with more than better, but who knows. For commercial vendors, I can definitely see the more users == more software, but for FOSS developers is there a significant body of developers for whom Ubuntu isn't already big enough to be important? ... None of those OSes offer application downgrades (though individual applications might). None of them migrate user settings to previous versions. (The file “iTunes Library” cannot be read because it was created by a newer version of iTunes. Would you like to download iTunes now?) And absent that settings problem, OS X is the only one that makes multiple application versions moderately easy (portable apps on Windows being the exception rather than the rule). That tells me that while they might be desirable, none of those three things is a requirement for a mass-market OS. It is also quite normal for things to get screwed up on other operating systems and people do a full reinstall to fix it. One of the fundamental design principles behind package management in Debian and by extension Ubuntu is that once installed, systems can just be upgraded. Reinstalls should not be needed. I think this is an important feature that should not be lightly abandoned. I think the implication of that is you've got to find a way to support downgrades. It is not an implication of that, because Debian and Ubuntu have never allowed downgrades. Upgradeability may be a design principle behind package management in Debian
Re: Proposing a New App Developer Upload Process
On Fri, Sep 07, 2012, Matthew Paul Thomas wrote: What kind of sandboxing, specifically, do you think would be necessary for hundreds of thousands of Ubuntu applications not to interfere with each other? It seems to me there are four possible points of contention: 1. package names (versus the OS archive, and versus each other) 2. installed files 3. saved documents and settings 4. resource use (memory, CPU, network, peripherals) while running. Sandboxing might also involve enforcing the app / system interface; e.g. not expose any other shared library than the ones application can rely on being always there for a particular version of the interface. e.g. can an application rely on libgtk-x11-2.0.so.0 to be there or should it bundle it? If we encourage apps to be self-contained, we are lowering the overall security experience of the system by expecting all application developers to update a lot of embedded libraries; if we make them rely on system libraries, we're stuck with deps on them forever. Another constraints for sandboxing is integration between apps and integration of apps with the system. There are various levels at which we expect apps will integrate with the system such as notification area icon, a background service, gadgets, but integration between apps is also important and isn't very developed in Android / iOs. Sure, there are some Share buttons or Open with intents in iOS and Android and even Nautilus has a Send to..., but I feel this is a very limited level of integration. Will we allow detecting the presence of another app? How do I embed this or that image viewer or music player into this or that cloud file sharing app? Also, we want application sandboxing but are we going to allow replacing system services in apps? Would we allow an app to act as an interactive desktop background? Are sandboxed apps always fullscreen like on Android and iOS, or may they have resizeable windows? [ 2/ (installed files) above seems like a non-problem if we have unique app names though ] -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Al 07/09/12 15:11, En/na Scott Kitterman ha escrit: On Friday, September 07, 2012 11:01:55 AM Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote on 06/09/12 22:02: On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas wrote: ... Scott Kitterman wrote on 06/09/12 14:22: ... To pick just one example, rolling delivery of applications and offering multiple versions of the same package (which is what the BSD Unixes do, although not in a way I've personally found at all satisfying as a user) implies huge changes in package management. Not the least of which is the ability to support downgrades, including migrating per user settings back to previous versions. Windows, OS X, iOS, and Android all let an author issue a new or updated application within a week or so of wanting to, which I guess is what you mean by rolling delivery. This whole discussion is predicated on that being a requirement for a mass-market OS. On iOS and Android there's rather more extreme sandboxing than is being proposed here that make potential interactions between applications less of an issue. The term DLL hell was invented for Windows. I don't think it's at all obvious that replicating the existing systems is a path to success. DLL hell or no, Windows and (lesserly) Mac OS were both popular for decades before they both introduced sandboxing this year. But let's leave aside the definition of success. What kind of sandboxing, specifically, do you think would be necessary for hundreds of thousands of Ubuntu applications not to interfere with each other? It seems to me there are four possible points of contention: 1. package names (versus the OS archive, and versus each other) 2. installed files 3. saved documents and settings 4. resource use (memory, CPU, network, peripherals) while running. All four might have benefits, but for this particular goal I think it's sufficient to have technical measures for #1 and #2. Do you at least agree on that? For this particular goal, #1 and #2 are essential. Some elements of #3 and #4 are important as well to meet the security goals associated with the proposal, which is a critical element of reducing review/allowing third parties more direct control, so I agree we have to have #1 and #2. It may even be sufficient to start with #1 and #2 designed and work out the details on #3 and #4 as the project matures. There is an assumption here that there's a vast user base that awaits if only it weren't so hard to run the latest versions of things. That's a misunderstanding. There are, indeed, users who get annoyed when they can't play a game like Hedgewars online because the packaged version of the game is too old for the server. (Raises hand.) We have mechanisms in place already to fix this problem, but that's a separate issue. But the main motivation is that one of the things we need for a vast user base is an order of magnitude more and better applications. And one of the things we need to attract those application developers is the ability for them to issue new and updated applications at will. It's not sufficient, but it is necessary. OK. I guess that's the crux of the argument. We need better/more applications (personally, I think better is far more important than more, but I guess that's a detail) and you believe more users will attract the developers to achieve that. I suspect that helps more with more than better, but who knows. For commercial vendors, I can definitely see the more users == more software, but for FOSS developers is there a significant body of developers for whom Ubuntu isn't already big enough to be important? ... None of those OSes offer application downgrades (though individual applications might). None of them migrate user settings to previous versions. (The file “iTunes Library” cannot be read because it was created by a newer version of iTunes. Would you like to download iTunes now?) And absent that settings problem, OS X is the only one that makes multiple application versions moderately easy (portable apps on Windows being the exception rather than the rule). That tells me that while they might be desirable, none of those three things is a requirement for a mass-market OS. It is also quite normal for things to get screwed up on other operating systems and people do a full reinstall to fix it. One of the fundamental design principles behind package management in Debian and by extension Ubuntu is that once installed, systems can just be upgraded. Reinstalls should not be needed. I think this is an important feature that should not be lightly abandoned. I think the implication of that is you've got to find a way to support downgrades. It is not an implication of that, because Debian and Ubuntu have never allowed downgrades. Upgradeability may be a design principle behind package
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: Proposing a New App Developer Upload Process
On 09/07/2012 09:48 AM, Loïc Minier wrote: On Fri, Sep 07, 2012, Matthew Paul Thomas wrote: What kind of sandboxing, specifically, do you think would be necessary for hundreds of thousands of Ubuntu applications not to interfere with each other? It seems to me there are four possible points of contention: 1. package names (versus the OS archive, and versus each other) 2. installed files 3. saved documents and settings 4. resource use (memory, CPU, network, peripherals) while running. Sandboxing might also involve enforcing the app / system interface; e.g. not expose any other shared library than the ones application can rely on being always there for a particular version of the interface. e.g. can an application rely on libgtk-x11-2.0.so.0 to be there or should it bundle it? If we encourage apps to be self-contained, we are lowering the overall security experience of the system by expecting all application developers to update a lot of embedded libraries; if we make them rely on system libraries, we're stuck with deps on them forever. There is currently other work going on to define the platform that Ubuntu offers to application developers, and things like what Gtk version and it's APIs will be part of that. App developers will be encouraged to use the packages already provided in our repositories, even if they're not installed, by using Depends in their package definition. Part of the spec says that they can't depend on a maximum version, so they can't say it *has* to be version 2.0.0 ( = 2.0.0), they can only say it has to be *at* *least* version 2.0.0 ( = 2.0.0), so that we can update it with security fixes. Another constraints for sandboxing is integration between apps and integration of apps with the system. There are various levels at which we expect apps will integrate with the system such as notification area icon, a background service, gadgets, but integration between apps is also important and isn't very developed in Android / iOs. Sure, there are some Share buttons or Open with intents in iOS and Android and even Nautilus has a Send to..., but I feel this is a very limited level of integration. Will we allow detecting the presence of another app? How do I embed this or that image viewer or music player into this or that cloud file sharing app? Also, we want application sandboxing but are we going to allow replacing system services in apps? Would we allow an app to act as an interactive desktop background? Are sandboxed apps always fullscreen like on Android and iOS, or may they have resizeable windows? While this would be awesome to have, it's not part of the upload process. I'd really like to see a desktop intents framework for Linux, and I'm aware of at least a couple projects that have started on one. But that is something for a different spec. [ 2/ (installed files) above seems like a non-problem if we have unique app names though ] 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 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: Proposing a New App Developer Upload Process
Hi Loïc (2012.09.07_15:48:53_+0200) e.g. can an application rely on libgtk-x11-2.0.so.0 to be there or should it bundle it? It wouldn't make any sense to bundle anything like that. The library's ABI isn't going to change over the life of the stable release. However, (although this is the wrong thread for this, sorry) apps *are* going to need to bundle new third party libraries that aren't in Ubuntu. And then we run into the problem of the third party libraries not being authored by the app author. Even if there isn't a bundled library, there is quite likely to be bundled artwork not authored by the app author. It seems that we have to allow apps to incorporate works with copyright held by third parties, assuming it's released under an appropriate license. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: State of Sugar packages in Ubuntu
On 7 September 2012 06:23, Dan Chen seven.st...@gmail.com wrote: On Fri, Sep 7, 2012 at 12:35 PM, Daniel Holbach daniel.holb...@ubuntu.com wrote: Would it be possible to remove these packages? Packages I found in the sponsoring queue were: sugar-0.84, sugar-0.88, sugar-base-0.86, sugar-datastore-0.86, sugar-toolkit-0.86 but I assume there are more. SGTM. This proposal sounds reasonable. Last I chatted with Luke F, the development platform had migrated to Fedora. Iain Lane pinged me a while back about this packageset; I requested it when I worked for Activity Central http://activitycentral.com in 2010 and was working on bringing a number of AC developers on board working on porting Sugar from Fedora. The project was successful, insofar as Ubuntu 10.10 had a decent, mostly-working Sugar stack. Unfortunately, Mozilla was changing the way they provide support for xulrunner, so we weren't able to have a functional Browse http://activities.sugarlabs.org/en-US/sugar/addon/4024 since the webkit-based Sugar browser was very immature. Basically, Activity Central moved on, and the developers who would have been candidates for joining the Sugar packageset uploaders moved on to other projects. The Debian OLPC team http://alioth.debian.org/projects/debian-olpc/ still maintains Sugar, but under significantly reduced staffing. -- Luke Faraone;; Debian Ubuntu Developer; Sugar Labs; GMU 2014 lfaraone on irc.[freenode,oftc].net -- https://luke.wf/ohhello PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 -- 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
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
Patch Pilot 20120907
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Notes from my session today. https://code.launchpad.net/~jfi/ubuntu/quantal/psensor/fix-LP1029065/+merge/117028 - Abandoned - marked WIP to get it off the sponsorship list. https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/981803 - Already uploaded to proposed - unsub-ed sponsors https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1040274 - Lots of bugfixes to merge - uploaded https://bugs.launchpad.net/ubuntu/+source/libquantum/+bug/1047380 - Built OK - enables hardening flags so worth picking - synced. https://bugs.launchpad.net/ubuntu/+source/zgv/+bug/1047383 - Misc bugs and fixes - synced. https://bugs.launchpad.net/ubuntu/+source/kde-gtk-config/+bug/1047387 - Need a merge, not a sync - explained to reporter and unsubscribed sponsors. https://code.launchpad.net/~respawneral/ubuntu/precise/java-gnome/java-gnome-fix-1043558/+merge/123232 - MP updated - but still need a bit more work - provided feedback. https://code.launchpad.net/~xnox/ubuntu-dev-tools/gnupginterface-is-evil/+merge/122402 - Different approach agreed - marked WIP to remove from the sponsoring queue. https://bugs.launchpad.net/ubuntu/+source/blktap-dkms/+bug/1028135 - New upstream release for compat with 3.5 kernel - proposed by upstream themselves which created some confusion as the packaging was quite different. Worked with Mike on IRC to get the correct release and uploaded a new version for ubuntu. EOD - -- James Page Ubuntu Core Developer Debian Maintainer james.p...@ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCAAGBQJQSibsAAoJEL/srsug59jDfYMQAJ/TIjHModq6rKDqjTZwBoQO gvQaNCVHKnIizMqG/L+0ZgolTIJrCQOyO3QpEj2Z7p/3I7br+t5T5g73dcuTvmG+ q98EQGeT+9AY+X8PHdVMZEnVEUfRCHm2zH+FAlw+CUReKONt/4keARGecLLftG9w XrqMvXCPujD1h2iYwE7Sn9uHpbI0iSBcNrgXiB5zq1HTDH2unidImGRu3zSdSmkP WFbhMRAZQ4JLVY7NF5I8/JRxTV/ueaOSYL1PZMVSjyiwUZw+hrYa6L8+GP3wns8U S/hPw1NpqZ6XTQqDazZMqtjuRVDmDocYDo7jQxsuiebSUnFpQzYbygDAmVmEpdMJ 8TaIHCWxddOVQwqDKdFWgr7Ot8OkHStYbFSlhLhxXbGupceqLr0AKk+tsUYeeQMb KERQxYp0MIo85pNh4hLzNzAuqEc1hDQwnn4sIHgS//JaJTXLV2BljYsiTb3NjP7V WTi5RuyMQ3FGG2rAd/SJxUplR0XZgFdmSWAuEIkcYFk6dpIdA8RJCJPxSfMYhYMM AvP+gHo33l9cNcOti31mtzTSLH4N8xrANqa1AYpVz8LLNjCfgBr5T9+N24tHW7PR o5G7MvfE58/OoTroFjOtx9/huxyqEfVbnAj9rvJXhe40FFb7Tp4nwkLjCGQ/76ia LBARbxtvPUfIXj2d7aYT =ImvV -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu 12.10 No Longer Have Alternate CDs
FYI, http://news.softpedia.com/news/Canonical-Drops-Alternate-CDs-from-Ubuntu-12-10-289338.shtml https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035675.html -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
News Update: You are now unsubscribed
We have removed your email address from our list. We're sorry to see you go. Was this a mistake? Did you forward one of our emails to a friend, and they clicked the unsubscribe link not realizing they were in fact unsubscribing you from this list? If this was a mistake, you can re-subscribe at: [1]Subscribe Links: 1. http://anutc.us5.list-manage.com/subscribe?u=ea21d3862eed817ad8e5fb8d8id=ccb60e9cc9 For questions or comments, please contact us at: [2]mehboobfra...@gmail.com Links: 2. mailto:mehboobfra...@gmail.com attachment: News_Update.vcf-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
