Snappy Confinement and AppArmor

[Sergio Schvezov]

On miércoles 25 de febrero de 2015 16h'09:56 ART, Oliver Grawert wrote:
> hi,
>
> Am Mittwoch, den 25.02.2015, 12:44 -0600 schrieb Jamie Strandboge:
>> On 02/25/2015 09:52 AM, Gustavo Niemeyer wrote:
>>  ...
>
> right, this is why i wrote:
>
> "that vim package is rather moot anyway, you cant really open files
> anywhere but in $SNAPP_APP_USER_DATA_PATH due to the confinement. "
>
> ...a few mails above :) 
>
> that vim package was initially more to prove that you can re-purpose
> node-snapper to roll you a multi arch snap within less than 20min,
> which, in the end worked just fine ... I simply didn't think about
> confinement when starting this and only fell into that trap later. 
>
> My expectations are probably not so far off from other outside
> developers though and there is nothing in our documentation screaming in
> my face "don't package an editor as snap, you wont be able to open files
> anyway" ... 

DISCLAIMER: These are just my thoughts and can be totally discarded.

I know some people want to bring the whole debian/ubuntu archive over to 
snaps, but for product building, do you really need some of these tools? In 
cloud perhaps and that should be solved by comfy as Jamie mentions.

In the case of node snapper, it's excellent as I can grab the bits I need 
and move on to building what I want, which fixes the "environment setup". 
In most cases that's all you need (for building a product). golang is just 
awesome in this case as well.

Maybe the initial focus should be to repurpose products out there to do 
something neat the in snappy world (or use them directly if they are 
already aligned), but not focus so much on the packaging of it. Doing this 
is good too, as it opens conversations on the limitations and probably the 
focus.

Maybe I'm wrong and this eases the transition to desktop in the future, I 
don't know; but in the case of an editor, I'm not sure how to avoid manual 
review and blindly trust the binary at the same time.

Cheers
Sergio