www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - XDG-APP and D

reply Gerald <gerald.b.nunn gmail.com> writes:
For those not familiar, xdg-app is a Linux virtualization system 
targeted at desktop apps, it's been under pretty heavy 
development and is available for use in Gnome 3.20.

Mathias Clausen recently wrote a blog entry about creating his 
first xdg-app and the application he chose to play with was 
Terminix, a terminal emulator, which is written in D. He had some 
D specific challenges to deal with which may be interesting to 
others looking to support xdg-app.

You can read his blog entry here:

https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.
Apr 21 2016
next sibling parent reply Karabuta <karabutaworld gmail.com> writes:
On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:

 For those not familiar, xdg-app is a Linux virtualization 
 system targeted at desktop apps, it's been under pretty heavy 
 development and is available for use in Gnome 3.20.

 Mathias Clausen recently wrote a blog entry about creating his 
 first xdg-app and the application he chose to play with was 
 Terminix, a terminal emulator, which is written in D. He had 
 some D specific challenges to deal with which may be 
 interesting to others looking to support xdg-app.

 You can read his blog entry here:

 https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.



This whole sandbox apps seem interesting. Canonical also talking 
about snaps :)
Apr 21 2016
parent reply Dicebot <public dicebot.lv> writes:
On 04/21/2016 11:30 PM, Karabuta wrote:

 This whole sandbox apps seem interesting. Canonical also talking about
 snaps :)


Meh, I can see why this concept is tempting for desktop systems but it
makes me feel that 5 years from now I'll have to build my own
Linux-From-Scratch distro to preserve kind of user experience I
initially loved Linux for (minimal overhead, running same system on both
your tiny media server and power desktop). "A runtime can be thought of
as a /usr filesystem with fixed contents. When a bundled app gets run,
the runtime it needs gets mounted at /usr." :(
Apr 22 2016
parent Anonymouse <asdf asdf.com> writes:
On Friday, 22 April 2016 at 10:24:08 UTC, Dicebot wrote:

 On 04/21/2016 11:30 PM, Karabuta wrote:

 This whole sandbox apps seem interesting. Canonical also 
 talking about snaps :)


 Meh, I can see why this concept is tempting for desktop systems 
 but it makes me feel that 5 years from now I'll have to build 
 my own Linux-From-Scratch distro to preserve kind of user 
 experience I initially loved Linux for (minimal overhead, 
 running same system on both your tiny media server and power 
 desktop). "A runtime can be thought of as a /usr filesystem 
 with fixed contents. When a bundled app gets run, the runtime 
 it needs gets mounted at /usr." :(


I don't know at what point dynamic libraries came to be 
considered harmful, but it certainly seems to be the case now. 
And even if they are dynamic inside the container, every program 
shipping an individual copy of the libs means they might as well 
be statically compiled into it.
Apr 22 2016
prev sibling next sibling parent FreeSlave <freeslave93 gmail.com> writes:
On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:

 For those not familiar, xdg-app is a Linux virtualization 
 system targeted at desktop apps, it's been under pretty heavy 
 development and is available for use in Gnome 3.20.

 Mathias Clausen recently wrote a blog entry about creating his 
 first xdg-app and the application he chose to play with was 
 Terminix, a terminal emulator, which is written in D. He had 
 some D specific challenges to deal with which may be 
 interesting to others looking to support xdg-app.

 You can read his blog entry here:

 https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.


How did he get build that weighs less than megabyte? When 
building with dub -b release and after stripping binary terminix 
still weighs 9 MB on my debian. And it's just a single binary, 
without resources and dynamic dependencies.
Apr 22 2016
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:

 For those not familiar, xdg-app is a Linux virtualization 
 system targeted at desktop apps, it's been under pretty heavy 
 development and is available for use in Gnome 3.20.

 Mathias Clausen recently wrote a blog entry about creating his 
 first xdg-app and the application he chose to play with was 
 Terminix, a terminal emulator, which is written in D. He had 
 some D specific challenges to deal with which may be 
 interesting to others looking to support xdg-app.

 You can read his blog entry here:

 https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.


