ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Thu, Jul 18, 2013 at 08:05:06AM -0400, Marc Deslauriers wrote:
> On 13-07-17 12:55 PM, Colin Watson wrote:
> > I like this layout a lot better: it actually makes some kind of sense to
> > me, it's easier to read, and it repeats itself less.
> 
> Except now we have to parse multiple json files and correlate the information we
> need. For example, we find myapp.json. We now need to parse manifest.json to
> figure out that myapp.json maps to the binary called "myapp", that the version
> is "0.1", that the desktop file is "myapp.desktop", etc. It seems to me this is
> overly complicated.

Maybe it just moves the complexity around; I assure you the complexity
is at least as bad with the previous option, it's just not in your code.
:-)

Not all the things you say here are true though; you should get the
application name and version from the name of the symlink created by
"click hook", as I discussed with Steve, not from the manifest.
Furthermore, it is not clear to me why the AppArmor hook needs to know
about the desktop file.

> We also need a global security section somewhere, so we're going to need a
> security section in manifest.json anyway.

Sure, as long as it's not part of a hook mechanism.  What will this
section contain?

> > Furthermore, this
> > way, click's hook execution can be almost entirely general: in this
> > case, it would create symlinks in /some/apparmor/cache/directory/ named
> > com.ubuntu.developer.username.myapp_myapp_0.1.json and
> > com.ubuntu.developer.username.myapp_myapp-camera_0.1.json, each of which
> > contains just the profile declaration for a single application, and
> > something like click-apparmor can walk that directory for changes and
> > generate and load profiles.
> 
> I don't understand this part. What exactly is creating the symlinks?

"click hook".  See the Click hooks spec.

> Is this just for tracking which profiles have been generated already?

This is how you know which profiles are supposed to exist and where the
apps in question are unpacked.  Otherwise we have to distribute
knowledge of where apps live across various components, which is unwise
given that we know of at least one way in which it's going to need to
change.

> > The one remaining non-generic thing here is as follows: my understanding
> > is that for 13.10 the server is not going to have any facilities for
> > scanning apps for problems and rejecting them.  This means that, IMO, we
> > need to reject such things at the client end.  But that at least is a
> > relatively small amount of code.
> 
> We need to have a checklist which we manually go through when the app gets
> uploaded. At some point, this will be automated.

Sure, but I thought we were all agreed that the more that was enforced
and the less we needed to check, the better.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]