Patch Pilot 20120907

[James Page]

-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

Re: AppDevUploadProcess Automatic reviews

[Scott Kitterman]

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

Re: AppDevUploadProcess Automatic reviews

[Philipp Kern]

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: State of Sugar packages in Ubuntu

[Luke Faraone]

On 7 September 2012 06:23, Dan Chen  wrote:

> On Fri, Sep 7, 2012 at 12:35 PM, Daniel Holbach
>  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  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  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  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: Proposing a New App Developer Upload Process

[Stefano Rivera]

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: AppDevUploadProcess Automatic reviews

[Scott Kitterman]

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 ver

Re: Proposing a New App Developer Upload Process

[Michael Hall]

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

[David Planella]

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

[Michael Hall]

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: Proposing a New App Developer Upload Process

[David Planella]

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 sho

Re: Proposing a New App Developer Upload Process

[Loïc Minier]

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

[Scott Kitterman]

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.
> 
> 

Re: AppDevUploadProcess Automatic reviews

[Scott Kitterman]

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: State of Sugar packages in Ubuntu

[Dan Chen]

On Fri, Sep 7, 2012 at 12:35 PM, Daniel Holbach
 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: Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

-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 gro

State of Sugar packages in Ubuntu

[Daniel Holbach]

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