Can someone explain to me how xdg-app provides a significantly 
different experience to static linking (in a language like C or 
D)? I guess there's the old "what about libc?".
Apr 22 2016
parent reply Dicebot <public dicebot.lv> writes:
On 04/22/2016 02:57 PM, John Colvin wrote:

 On Thursday, 21 April 2016 at 18:55:23 UTC, Gerald wrote:

 For those not familiar, xdg-app is a Linux virtualization system
 targeted at desktop apps, it's been under pretty heavy development and
 is available for use in Gnome 3.20.

 Mathias Clausen recently wrote a blog entry about creating his first
 xdg-app and the application he chose to play with was Terminix, a
 terminal emulator, which is written in D. He had some D specific
 challenges to deal with which may be interesting to others looking to
 support xdg-app.

 You can read his blog entry here:

 https://blogs.gnome.org/mclasen/2016/04/15/my-first-xdg-app.


 
 Can someone explain to me how xdg-app provides a significantly different
 experience to static linking (in a language like C or D)? I guess
 there's the old "what about libc?".


https://wiki.gnome.org/Projects/SandboxedApps explains it pretty well.
Think of it as immutable filesystem snapshot that gets used for
sandboxed app instead of real host filesystem. Not only all dependency
code is included but all file resources too,:

"A runtime provides a well-defined environment that an app can run in.
Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of
as a /usr filesystem with fixed contents. When a bundled app gets run,
the runtime it needs gets mounted at /usr." (c) that link

It also includes facilities for limiting sandboxes app access to host:

"The xdg-app run command sets up an isolated environment before
exec()ing the application. Among other things, it

- mounts the files/ directory of the application under /app (readonly)
- mounts the files/ directory of the runtime under /usr (readonly)
- mounts the data/ directory of the application under /var (writable)
- if access to the host filesystem is required, it gets mounted at /
(writable)
- if access to the home directory is required, it gets mounted at its
usual place (writable)
- if access to neither the home directory or the host filesystem is
required, /var/home gets mounted in its place (writable)
- if the runtime has extension points, and matching runtimes are
installed, mount them (readonly)"

So in the end each app will bundle all its dependency and just work no
matter what the host is. Which is cool. But it will also bundle all its
dependencies and you'd better accept size of your total system
installation (and its RAM consumption).
Apr 22 2016
parent Gerald <gerald.b.nunn gmail.com> writes:
On Friday, 22 April 2016 at 12:07:36 UTC, Dicebot wrote:

 So in the end each app will bundle all its dependency and just 
 work no matter what the host is. Which is cool. But it will 
 also bundle all its dependencies and you'd better accept size 
 of your total system installation (and its RAM consumption).


I don't think it is quite as bad as it seems though, I believe 
the runtimes are shared and thus do not count as dependencies so 
it's not like each application is shipping the complete gnome 
runtime for example. Hopefully as additional runtimes get created 
the dependency issue will lessen.
Apr 22 2016
prev sibling parent reply NX <nightmarex1337 hotmail.com> writes:
I will just leave it here:

http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/
Apr 23 2016
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 23 April 2016 at 11:29:29 UTC, NX wrote:

 I will just leave it here:

 http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/


This is FUD.

There are no security risks with snappy packages that there 
aren't with any other existing Linux packaging systems.

Snappy actually improves things in various ways compared to most 
packaging formats, while not addressing the longstanding and 
universal issues with X11 that affect just about all Linux 
distros.

The solution of those issues lies either in setting up X11 to 
appropriately isolate applications (which AIUI is possible but 
not very nice to do), or using an alternative display server that 
addresses those security concerns (Mir or Wayland).

Ubuntu and Canonical have been completely up-front about the 
limitations of snappy's security guarantees when used on an X11 
system (well before Matthew Garrett wrote his article), so it's 
difficult to see these stories as anything other than a malicious 
attempt to undermine a competitor.
Apr 23 2016
parent reply Anonymouse <asdf asdf.com> writes:
On Saturday, 23 April 2016 at 13:56:45 UTC, Joseph Rushton 
Wakeling wrote:

 On Saturday, 23 April 2016 at 11:29:29 UTC, NX wrote:

 I will just leave it here:

 http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/


 This is FUD.

 There are no security risks with snappy packages that there 
 aren't with any other existing Linux packaging systems.


