Skip to content
Snippets Groups Projects
New look: Off

Evaluating privilege separation for postmarketOS and Alpine apps

    • Closed Imported Issue created by Administrator @root

    Hey all, I've had a busy week and then unexpectedly also a busy weekend. So I wasn't able to do the backlog there as planned. Sorry for that, I'll go through it as soon as I find time. Here is an issue that I prepared all week, I'd like to at least share that with you. Cheers! :slight_smile:

    The next immediate goals are basing on Alpine stable (#11 (closed)), getting at least the Pinephone fully supported (#3 (closed)), categorizing devices better (#13 (closed)). But another important topic, that we should tackle after that (or even in parallel if somebody not involved with the above three tasks finds time), is "proper support" for apps:

    • touch friendly GUI applications
    • easy to install
    • privilege separation (only has access to what it needs, i.e. a PDF reader only needs read access to everything except for configs and should not need network access)

    An "app store" for postmarketOS should not list programs that would not be accepted in postmarketOS or Alpine. Especially:

    • proprietary apps
    • apps that track users
    • apps that display advertisements

    Nowadays we have some apps, but they are not easy to install yet (only with apk on the command-line), and they don't have privilege separation.

    I have put Alpine in the title, because after careful evaluation I would like to arrive at a solution that we could reasonably propose to Alpine, and after approval, submit patches to upstream it to Alpine.

    Flatpak

    Honestly I had already discarded flatpak earlier (postmarketos.org#94). But this week I've seriously considered it again. After all, flatpak is already in Alpine and we have a nice gui with Discover.

    The official repository, flathub, has all sorts of proprietary applications like skype. We can't use that, so we would need to roll our own git repository for flatpak manifests (the recipies like APKBUILDs) and host our own flatpak repository. For all "SDKs" and for all apps, so we make sure that we build everything from source.

    I don't think this is good for postmarketOS, because it would immensely increase the maintenance effort. Let's illustrate this with evince APKBUILD and flatpak manifest. Note that each app only depends on a "SDK" (org.gnome.Sdk in this case), all other dependencies are built from source and shipped with the app.

    • essentially we get a second pmaports repository that works entirely different
    • existing tooling (pmbootstrap, CI) can't be used
    • increased RAM usage, since libraries are loaded multiple times when using apps, the version from Alpine/pmOS apk and at least one flatpak version
    • updating a library suddenly means touching the flatpak manifests of all apps using that library, which is much more effort. Deploying security fixes for libraries would be a nightmare.

    My recommendation is, that we make it easy to use flatpak for people who really want to (https://gitlab.com/postmarketOS/pmaports/-/issues/491) but do not recommend or support it. Then people can use flathub or purism's upcoming flatpak repository (hopefully only of free software mobile friendly applications?) if they like and we avoid the maintenance burden.

    Minimalist alternative: privsep subpackage

    I propse that we create privsep subpackages for each app package, that we care about. Have it install a privsep.sh in /usr/privsep/bin/$pkgname, if the package was installed and privsep-base is installed in the system:

    subpackages="... $pkgname-privsep"
source="... privsep.sh"
# ...
privsep() {
	install_if="$pkgname privsep-base"
	install -Dm755 "$srcdir"/privsep.sh "$subpkgdir"/usr/privsep/bin/$pkgname
}

    The privsep.sh would look like this (based on example):

    #!/bin/sh
exec bwrap --ro-bind /usr /usr \
	--dir /tmp \
	--dir /var \
	... \
	/usr/bin/path-to-real-application

    privsep-base would depend on bubblewrap and provide a profile script, which places /usr/privsep/bin at the beginning of $PATH. Bubblewrap is a lightweight program that flatpak is using internally for privilege separation. (We should even be able to run flatpak with some verbose parameter to make it display the bwrap command it generates.)

    In my opinion, this nicely integrates with the APKBUILDs postmarketOS and Alpine already have. The whole thing is optional. I don't care so much about locking down the applications perfectly with every seccomp rule we can apply, I would rather shoot for some basic privilege separation, like stripping internet access for all apps that don't need it. That way it should not break on updates while still having a day and night difference in security compared to how it is now. Also it should hopefully work with most downstream kernels too.

    Please note that I have not tested the above approach. Help with creating a proof of concept is welcome and this would be the next step if we decide to go with this solution.

    What about portals?

    Portals are a mechanism to make an unprivileged app ask for permissions, e.g. to let a pdf reader display a file open dialog that has access to everything owned by your user instead of only having access to what the pdf reader is allowed to read. AFAIU flatpak does this with a daemon listening for dbus requests for such portals from the bubblewrapped apps, then forwards the chosen file to the sandbox (also via dbus?) or performs whatever other action the portal is supposed to do. It should be possible that we build the same mechanism, and re-use flatpak's daemon somehow. To let GTK apps request portals for file open dialogs, one apparently only needs to set export GTK_USE_PORTAL=1 (which the privsep.sh would do in the bwrap call).

    Again, if somebody could help with building a proof of concept, it would be greatly appreciated.

    What about an "app shop" gui?

    @minlexx is already working on apk support for Discover. Besides that, we would need some way to mark some apks as "apps" and add a nice description, icon and screenshot that would then be displayed in Discover. AFAIK there is the appstream format for that exact purpose, and it is also supported in Discover.

    I image that we would have an extra repository for these appstream files, pmapps.git, and it would have one dir for each app, with the metadata. In contrary to having our own flatpak repo, this would not duplicate stuff from the pmaports repository so it should be a lot easier to maintain.

    @minlexx: does this make sense?

    What about rollbacks of app updates?

    Unlike flatpak, the privsep subpackage approach does not make it possible to roll back apps conveniently after an upgrade went wrong. Because updating an app may have updated depending libraries at the same time, and other programs may depend on the new library.

    But I argue that this is not something we should optimize for. I propose a rollback of the whole (package manager maintained) system with btrfs and snapshots. Snapper seems to be the appropriate tool, and it is packaged in Alpine. I have not tested it personally.

    Details in https://gitlab.com/postmarketOS/pmaports/-/issues/492

    What about snap?

    Well, I did not only look into flatpak, but also a bit into snap. It uses Apparmor for privilege separation, and Ubuntu Touch has their own app repository: https://open-store.io/

    Maybe there would be a chance for collaboration... I have not looked into the technical details, but I don't think we could get around all the issues I have listed for flatpak from postmarketOS perspective and result in an as minimalistic solution that could possibly be upstreamed to Alpine. Feel free to convince me otherwise, though.

    Conclusion

    So... I propose my minimalistic approach listed above. Thanks for reading, looking forward to feedback and help with proof of concepts!

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Administrator added discussion help wanted labels · Imported

      added discussion help wanted labels

      • Administrator
        Administrator @root · Imported
        Author Owner

        Here are some quick ideas:

        For end users' well being, separate apps and packages.

        apps are the user facing applications (like GIMP, gVim...) available through the 'app shop', packages are the system packages (like device-xxx, vim...) available through apk.

        Non tech people would just deal with apps, packages would be updated when OS update, through GUI. Hackers would deal with both aps and packages for CLI for example.

        What I love about flatpak is the builtin sandboxing (even for free software, to reduce vulnerabilities impact on system, Bezos would never have been pwned if iOS implemented good sandboxing), no need to add a script which increase complexity.

        Also it seems to be the solutions that all (other than Ubuntu) other distros are converging on. It is nice that the GNU/Linux world start to unify efforts. As a Linux app developer it will certainly be the only one format I will maintain.

        Regarding flathub, an idea would be to implement a blacklist or whitelist (I'm not sure how) thus proprietary apps or apps with pubs can't even be found nor installed through the 'app shop'.

        What I'm sure is that I can convince my mother (non digital native people personae) to use GNU/Linux on both Desktop and mobile, but she won't if the experience (for installing apps for example) is too much different between the 2 platforms while both are named 'Linux'.

        By Ghost User on 2020-03-09T12:54:49

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        For end users' well being, separate apps and packages.

        That's what the appstream metadata format is for. There is no need to make this distinction manually besides making sure the required metadata is installed.

        As a Linux app developer it will certainly be the only one format I will maintain.

        As an app developer, you should not bother with packaging yourself other than for Flatpak anyway. Packaging is for packagers of the distros. And even with Flatpak I personally think others have to package it for you, but I guess opinions differ there.

        I'm against a black or whitelist though. We should make sure never to enable a repository which includes proprietary applications by default, but besides that, we should not hinder the user from installing proprietary applications. It's their choice to run proprietary stuff, not ours.

        By Bart Ribbers on 2020-03-09T12:54:49

      • Administrator
        Administrator @root · Imported
        Author Owner

        Each distribution mechanism have specificities that need to be adapted in code, like permissions, app folder and so on... Adding more distribution mechanisms adds complexity and fragmentation, exactly what the Linux world does not need more.

        Letting packagers of distros package your app is the surest way to have old versions of your app installed, thus creating a user support nightmare (which distro are the more used? how many versions late of well known packages have they?). Also, the app may need to adapt to server APIs (thus the recent story about Discord).

        It's a successful recipe for disaster, from an user experience point of view AND app developers point of view.

        Regarding black/white listing, I thought about something that can be disabled by users who want.

        I do not claim to have THE solution to app packaging and distribution for mechanism, but having a common standard, relatively secure and easy to use across distros is something the Linux world is really missing. I think flatpak is this standard.

        By Ghost User on 2020-03-09T13:45:36

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        Each distribution mechanism have specificities that need to be adapted in code, like permissions, app folder and so on... Adding more distribution mechanisms adds complexity and fragmentation, exactly what the Linux world does not need more.

        It is not true that one would need to adapt permissions and "app folder" (whatever that is, I assume installation paths?) for each distribution. For example, we have plasma mobile and phosh packaged in postmarketOS, along with lots of applications from these environments. Upstream did not need to make any adjustments related to permissions or file locations, and they certainly don't have tons of switch-case statements for all the different Linux distributions out there, like your comment makes it appear to be.

        What Alpine Linux and therefore postmarketOS is doing differently than most distributions, is that we use the more strict musl libc instead of glibc. It forces programmers to write more portable code that will eventually be able to work in more environments (think of BSDs, ...), causing less fragmentation (see the examples Natanael gave at FOSDEM 2017).

        This is a deliberate decision made on Alpine's end, and as app developer you don't need to worry about it. Either write your code POSIX compliant, or if we really want to package your app, postmarketOS packagers will add patches to make it compile with musl and upstream those to your project.

        The init system is also different, but that is not something you typically need to deal with in a GUI application anyways. If it is relevant, then package managers will take care of it.

        Letting packagers of distros package your app is the surest way to have old versions of your app installed, thus creating a user support nightmare (which distro are the more used? how many versions late of well known packages have they?).

        This is generalizing. It depends on how fast the distribution in question is updating your app, and if you don't agree with the release cycle, then talk to the people from the distribution! Who said that we would update your app only once a year? If you can make proper, stable, trustworthy releases then I don't see why we in postmarketOS would not update your app as soon as the update is released.

        Another approach could be LTS versions provided by upstream, like firefox is doing it.

        Also, the app may need to adapt to server APIs (thus the recent story about Discord).

        This is a prime example why it's a bad idea to let software developers directly push their apps to some sort of app shop. They can just recommend users to circumvent the privilege separation by downloading a binary from their website and installing that. This behavior would never be accepted by package maintainers from postmarketOS or Alpine Linux and illustrates why it is important for the user, that we have a package maintainer between the software developer / "vendor" and the user: the maintainer enforces that the programs play by the distribution's rules.

        Regarding the APIs: as app developer, just communicate clearly with the package maintainers. Let the maintainers know in advance when an API will be deprecated. If it happens regularly, then clearly communicate the timeframes when all users must have moved.

        It's a successful recipe for disaster, from an user experience point of view AND app developers point of view.

        This is exaggerating, the disaster happens when app developers and/or package maintainers refuse to talk to each other and find reasonable release cycles. Which is of course not what we want, we are talking to upstream.

        I do not claim to have THE solution to app packaging and distribution for mechanism, but having a common standard, relatively secure and easy to use across distros is something the Linux world is really missing. I think flatpak is this standard.

        Then by all means, use flatpak if it works for you.

        It just doesn't mean we must adapt it as the recommended way to install applications.

        By Oliver Smith on 2020-03-14T04:11:43

      • Administrator
        Administrator @root · Imported
        Author Owner

        For example, when developing for Flatpak, we need to adapt and use XDG_DIRECTORIES (https://docs.flatpak.org/en/latest/conventions.html#xdg-base-directories) whereas when distributing as a simple, non-sanboxed, binary we can simply put config files and data in $HOME/.myapp.

        If there is nothing special for each distribution mechanism, while it took Firefox so long to adapt to flatpak?

        I believe it's a mistake to perpetrate the old way to distribute software (using distrib's repositories, with a common package manager).

        Android and IOS both have a different way to update apps and system packages.

        Deepin Linux (the Chinese new player, often acclaimed for it's smooth user experience) also have 2 package managers:

        They also have strict rules for apps maintainers to keep the apps updated: https://www.deepin.org/en/deliver-applications

        On the other hand, alpine packages are far from these standards, for example, Krita is 6 months old on edge: https://invent.kde.org/kde/krita/-/tags.

        By Ghost User on 2020-03-14T16:23:20

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        for example, Krita is 6 months old on edge

        Right, distro packaging will almost always lag behind upstream releases, but flatpak is just another packaging format, it can lag too. Have you read http://flatkill.org/ ?

        By Alexey Min on 2020-03-14T17:02:51

      • Administrator
        Administrator @root · Imported
        Author Owner

        For example, when developing for Flatpak, we need to adapt and use XDG_DIRECTORIES

        That's something any app that saves configuration to $HOME should do though, to support nonstandard setups too.

        By Rasmus Thomsen on 2020-03-14T17:07:39

      • Administrator
        Administrator @root · Imported
        Author Owner

        Have you read http://flatkill.org/ ? Sure, here is also some discussion about it: https://news.ycombinator.com/item?id=18180017

        I believe that if flatpak become the only one app distribution mechanism, users will be able to better understand it, volunteers will be able to better focus their limited time to help developers and packagers, and developers will be more pressured to produce high quality packages. This is the virtuous cycle of open source.

        Today the future seems still uncertain for flatpak, thus why developers would bother to adapt their apps and restrict the permissions?

        I sincerely believe that flatpak is our only chance, to see one day, VLC or GIMP without host filesystem permissions.

        Right, distro packaging will almost always lag behind upstream releases

        It's the worst nightmare of commercial (not proprietary) apps developers, it means increased support, increased fragmentation, and increased technical debt.

        but flatpak is just another packaging format, it can lag too

        What I'm preaching is flatpak to be the sole packaging format, thus it can be maintained by apps' developers themselves, thus it can have quicker updates.

        That's something any app that saves configuration to $HOME should do though, to support nonstandard setups too.

        Agree, but if there is no incentives, why app developers would prioritize this while they have 1000 other 'urging' tasks?

        By Ghost User on 2020-03-16T16:12:17

        Edited by Administrator
      • Please register or sign in to reply
      • Administrator
        Administrator @root · Imported
        Author Owner

        Minimalist alternative: privsep subpackage

        This seems like reinventing the wheel. Why do we not take existing solutions? Afaik AppArmor and/or SELinux can be used to accomplish exactly what we want. And doesn't AppArmor already use Portals for all this stuff?

        As for an "app store", yeah we should use Discover for KDE Plasma, and GNOME Software for Phosh (@Cogitri is working on adding support for apk there). I'm however not sure why we would store the required metadata in separate repositories. Can't we ship this with the packages instead? A subpackage with install_if="appstream" for every package that ships metadata sounds easy enough and something upstream Alpine would support. Actually, most, if not all, KDE applications already ship with the required metadata in /usr/share/metainfo/<some kind of application identifier>.xml.

        Snap I personally don't believe is worth even talking about. It's a centralized service that runs on a proprietary backend, it should not be considered at all.

        By Bart Ribbers on 2020-03-09T13:12:46

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        This seems like reinventing the wheel. Why do we not take existing solutions?

        +1 on that, reinventing the wheel here isn't going to help IMHO

        GNOME Software for Phosh (@Cogitri is working on adding support for apk there).

        Yes, I'm currently writing a polkit helper thingie for that, I hope I'll have a first working version for that soon-ish.

        By Rasmus Thomsen on 2020-03-09T12:59:26

      • Administrator
        Administrator @root · Imported
        Author Owner

        This seems like reinventing the wheel. Why do we not take existing solutions? Afaik AppArmor and/or SELinux can be used to accomplish exactly what we want. And doesn't AppArmor already use Portals for all this stuff?

        I had the idea of using such shell wrappers with bubblewarp (or firejail in earlier concepts) for several years now and just refined them with this post. The advantage would be, that it should work with pretty much all kernels, because we shouldn't need to enable anything special AFAIK.

        But now that you point it out... using AppArmor or SELinux should indeed be a much cleaner solution and it would be better than re-inventing the wheel. So let's scrap my idea and use AppArmor or SELinux instead!

        I'm however not sure why we would store the required metadata in separate repositories. Can't we ship this with the packages instead? A subpackage with install_if="appstream" for every package that ships metadata sounds easy enough and something upstream Alpine would support. Actually, most, if not all, KDE applications already ship with the required metadata in /usr/share/metainfo/<some kind of application identifier>.xml.

        Oh you're right. I had assumed, that there would be some kind of index file, like APKINDEX.tar.gz, that Discover/GNOME software would download. But it works as you described, every application puts their metadata in /usr/share/metainfo. (And I just saw that we could even use yaml files instead of xml if we wanted, yay!)

        I guess the appstream subpackages, that get auto-installed would work. Maybe we should not use install_if="appstream", but another pkgname instead, so one can choose to install appstream without automatically pulling in all these metadata subpackages.

        Snap I personally don't believe is worth even talking about. It's a centralized service that runs on a proprietary backend, it should not be considered at all.

        Didn't know that, it's a no-go then. Thanks for pointing this out!

        By Oliver Smith on 2020-03-14T03:22:32

      • Please register or sign in to reply
      • Administrator
        Administrator @root · Imported
        Author Owner

        Suggestions to move this forward (help wanted):

        • Make a case for AppArmor or SELinux
        • Create example subpackages with apparmor/selinux profiles
        • Create example subpackage for appstream metadata
        • give it some wider testing in postmarketOS
        • finally pitch this to Alpine ML and try to upstream it

        By Oliver Smith on 2020-03-14T06:35:58

        Edited by Ghost User
      • Administrator
        Administrator @root · Imported
        Author Owner

        FWIW I don't really think Alpine (nor PostmarketOS) will be able to maintain (good) SELinux rules. SELinux is very powerful but it's really a massive pain to maintain and even Fedora can barely get it to work apparently (the last times I tried I always got some popups about SELinux denying something right after installation).

        So I think AppArmor is the better way forward, since it's much easier to maintain and Apparmor rules are way simpler. The disadvantage is that Apparmor is more designed to guard specific (critical) parts of the system (e.g. internet facing apps) and not the whole system at once (like SELinux and TOMOYO), so IMO it would make sense to first add AppArmor rules (or grab them from Ubuntu) to things like Firefox, Evolution, etc.

        At least from my perspective Alpine should adopt that ASAP.

        By Rasmus Thomsen on 2024-07-11T21:12:45

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        Create example subpackage for appstream metadata

        Right now we just package it in the main package, what is the rational for splitting it into (yet another) subpackage?

        By Rasmus Thomsen on 2020-03-14T06:37:28

      • Administrator
        Administrator @root · Imported
        Author Owner

        My understanding is, that we must have the metadata installed before having the main package installed. Otherwise, we can't use discover / gnome software to find the app and display the metadata + screenshot before it is installed. Or what am I missing?

        By Oliver Smith on 2020-03-14T08:42:12

      • Administrator
        Administrator @root · Imported
        Author Owner

        My understanding is, that we must have the metadata installed before having the main package installed.

        Ah, fair, it's required for some advanced metadata, such as:

        • Screenshots
        • Content rating
        • Developer names
        • Release notes
        • Icons

        Everything else can be provided directly by apk via the polkit helper I'm writing right now - but at least icons and screenshots are very nice to have.

        By Rasmus Thomsen on 2020-03-14T08:58:34

      • Administrator
        Administrator @root · Imported
        Author Owner

        Suggestions to move this forward (help wanted):

        why did you throw away bubblewrap idea? I actually liked how simple it is. Why is it bad?

        By Alexey Min on 2020-03-15T15:02:50

      • Administrator
        Administrator @root · Imported
        Author Owner

        I want to avoid reinventing the wheel if there is already a good solution out there. Without having done much research, apparmor does seem like a good approach and we could re-use existing profiles from other distros.

        By Oliver Smith on 2020-03-21T19:18:26

      • Administrator
        Administrator @root · Imported
        Author Owner

        Sounds good. I'd love to have in Alpine too, so feel free to ping me if I can help with anything.

        By Rasmus Thomsen on 2020-03-21T19:21:13

      • Administrator
        Administrator @root · Imported
        Author Owner

        Sure, thanks! Just FYI, right now I have other tasks prioritized for myself. So it will take some time until I push this forward more.

        By Oliver Smith on 2020-03-29T13:04:04

      • Please register or sign in to reply
    • Administrator changed the description · Imported

      changed the description

      By Oliver Smith on 2020-03-14T04:53:00

    • Administrator
      Administrator @root · Imported
      Author Owner

      Also, FWIW there's now an online generator tool for generating MetaInfo (Appstream) files, which should be easier than writing the XML by hand: https://blog.tenstral.net/2020/03/introducing-the-metainfo-creator.html

      By Rasmus Thomsen on 2020-03-14T06:48:05

    • Administrator
      Administrator @root · Imported
      Author Owner

      @minlexx is already working on apk support for Discover. Besides that, we would need some way to mark some apks as "apps" and add a nice description, icon and screenshot that would then be displayed in Discover. AFAIK there is the appstream format for that exact purpose, and it is also supported in Discover.

      As far as I understand Discover relies on packager backend to provide this information. This would be cool, but right now there is no way we can get categorizing information from apk-tools itself (ideally struct apk_package would provide this info, meh, dreams).

      I imagine that we would have an extra repository for these appstream files, pmapps.git, and it would have one dir for each app, with the metadata. In contrary to having our own flatpak repo, this would not duplicate stuff from the pmaports repository so it should be a lot easier to maintain. @minlexx: does this make sense?

      I have no idea how and where appstream information should be stored. This is how Discover looks like in Kubuntu, for example, with all those categories, ratings and comments:

      image

      By Alexey Min on 2020-03-15T15:13:03

      • Administrator
        Administrator @root · Imported
        Author Owner

        As far as I understand Discover relies on packager backend to provide this information. This would be cool, but right now there is no way we can get categorizing information from apk-tools itself (ideally struct apk_package would provide this info, meh, dreams).

        No, apk-tools shouldn't provide this since Appstream already is the defacto standard here and works just fine. With GNOME Software there's an Appstream plugin that searches for Appstream files for all known packages, so it's sufficient to let Software know about the packages that are available via apk and it'll get the additional metadata itself (if it's installed on the system).

        I imagine that we would have an extra repository for these appstream files, pmapps.git, and it would have one dir for each app, with the metadata. In contrary to having our own flatpak repo, this would not duplicate stuff from the pmaports repository so it should be a lot easier to maintain

        I think having a seperate repositories is going to be a massive pain to update (since you'd need to always look out for Alpine updating a package so you can extract the metadata from the package and add it to the repo). I think adding -appstream or -metainfo packages is probably a better idea.

        By Rasmus Thomsen on 2020-03-22T22:21:55

        Edited by Ghost User
      • Administrator
        Administrator @root · Imported
        Author Owner

        No, apk-tools shouldn't provide this

        I'm not trying to say it should, just that this would be convenient to get this info directly from package :smile:

        Appstream already is the defacto standard here and works just fine. With GNOME Software there's an Appstream plugin that searches for Appstream files for all known packages

        I have zero idea how this works, where are those magical files stored? How this works exactly? Is there some guide I could read to get an enlightenment..?

        By Alexey Min on 2020-03-22T22:22:07

        Edited by Administrator
      • Please register or sign in to reply
    • Administrator changed milestone to %Apps · Imported

      changed milestone to %Apps

      By Oliver Smith on 2020-03-22T02:27:50

    • Administrator mentioned in issue #21 (closed) · Imported

      mentioned in issue #21 (closed)

      By Oliver Smith on 2020-03-24T23:15:57

      • Administrator
        Administrator @root · Imported
        Author Owner

        I've now read about appstream and what it is, and specifically this page: https://www.freedesktop.org/software/appstream/docs/chap-AppStream-About.html

        AppStream provides specifications for meta-information which is shipped
by upstream projects and can be consumed by other software. 
...
Distributors provide metadata as well, which describes all components
available in a software repository. That data is composed of the
upstream-metainfo and some other sources.

        I image that we would have an extra repository for these appstream files,

        @ollieparanoid It seems to me that distro should provide metadata files for all packages availiable in its repositories, am I right? Does Alpine do it? @Cogitri

        By Alexey Min on 2020-04-06T05:39:56

        Edited by Ghost User
      • Administrator
        Administrator @root · Imported
        Author Owner

        No, right now we only package it with the main package. I think we should make something similiar to the -doc subpackages: add -appstream subpackages and then add ab appstream package that pulls all of them in

        By Rasmus Thomsen on 2020-04-06T05:39:56

      • Administrator
        Administrator @root · Imported
        Author Owner

        That would result in having metadata for all installed packages, but we need it (ideally) for every package in repos, even for not installed ones, just to display their icons/descriptions in software center apps

        By Alexey Min on 2020-04-06T12:17:13

        Edited by Administrator
      • Administrator
        Administrator @root · Imported
        Author Owner

        Err right, that's what I had in mind, but the doc function doesn't work that way. I meant that we should have an -appstream package that pulls in all appstream packages.

        By Rasmus Thomsen on 2020-04-06T12:19:12

      • Administrator
        Administrator @root · Imported
        Author Owner

        From what I understand distribution should provide accumulated appstream metadata info during package build process (for all packages that have appstream metadata included)

        I found where Debian keeps it - https://appstream.debian.org/data/sid/main/ . Components-*.gz files contain the actual metainfo and there are also icons... Info from https://wiki.debian.org/AppStream

        By Alexey Min on 2020-04-06T12:39:31

      • Administrator
        Administrator @root · Imported
        Author Owner

        This is what Arch Linux does: https://www.archlinux.org/packages/extra/any/archlinux-appstream-data/

        By Luca Weiss on 2020-04-06T20:17:38

      • Administrator
        Administrator @root · Imported
        Author Owner

        Hm, I don't think that'd fit as nicely into our build process compared to just adding -appstream subpackages and pulling all of them in though

        By Rasmus Thomsen on 2020-04-06T20:22:41

      • Please register or sign in to reply
    • Administrator
      Administrator @root · Imported
      Author Owner

      The winner is AppArmor: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2624

      By Oliver Smith on 2021-10-22T16:47:17

    • Administrator closed · Imported

      closed

    Please register or sign in to reply