A possible PND-system replacement

[ptitSeb]

On the subject of Screenshot in DBP:


I'd like to have Screenshot in the DBP themselves. I don't care about video, and they should be separates from the DBP anyway, but the screenshot must be parts of the DBP, along with Icons, documents, etc... The whole point of a DBP (and a PND) is that it is self contained. App that browse DBP (or PND, like Minimenu) shouldn't need internet access to get screenshot.


All this is of course the screenshot the packager want to package inside the app.


There can be third-party screenshot or vid of course, on a server. But as far as I'm concern, that's third-party...


But I think I have another issue: the "launch script" of the DBP.


In the PND system, each launch script is "local" to the PND.


In the DBP, I understand that the launch script of the DBP will be availlable system-wide. I predict a huge mess then, with package collisionning themself and/or with system files.

 

[EvilDragon]

I also agree, screenshots (at least one or two) should be included locally in the DBP. Anything external on a server should be optional, so you get more screens and videos if you are online, but have at least SOMETHING when you're offline.


Has anyone tried what happens if you have multiple runscripts with the same name (i.e. run.sh) and have those DBP packaged programs at the same time?


What about security? Can it override system files and inject stuff?


I wouldn't be happy if an app can override /etc/passwd and then gain root as it can use it's own password...

 

[slaeshjag]

Ok, so the deal about launch scripts is:


They are placed by the dbp system in a directory as configured in /etc/dbp/sbp_config.ini


They are not capable of overriding conf or anything like that. If a package wishes to export an executable that is already present in exec_dir, then dbpd will detect the collision, yell about it in /var/log_dbp_messages and refuse to export that exec for that package. If a collision occurs, the package that was identified the latest will probably end up launching the program/game of the package that was scanned first, or not launch at all. When packages are removed, the exported launchers are checked for a signature first to avoid removing anything that the DBP system didn't place there.


As things are configured right now during development, exported executables are placed in /usr/local/games, which has low priority in PATH and is not visible by root. For a more production environment, I personally suggest a new location dedicated to the DBP system that comes after core system utilities, and preferably after installed programs.


The reason for not having them local is for better integration with environments not using the traditional graphical style. A prime example is tiling WM:ers that use dmenu_run for launching stuff. This shortcoming of the PND system is one of few things that annoyed me enough to even get started working on dbp. Typing dbp-run <package id> <path to run script> in dmenu-run is an unacceptable solution.


On the matter of avoiding collisions, I suggest a helpful predictable name (say, name of the game) and if a collision is plausable (also available in debian repo, etc) then suffix with package name or something. There will be machanisms added later to specify packages that cause collisions, both dbp:s and deb:s.


EDIT: And, regarding screenshots:


This could be solved at repo-level. Removing or adding screenshots to the package is not a terribly complicated thing to do on the repo, so getting it right at first is not critical. On package level, it'll only be implemented as a couple screenshots inside a directory in the meta-zip. If they're there, they're there.

 

[EvilDragon]

Okay, so if I run Chromium which uses run.sh and then LibreOffice which also uses run.sh, LibreOffice will not start - which is bad.


There could be a simple solution for that:


As each package needs it's own unique ID, why not let the system create a symlink that has that ID as name in the system-wide available dire which points to the runscript?


That way, the runscript can have any name and would still work and have a useful executable name in the system-wide environment.

 

[slaeshjag]

Well, they should have sensible name to begin with. There's no reason whatsoever to name a launch script run.sh other than maintainer lazyness/ignorance.


At most I can stretch to adding a config option that will add a suffix of the exec containing the package ID, but that really should not be needed.

 

[ptitSeb]

In the PND world, there is many good reason to have always the same name for the launch script, it's not laziness, it's reusability of code. It's not the same for DBP, fine. One more things to adapt (not the biggest challenge anyway). I'll probably have to create a small dbp to be able to discuss all this better.

 

[Neelix]

I thought the idea was to make the system as transparent as possible to the end user. (EDIT: and other software that might be dependent on it.) Theoretically then the exported run script should normally match the name of the main executable in the package.   Eg   a DBP of gpsd should output a run script called  gpsd. 


-Neelix

 

[slaeshjag]

I guess I should post updates to this thread whenever I implement stuff.

As of now, I've pushed 0.6.12.1 to master, which introduces an early, crude utility for validating meta-data. It's still incomplete, but it's already doing *something*.
[doublepost=1462889635,1462884626][/doublepost]Example output:

steven@Butters:~/local/dbp$ LD_LIBRARY_PATH=build/lib build/bin/dbp-validate-extracted /tmp/dbp
ERROR: Desktop file /tmp/dbp/meta/default.desktop does not specify a type in its desktop entry
ERROR: Desktop file /tmp/dbp/meta/arne.desktop uses the icon arne2.png, which is missing
ERROR: Desktop file /tmp/dbp/meta/arne.desktop has categories, but the list isn't terminated with a ';'
ERROR: Desktop file /tmp/dbp/meta/arne.desktop uses the subcategory 'Emulator', but the category 'System' or 'Game' must preceed it
WARNING: Icon file arne3.png is present but not used
WARNING: Icon file arne.png is present but not used
NOTICE: No rootfs given, assuming meta-only package
4 errors, 2 warnings, 1 notices

 