But that's more or less what he's saying though, if you read his 
original blog post. His gripe isn't that it's defect 
security-wise, but rather that it's being marketed as capital-s 
Safe. As long as programs run under the X protocol, everything is 
up for grabs. Snappy doesn't change that fact at all, so widely 
claiming it makes it impossible to steal data would be 
cherry-picking Mir behaviour.


"Snaps are intended to make it easier to distribute applications 
for Ubuntu - they include their dependencies rather than relying 
on the archive, they can be updated on a schedule that's separate 
from the distribution itself and they're confined by a strong 
security policy that makes it impossible for an app to steal your 
data.

At least, that's what Canonical assert. It's true in a sense - if 
you're using Snap packages on Mir (ie, Ubuntu mobile) then 
there's a genuine improvement in security. But if you're using 
X11 (ie, Ubuntu desktop) it's horribly, awfully misleading. Any 
Snap package you install is completely capable of copying all 
your private data to wherever it wants with very little 
difficulty.

The problem here is the X11 windowing system. X has no real 
concept of different levels of application trust. Any application 
can register to receive keystrokes from any other application. 
Any application can inject fake key events into the input stream. 
An application that is otherwise confined by strong security 
policies can simply type into another window. An application that 
has no access to any of your private data can wait until your 
session is idle, open an unconfined terminal and then use curl to 
send your data to a remote site. As long as Ubuntu desktop still 
uses X11, the Snap format provides you with very little 
meaningful security. Mir and Wayland both fix this, which is why 
Wayland is a prerequisite for the sandboxed xdg-app design."


Sandboxing is good but I'm not convinced shipping duplicates of 
libraries with each program is. Packages were meant to solve this 
and they do, though .so version conflicts is a thing (albeit a 
rare one).
Apr 23 2016
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 23 April 2016 at 15:13:15 UTC, Anonymouse wrote:

 But that's more or less what he's saying though, if you read 
 his original blog post. His gripe isn't that it's defect 
 security-wise, but rather that it's being marketed as capital-s 
 Safe.


Except that his original blogpost is just saying something that 
has already been made perfectly clear in Ubuntu's technical 
outreach, and announcing it as if it's a new discovery of an 
issue that wasn't already known.

See e.g. https://youtu.be/lHO8j8uo5Z4?t=1127


 As long as programs run under the X protocol, everything is up 
 for grabs. Snappy doesn't change that fact at all, so widely 
 claiming it makes it impossible to steal data would be 
 cherry-picking Mir behaviour.


Not entirely, because snap packages will have to specify that 
they wish to access X, and that opens up various scenarios both 
for package review and for the user to decide if that is 
acceptable for them -- again, see the video posted, a short while 
later: https://youtu.be/lHO8j8uo5Z4?t=1202


 At least, that's what Canonical assert. It's true in a sense - 
 if you're using Snap packages on Mir (ie, Ubuntu mobile) then 
 there's a genuine improvement in security.


... which is probably the widest use-case for snap packages ...


 But if you're using X11 (ie, Ubuntu desktop) it's horribly,
 awfully misleading. Any Snap package you install is
 completely capable of copying all your private data to
 wherever it wants with very little difficulty.


It's only "misleading" if (i) you discount the 
already-publicly-stated caveats about the limitations of snappy 
packages on an X11-based desktop and (ii) you discount the fact 
that snappy-packed apps must _request_ access to the X server and 
that precautions are being taken for how this is handled.

On the other hand, I feel it's distinctly misleading for someone 
to write a blog post saying, "Hey, I found a security flaw!" 
without mentioning either that the people responsible for the 
software have already publicly stated as much, _or_ the steps 
that they are taking to mitigate that.

When it comes from an author who already has previous form for 
attempting to whip up public drama around Ubuntu's projects, 
usually distorting the truth in the process, you'll forgive me if 
I don't feel some level of cynicism about his motives.
Apr 23 2016
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 23 April 2016 at 15:13:15 UTC, Anonymouse wrote:

 But that's more or less what he's saying though, if you read 
 his original blog post.


Just to add further: while I have a lot of doubts about the 
motives behind the original blogpost (which I feel misleads by 
omission on several counts), remember that my original response 
was to someone posting an article whose title was "Ubuntu 16.04's 
new snap format is a security risk".

That's outright FUD and it deserves to be challenged strongly.
Apr 23 2016