[Shlee]

have you placed any consideration into security? such as running the applications in a jail/sandbox or even containers?

I'd love to see docker used as the containerisation platform..

https://pdos.csail.mit.edu/archive/mbox/ - Mbox is a lightweight sandboxing mechanism that any user can use without special privileges in commodity operating systems.
http://google.github.io/nsjail/ - A light-weight process isolation tool, making use of Linux namespaces and seccomp-bpf
https://firejail.wordpress.com/ - restricting the running environment of untrusted applications using Linux namespaces andseccomp-bpf

http://flatpak.org/ is obviously bloated.. but worth a read
https://github.com/flatpak/flatpak/wiki/Sandbox

Docker related:
https://containerd.tools/
https://github.com/opencontainers/runc
http://subuser.org - Run programs on linux with selectively restricted permissions
https://github.com/Kagami/kagome - collection of scripts helps to run programs in Linux in isolated environments.

 

[slaeshjag]

I personally loathe Docker and everything it stands for.

Security has not been a major design goal, other than "you shouldn't be able to haxx yourself into root". I'm not a security person, so I'm not the one to design such a system anyway, it is inteded as a successor to the PND system and its use cases. If you're paranoid and/or very concerned about security, I advise against using the DBP system. To introduce decent sandboxing, the entire system would probably have to be re-designed from a concept level, as intergration with the running OS has been a primary design goal rather than isolating it.

 

[levi]

You could run dbp's deamons inside a chrooted environment, if you wanted to keep your base env uncorrupted, or even a full VM if you wanted to.

It's perfectly possible to make a malicious dbp, just as it was a pnd I assume. The community would probably make a noise about it and it's get pulled from the repo pretty rapidly if that did happen, although we did have one example of releases tracking users (though there was never any evidence that was malicious), and I assume those are still in the repo.

 

[_jr_]

There is a thread discussing docker somewhere and I seem to remember that the consensus was that it solves a different use case.

Not really on topic but slightly related. It crossed my mind that it might be a good idea to not have the home directory (with personal data like passwords) on internal storage. Would it make sense to have a preconfigured Pyra user (other users can still be created and used normally) that on login searches for (possibly encypted) 'Profiles' on external storage to choose from and mount over the pyra user home directory; if none can be found mount a tempfs layer is used? Does something like that exist already?

 

[ible]

i'm not sure that use-case makes sense for me. if i lose my device, it'll probably be along with the external storage... and i think i'd be less likely to lose the device itself than the external storage, in the case that they are separate...

 

[Shlee]

I personally loathe Docker and everything it stands for.

:S that's strong words.... why would you hate docker?

 

[slaeshjag]

Part of it is that it's the same thinking as to deploying virtual machines tends to have behind it. Rather than dealing with dependencies and integrating things into the system, you ship a blob of more or less the entire userspace where everything has exactly the correct version of libraries for it to not fall apart. Great for lazy developers who has to target a bazillion different system configurations. But I, personally, prefer to just keep my dependencies at a minimum, meaning you won't even have that problem in the first place. For this reason, their choice of a whale for their logo is highly amusing to me.

Personal opinion and objective thinking are more or less mutually exclusive, but considering the use cases we've seen for the PND system, a system with a strong focus on security, predictability among platforms and isolation from the host system is a poor fit. For use-cases completely different than the ones we saw for the PND system, it might make a lot of sense though. I'm not personally aware of what those would be though.

 

[sm0kew0n]

Okay, be gentle....

I'm trying to build this on an armhf VM and it keeps failing at dbp-run.vala,

common/dep-dialog.vala:102.3-102.27: error: The name `always_show_image' does not exist in the context of `Gtk.Button?'
install.always_show_image = true;

Same for line 105 and 108. I've installed libgtk-3-0 and libgtk-3-dev in a half arsed attempt at solving the (my) issue but no joy and now I'm stuck. Before anyone points out that I shouldn't be allowed near a keyboard, yah I know but I've got this far so.... a little help? Pretty pls.

 

[TrashyMG]

@sm0kew0n - What are you compiling?, didn't think the DBP system had any ties to gtk.

 

[sm0kew0n]

This -

https://github.com/slaeshjag/dbp

I was thinking of trying out the .dbps on the repo.

 

[slaeshjag]

What are you building on? It's possible you're running a too old/new version of Gtk.

For now, if you just want to toy around, you can comment those lines out. Those lines are not critical.
Its

I've forgotten all vala I used to know, I couldn't make out in the documentation if those properties are directly accessable anymore, so I switched to using the setter function instead, you could try that and see if it makes a difference.

 

[TrashyMG]

Ah alright, have you tried installing the older libgtk 2 dev packages?
[doublepost=1496343023,1496342835][/doublepost]Also just to note I compiled both Opentyrian and SoRR (bennugd) with specific ARM Cortex A15 optimizations. so not entirely sure how they will work with your setup.