On Wed, Sep 9, 2015 at 6:20 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:

Hi,

Hm... we want to keep Darktable featured in GNOME Software. But I think we are taking the anti-bundling crusade a bit too far, especially considering we're about to *mandate* bundling for the *vast majority* of libraries by nature of xdg-app.

A ticket is going to be opened in the FESCo tracker to discuss the broader implications of Fedora's packaging guidelines compared to the reality of software development today. Frankly, I hope we find a much better balance than we have today.

However, it is unclear to me 1) what you mean by mandate, and 2) how you plan on doing so at a Fedora Project level particularly when the project has not committed to shipping any kind of xdg-app at all. I believe the desire and intentions are there, but mandate seems a bit bold at this point.

I'm extremely hesitant to go down the route of removing applications from Fedora due to packaging guideline issues, then turning around and making them available in coprs and featuring them in Software. That

To be clear, Darktable was retired on the f23 and master branches this afternoon. If you want to feature it in Software, you need to use the Copr for F23.

provides no incentive for packagers to fix the issues, and heralds a future where packagers don't even attempt to get packages into Fedora, but just use coprs instead. (It's already happening [1]!)

Yes, Coprs are being used to provide useful software outside of the Fedora repositories. This is not surprising at all. What would be the good of building the Copr infrastructure if it wasn't used? I also don't think it is all that much of a problem either.

Also, from a delivery and infrastructure standpoint, xdg-apps will most likely look very similar. I don't see any reason to discourage Copr usage while then turning around and encouraging xdg-apps.

Anyway, I've been reading [2] and [3] in particular, and it seems like this is a classic example of where a permanent bundling exception would be appropriate: the application and library need to be updated in tandem, different applications will want to update the library at different times, and the upstream library maintainers expressly intend it to be bundled. Either the applications bundle the library, or we have to package multiple versions of the library, each one intended to be used by a particular application, and what good does that serve? Meanwhile, the Darktable developers agreed to work on eliminating the bundling issues for all other libraries, which indicates a temporary bundling exception would be appropriate for those cases. It's discouraging that FPC feels otherwise.

Some in FESCo agreed, which is why the aforementioned ticket is going to be opened.

josh

On Wed, Sep 9, 2015 at 6:06 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:

On Wed, 2015-09-09 at 18:33 -0400, Josh Boyer wrote:

...

However, it is unclear to me 1) what you mean by mandate, and 2) how you plan on doing so at a Fedora Project level particularly when the project has not committed to shipping any kind of xdg-app at all. I believe the desire and intentions are there, but mandate seems a bit bold at this point.

In the Workstation WG, there is consensus on moving towards distributing applications as xdg-app bundles. Applications will be required to bundle any library not provided by the xdg-app runtime. I don't think we have made any formal decisions regarding this, but it seems almost inevitable at this point. We also haven't defined what applications will be required to use xdg-app, but history tells us that if the answer isn't "almost everything," the project will fail. An optional application sandbox is a pointless application sandbox; developers aren't going to use it if it's optional, since that's more work for them.

...

Yes, Coprs are being used to provide useful software outside of the Fedora repositories. This is not surprising at all. What would be the good of building the Copr infrastructure if it wasn't used? I also don't think it is all that much of a problem either.

I don't really understand what the end goal is with coprs, I suppose, and I'm not sure if the copr developers or anyone else does either. There's really no practical difference to the end user whether the application is in Fedora or a copr, so long as it appears in GNOME Software. But if the packaging guidelines can be circumvented simply by migrating applications to a copr, then applications are going to migrate to coprs. Eventually we're going to have a lot fewer applications in the Fedora repositories. This isn't necessarily a bad thing, but I don't really see why it's desirable....

Accepting all premises above, Copr end run around means application sandboxing is pointless, and xdg-app will fail because it makes both optional.

On Wed, 2015-09-09 at 20:56 -0500, Pete Travis wrote:

As a follower of the discussion, and packager of an application that might fall under these requirements, your phrasing here makes me nervous. I'm not reading "We will develop infrastructure for distributing xdg -apps", I'm reading "We will require infrastructure for development and distribution xdg-apps be developed". Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps.

I'm not sold. I don't believe that the majority of users consume Fedora exactly as intended by this kind of strategy, and I am dubious that the project would be better off if they did. The strength of Fedora is in both polish and extensibility. Extremes in either direction weaken the appeal. Look at devassist, for example - in my opinion, the one included 'application' serving the developer workstation use case. There's talk of dumping it for lack of polish, and talk of deployment methodology mandates....

Either I'm totally lost, OR the GNOME spin should rebrand as a desktop computing appliance with a wholly curated experience, and the project should promote some other implementation as a versatile desktop Linux distribution.

Hi,

You've posed a hard question that we've been ignoring because it's hard.

Your key point is: "Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps."

The compromise solution will probably wind up being that Software only exposes xdg-apps, like you fear, but I'm going to argue that doesn't go nearly far enough. You maybe haven't considered that we have a compelling interest to make sure users can run only sandboxed xdg-apps, period, so that bad guys can't own users' computers by putting custom installers and RPMs up for download on their web sites. But we also want to make sure Fedora remains a general purpose OS that the user has full control over: we're not respecting the user if we limit what he can do like an iThing. The goals are contradictory.

If you can do whatever you want, you'll probably install the first non -sandboxed, non-xdg-app-ified third-party app that you want to use. If that becomes commonplace, it will totally defeat the purpose of having application sandboxes: we might as well not bother, because sandboxing all the non-malicious applications does us zero good if the malicious applications simply don't use the sandbox. Analogy: Windows and Java application signing is intended to make it harder to distribute malware. It's also totally worthless, because it's optional, and nobody cares whether an application is signed or not, or even understands what that means. (In fact, it's worse than worthless, it's actively harmful, since it trains users to ignore security questions.) This is *exactly* what is going to happen to xdg-app if we allow running things that aren't xdg-apps. It's also what's going to happen to sandboxed xdg-apps if we allow running unsandboxed xdg-apps. Even if most apps play nicely in the sandbox, you're just going to get owned by the ones that don't, and building the sandbox was a waste of effort.

The best way to solve that problem is to become an iThing, which we definitely aren't going to do, because that would be disrespectful to users and just plain BS. But we have to do that, or we're not protecting users, and that too is disrespectful and BS. So what do we do? Probably find a compromise between the two extremes, which sounds to me like exposing only sandboxed xdg-apps in Software, but that's *really* not enough, because like you say: packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps.

Anyway, we need to give you a non-BS answer, and I don't have one, sorry. Maybe somebody else does.

Michael

hi I've been following this thread for a while, and I've got a couple of questions. Will this xdg-app export to, or be able to grant access to, accessibility tools, such as orca? I like the idea of sandboxed applications, regardless of whether they're an imperfect form of security or not, no form of security is perfect. Is the xdg-app specification being designed to from the start allow assistive tools, such as orca, magnifiers, etc to get access to these sandboxed apps? If not, I'd strongly suggest it be added. This is a chance for accessibility to be designed in, rather than bolted on later, which is usually a better solution, imo. I can't speak to how good or otherwise sandboxing is in terms of security, but it's better than nothing, and it can only help linux, which is already pretty secure, and very secure once you add in SELinux. Thanks Kendell clark

On 09/11/2015 06:02 AM, Josh Boyer wrote:

On Fri, Sep 11, 2015 at 1:41 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:

...

On Wed, 2015-09-09 at 20:56 -0500, Pete Travis wrote:

...

As a follower of the discussion, and packager of an application that might fall under these requirements, your phrasing here makes me nervous. I'm not reading "We will develop infrastructure for distributing xdg -apps", I'm reading "We will require infrastructure for development and distribution xdg-apps be developed". Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps.

I'm not sold. I don't believe that the majority of users consume Fedora exactly as intended by this kind of strategy, and I am dubious that the project would be better off if they did. The strength of Fedora is in both polish and extensibility. Extremes in either direction weaken the appeal. Look at devassist, for example - in my opinion, the one included 'application' serving the developer workstation use case. There's talk of dumping it for lack of polish, and talk of deployment methodology mandates....

Either I'm totally lost, OR the GNOME spin should rebrand as a desktop computing appliance with a wholly curated experience, and the project should promote some other implementation as a versatile desktop Linux distribution.

Hi,

You've posed a hard question that we've been ignoring because it's hard.

Your key point is: "Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps."

The compromise solution will probably wind up being that Software only exposes xdg-apps, like you fear, but I'm going to argue that doesn't go nearly far enough. You maybe haven't considered that we have a compelling interest to make sure users can run only sandboxed xdg-apps, period, so that bad guys can't own users' computers by putting custom installers and RPMs up for download on their web sites. But we also want to make sure Fedora remains a general purpose OS that the user has full control over: we're not respecting the user if we limit what he can do like an iThing. The goals are contradictory.

If you can do whatever you want, you'll probably install the first non -sandboxed, non-xdg-app-ified third-party app that you want to use. If that becomes commonplace, it will totally defeat the purpose of having application sandboxes: we might as well not bother, because sandboxing all the non-malicious applications does us zero good if the malicious applications simply don't use the sandbox. Analogy: Windows and Java application signing is intended to make it harder to distribute malware. It's also totally worthless, because it's optional, and nobody cares whether an application is signed or not, or even understands what that means. (In fact, it's worse than worthless, it's actively harmful, since it trains users to ignore security questions.) This is *exactly* what is going to happen to xdg-app if we allow running things that aren't xdg-apps. It's also what's going to happen to sandboxed xdg-apps if we allow running unsandboxed xdg-apps. Even if most apps play nicely in the sandbox, you're just going to get owned by the ones that don't, and building the sandbox was a waste of effort.

That's ignoring the existing security measures we have in place, like RPM/dnf requiring signatures on packages and SELinux. Sure, if users force install everything then yes they can have their systems owned. This has always been true and xdg-apps doesn't present a new wrinkle at all here.

...

The best way to solve that problem is to become an iThing, which we definitely aren't going to do, because that would be disrespectful to users and just plain BS. But we have to do that, or we're not protecting users, and that too is disrespectful and BS. So what do we do? Probably find a compromise between the two extremes, which sounds to me like exposing only sandboxed xdg-apps in Software, but that's *really* not enough, because like you say: packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps.

Anyway, we need to give you a non-BS answer, and I don't have one, sorry. Maybe somebody else does.

I think you're taking too hard a line on this. Yes, possibility exists for people to screw up their own machines. It will always exist. That doesn't mean the infrastructure we have today and the xdg-apps work being done is worthless.

I'd also contend that users don't care about xdg-apps. Really, they probably don't. If you tell them it will run anywhere and it's sandboxed they'll say "oh, that's cool" and then get back to using their app. The group that gets the majority of the benefit of xdg-app is developers because it makes publishing their work in a secure and well supported way even easier.

So I don't really agree with your BS assertion on either side. The compromise is pretty simple. We provide applications in Software because Software exists to show users what applications can be installed. It shouldn't matter what deployment technology the apps use, as long as they come from a trusted source.

If you want to make non-sandboxed apps more secure, then perhaps work could be done to create sandboxes on-the-fly for regular RPMs. That would be difficult, but it would provide an added layer of security. It wouldn't necessarily be an xdg-app as that is more than just sandboxing, but creating a new namespace/Docker container for apps during RPM install might be possible.

josh

On Fri, 2015-09-11 at 06:07 -0500, kendell clark wrote:

hi I've been following this thread for a while, and I've got a couple of questions. Will this xdg-app export to, or be able to grant access to, accessibility tools, such as orca?

With the way a11y is currently set up, we will have to do a tiny amount of extra plumbing to make the accessibility bus available inside the sandbox. That is not hard at all. Unfortunately, it will probably give apps a way out of the sandbox, so we should look at ways to limit the access the a11y bus from inside the sandbox to just 'send events and receive commands'.

Alex, have you looked at this ?

Changing the title of the thread again... hard to believe this started out as a discussion about Darktable.

On Tue, 2015-09-15 at 11:51 +0200, Alexander Larsson wrote:

No, i have not. Its on my todo list, but honestly its been pushed down partially because i have no real idea how this stuff works at all. :/

Me too. I ran into the same trouble working on the sandbox for WebKit: https://bugs.webkit.org/show_bug.cgi?id=143004

I chatted with Alejandro Piñeiro about this today. The at-spi2 socket is a total sandbox escape: it can be used to inspect the accessibility tree of arbitrary applications, send them keyboard input, etc. We can't allow access to it. Also we can't block it, since that breaks a11y. A design change will be required. It should be considered in tandem with the problem of supporting a11y under Wayland, since the design problem there is similar. The basic issue is that Wayland clients have no access to other Wayland clients (except through clipboard and drag-and -drop selections), which is a security feature of the Wayland protocol, but one that breaks much of a11y, gnome-screenshot, etc. a11y needs a way to give privileged applications such access, while limiting the access of unprivileged applications.

Michael

Hi,

I will start with a TL;DR summary of my mail: we don't have to sandbox our xdg-apps, like you say. But if we do, we should only allow running sandboxed apps, even if it means we lose most of our apps. Otherwise, the sandbox is pointless. It's a hard choice we'll need to make. Right now, we're headed towards developing a useless sandbox, which is silly, and it's time to apply the breaks and rethink that.

On Fri, 2015-09-11 at 07:02 -0400, Josh Boyer wrote:

That's ignoring the existing security measures we have in place, like RPM/dnf requiring signatures on packages

This isn't true; you can install unsigned packages whenever you want, just by clicking through (well, keypressing-through) the warning from dnf. If you've installed RPMFusion, you've done this.

and SELinux.

SELinux is very important, but the security model is completely different: it's designed to protect benign but buggy applications from being owned by malicious input. We're trying to protect against applications that are themselves malicious. The malicious app is simply not going to ship with an SELinux policy that constrains it from doing the bad things it wants to do. Actually, it will not ship with an SELinux policy at all, because it's not mandatory to write an SELinux policy, so nobody does.

Let's agree on the attack model before we continue the discussion: the attacker's goal is to read some file it's not supposed to from the user's home directory. It's not trying to find some kernel exploit for privilege escalation, because it doesn't need any privilege escalation: it can do all the bad things it wants to do without that. Stopping it requires xdg-app, or a similar technology, or a very restrictive default SELinux policy that breaks everything (which is worth considering).

Sure, if users force install everything then yes they can have their systems owned. This has always been true and xdg-apps doesn't present a new wrinkle at all here.

The goal should be to make it sufficiently difficult and scary to force install things that a large majority of users will decide not to, but you still can if you really want to.

I think you're taking too hard a line on this. Yes, possibility exists for people to screw up their own machines. It will always exist. That doesn't mean the infrastructure we have today and the xdg-apps work being done is worthless.

I'd also contend that users don't care about xdg-apps. Really, they probably don't. If you tell them it will run anywhere and it's sandboxed they'll say "oh, that's cool" and then get back to using their app. The group that gets the majority of the benefit of xdg -app is developers because it makes publishing their work in a secure and well supported way even easier.

So I don't really agree with your BS assertion on either side. The compromise is pretty simple. We provide applications in Software because Software exists to show users what applications can be installed. It shouldn't matter what deployment technology the apps use, as long as they come from a trusted source.

That's one possible choice for us. We can do it. xdg-apps still provide good benefit for developers as a cross-platform way to deploy applications. But then there is no point in sandboxing the xdg-apps, because the optional sandbox doesn't protect users, and it's inconvenient for developers, so it's more harm than good. We'll miss out on the tremendous security benefits of sandboxed applications.

That's a valid choice for us to make, though. It might be the best choice, because there is a huge cost to pay in losing existing apps if we want to mandate the sandbox! It's going to be hard -- perhaps unrealistically hard -- to tell developers all their apps have to change, and to tell users old apps can't be installed anymore. But if we don't do that, we should give up on the plans for sandboxed applications, because it's also unrealistic to expect malicious applications to use the optional sandbox.

We could define some subset of applications that are allowed to not use the sandbox, say all the existing packages in the Fedora repositories, but it's not hard to get a malicious application into Fedora, or take a non-malicious application and make it malicious, so again, the sandbox provides only quite limited benefit. (We're completely reliant on our upstreams and our packagers to never add bad stuff.)

If you want to make non-sandboxed apps more secure, then perhaps work could be done to create sandboxes on-the-fly for regular RPMs. That would be difficult, but it would provide an added layer of security. It wouldn't necessarily be an xdg-app as that is more than just sandboxing, but creating a new namespace/Docker container for apps during RPM install might be possible.

This might well happen, but it can't work well. The thing is, either applications require changes to be useful when run in the sandbox, or the sandbox isn't good enough. LibreOffice isn't going to be a very great app if it can't see any of your files when you run the file chooser, and if the files it saves can't be accessed by other apps. And the sandbox is worthless if it lets LibreOffice access files without going through the file portal. But I argue that's the fate that should await applications that aren't ported to use the portals provided by the sandbox: apps should be sandboxed automatically, even if the result is that they're broken.

I'm picking on LO just as an example; Alex already has a working demo of LO using the file portal. The big apps will be taken care of by developers who care; it's the smaller apps that will be out of luck. But then we lose users when their old apps don't work properly. Or we lose users because we didn't let them run the old apps at all.

Michael

Hi,

On Fri, 2015-09-11 at 18:25 +0300, Elad Alfassa wrote:

People would prefer to develop against a stable runtime that will work anywhere because it's less work than developing for moving targets of many distributions which change too often. The sandbox would be a "side effect" from them, and it will protect the users from misbehaving apps and some security flaws.

But this only applies to non-malicious apps. You're right that if xdg -app makes distributing software easier to a greater degree than the sandbox makes it harder, it will be used by non-malicious developers, which will definitely improve our security overall. Which is a big benefit, so I was wrong and the sandbox is worth it, regardless of whether it protects against malicious apps or not. (But it still does zero good against malicious third-party apps.)

Michael

Hi,

On Fri, 2015-09-11 at 11:29 -0400, Daniel J Walsh wrote:

Sandboxing apps is about protecting your desktop from the app, Not protecting your app from unsandboxed apps on your desktop.

If we had a sandboxed firefox when a firefox vulnerability happens, then my ~/.ssh content is much less at risk. Similarly my financial data and other financial data is not at risk.

If we could sandbox the largest GUI Apps like firefox, evince/acroread, Libreoffice, games this would be a big step forward in securing the desktop, even if some users continue to download apps from hackme.com.

Yeah, that's a big flaw in my argument: sandboxed apps are still useful because they provide benign apps better protection from malicious input, to complement SELinux.

Yes although most people have not, or only a few packages. Sandboxing apps is about protecting you from bugs in trusted apps, not about preventing untrusted apps that you install bypassing security.

That's actually what we were hoping to use the sandbox for: to protect the user from malicious apps.

Michael

On Fri, 2015-09-11 at 11:38 -0400, Josh Boyer wrote:

Sigh. We're going to simply disagree on this point. I cannot agree with your black and white view on this. I understand your argumentation, but I think it's overly drastic and defeatist.

josh

Well I've been thoroughly convinced that I was (mostly) wrong, so no further disagreement from me!

Michael

On Fri, Sep 11, 2015 at 9:16 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:

Hi,

I will start with a TL;DR summary of my mail: we don't have to sandbox our xdg-apps, like you say. But if we do, we should only allow running sandboxed apps, even if it means we lose most of our apps. Otherwise, the sandbox is pointless.

I don't know that this is true. OS X has mandatory sandboxing (App Store apps), and optional sandboxing (everything else). Both of those ecosystems are strong. Maybe they've compromised somewhat the potential security compared to permitting only sandboxed apps, but the reason they've done it this way is the more aggressive alternative would have killed the platform. Now maybe today they could move to App Store only model and have compulsory sandboxing?

On Fri, 2015-09-11 at 07:02 -0400, Josh Boyer wrote:

...

Sure, if users force install everything then yes they can have their systems owned. This has always been true and xdg-apps doesn't present a new wrinkle at all here.

The goal should be to make it sufficiently difficult and scary to force install things that a large majority of users will decide not to, but you still can if you really want to.

Missing, in my opinion, is application signature verification after installation. I want the option (preferably by default) to know that installed packages haven't been modified after they were installed, not merely that they were considered safe at the time they were installed.

On Fri, 2015-09-11 at 00:41 -0500, Michael Catanzaro wrote:

On Hi,

You've posed a hard question that we've been ignoring because it's hard.

I think you are being unnecessarily alarmist and defeatist here.

The thing to realize is that Fedora has no interest in *preventing* users from installing arbitrary software on their system. What we have an interest in is preventing users from being *tricked* into installing such software.

Your key point is: "Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps."

I think we have to be clear here that Software currently shows only software that is built on Fedora servers.

(There is discussion of changing it to allow for disabled repositories to end up in search results, but these would still be rare exceptions, carefully selected.)

What xdg-app allows is to make it plausible to greatly *extend* the set of software - to allow displaying results that are not built by Fedora.

It can't be a complete wild west - there have to be mechanisms for reporting abuse, blacklisting apps, etc - but we can very viably allow people to download and run applications built by 3rd parties, without making every such app downloaded be able to do *absolutely anything on the system* as is the case now.

For applications built in Fedora - moving them to xdg-apps provides incremental benefits, such as having a security vulnerability in an application be localized to that applications - so there's an incentive to work in this direction.

But there's no point in just blanking kicking out all existing applications in Fedora out of Software unless they are packaged as xdg- apps - that doesn't benefit the user.

The compromise solution will probably wind up being that Software only exposes xdg-apps, like you fear, but I'm going to argue that doesn't go nearly far enough. You maybe haven't considered that we have a compelling interest to make sure users can run only sandboxed xdg-apps, period, so that bad guys can't own users' computers by putting custom installers and RPMs up for download on their web sites. But we also want to make sure Fedora remains a general purpose OS that the user has full control over: we're not respecting the user if we limit what he can do like an iThing. The goals are contradictory.

We might want to eliminate the behavior where, currently, you can click on an RPM link and the RPM is opened by GNOME Software. Or at least the ability to override the default rejection of unsigned packages by entering an admin password.

But that doesn't mean that we're preventing people from installing such RPMS and taking the control out of the system out of the people using the system.

- Owen

I missed the subject change here, so I'll pick a seemingly appropriate point in the thread...

On Fri, Sep 11, 2015 at 10:30 AM, Owen Taylor otaylor@redhat.com wrote:

On Fri, 2015-09-11 at 00:41 -0500, Michael Catanzaro wrote:

...

On Hi,

You've posed a hard question that we've been ignoring because it's hard.

I think you are being unnecessarily alarmist and defeatist here.

The thing to realize is that Fedora has no interest in *preventing* users from installing arbitrary software on their system. What we have an interest in is preventing users from being *tricked* into installing such software.

...

Your key point is: "Packages not represented in Software are installed by users now, and these packages will continue to be installed if Software deigns to only expose xdg-apps."

I think we have to be clear here that Software currently shows only software that is built on Fedora servers.

(There is discussion of changing it to allow for disabled repositories to end up in search results, but these would still be rare exceptions, carefully selected.)

My key point is that currently, Software exposes Applications (as defined by the GNOME HIG?). Users are installing applications, and they are installing packages that are *not* applications. I installed four new python modules on this machine today; none of them were malicious, none were from a third party. I'm just trying to frame this in an appropriate context; I'm not sure if language being used here describes the behavior of one specific application on my system, gnome-software, or a system policy.

What xdg-app allows is to make it plausible to greatly *extend* the

set of software - to allow displaying results that are not built by Fedora.

It can't be a complete wild west - there have to be mechanisms for reporting abuse, blacklisting apps, etc - but we can very viably allow people to download and run applications built by 3rd parties, without making every such app downloaded be able to do *absolutely anything on the system* as is the case now.

For applications built in Fedora - moving them to xdg-apps provides incremental benefits, such as having a security vulnerability in an application be localized to that applications - so there's an incentive to work in this direction.

But there's no point in just blanking kicking out all existing applications in Fedora out of Software unless they are packaged as xdg- apps - that doesn't benefit the user.

...

The compromise solution will probably wind up being that Software only exposes xdg-apps, like you fear, but I'm going to argue that doesn't go nearly far enough. You maybe haven't considered that we have a compelling interest to make sure users can run only sandboxed xdg-apps, period, so that bad guys can't own users' computers by putting custom installers and RPMs up for download on their web sites. But we also want to make sure Fedora remains a general purpose OS that the user has full control over: we're not respecting the user if we limit what he can do like an iThing. The goals are contradictory.

We might want to eliminate the behavior where, currently, you can click on an RPM link and the RPM is opened by GNOME Software. Or at least the ability to override the default rejection of unsigned packages by entering an admin password.

But that doesn't mean that we're preventing people from installing such RPMS and taking the control out of the system out of the people using the system.

• Owen

xdg-apps makes sense to me for all those reasons. The third party stuff is more destructive - although not necessarily less secure - when delivered poorly; xdg-app adoption can combat the issues that come with installing arbitrary packages from the wild. End users might end up with bundled, unresolved vulnerabilities - but if their preferred third party apps were bundled nicely and available from the vendor, perhaps there'd be fewer folks hanging in to EOL releases.

I'm not against the idea of a computing / content consumption appliance as a Fedora deliverable. My point is more about market positioning. A few concepts have been thrown out here:

- Only allow installation of Applications meeting some kind of vetting parameters (leaving aside the implementation.) - Only allow execution of Applications installed as above.

That's great; Fedora can ship all the favorite Applications this way, and set an example for third party vendors. However, while I believe that the idea of a locked-down, secure desktop environment has merit, it seems mutually exclusive with the idea of a development workstation - at least without mandating a very specific development workflow. Most of the Applications I use were installed OOTB, or can easily be installed with Software now; xdg-apps won't change that part of my Fedora experience. I also use a shitton of command line utilities, editors, language libraries, reporting tools, sysadmin whizbangs, whatever and the context of this discussion ignores all that.

The productization of Fedora was purportedly aimed at enabling the project to target user bases more specifically instead of trying to be everything for everyone. The KDE folks have been refused Edition status at least partially on the basis that Workstation is already the developer-targeting product; meanwhile, the Workstation group seems to focus on content creation and consumption, instead of technology development. I don't know if there's a brand identity crisis, or if I'm just ignorant of the Workstation goals, or have different connotations for terms like 'developer' and 'workstation', or....

-- Pete

On Sep 14, 2015 10:39 AM, "Paul W. Frields" stickster@gmail.com wrote:

On Fri, Sep 11, 2015 at 07:14:18PM -0500, Pete Travis wrote: [...snip...]

...

The productization of Fedora was purportedly aimed at enabling the

project

...

to target user bases more specifically instead of trying to be

everything

...

for everyone. The KDE folks have been refused Edition status at least partially on the basis that Workstation is already the

developer-targeting

...

product; meanwhile, the Workstation group seems to focus on content creation and consumption, instead of technology development. I don't

know

...

if there's a brand identity crisis, or if I'm just ignorant of the Workstation goals, or have different connotations for terms like 'developer' and 'workstation', or....

At the risk of being tiresome, I'd like to reiterate that content creation and consumption are not exclusive to non-developers. As has been said many times, "developers are people too," and they engage in many of the same activities as non-developers. The Workstation team is not focusing exclusively on these common activities, but you can't have an effective Workstation without them.

-- Paul W. Frields

I don't disagree, and recognize that particular argument is tired...

I'm bringing it up again because the xdg-apps discussion leads me to believe there is a goal of only allowing users to install and execute approved graphical applications, and I'm having trouble visualizing how someone would perform common development tasks like installing libraries or executing their own code with that model. They could strictly use devassist and gnome-builder, I suppose, which seems like mandating a very specific development workflow.

Or, to put it another way, if Workstation goes in that direction, I'm offering to document the workarounds and config changes required to enable existing development patterns.

--Pete

On 09/10/2015 08:40 AM, Stephen Gallagher wrote:

One step in from that are the curated COPR repos. Specifically, those applications that are self-contained within their repository and do not alter any part of the platform. This is a good place to put software like Chromium, PyCharm or Darktable. Packages that aren't going to meet our strict guidelines (and don't really need to in order to be useful). In general, we'd want keep this to a small list of upstreams that are reasonably good at keeping themselves patched for security bugs, of course.

If this is a "step in" from the randomness of the outermost copr repos, has any consideration been given to them being enabled by default? I am concerned that we're going to have some very valuable apps in this curated copr space that are going to prove difficult for the very users who want to use them most (less technical users trying out fedora perhaps for the first time) to be able to get them installed.

I'm guess still unclear on what the F23 darktable installation experience is going to be like, I guess. Can anybody point to or a provide a write up step-by-step of what that experience is going to look like?

~m

On 10 September 2015 at 15:09, Paul W. Frields stickster@gmail.com wrote:

• The user selects installation, and receives a notice that the application is not part of official Fedora repositories.

Isn't this a workaround for the FPC decision? It kinda means thousands of users are going to have problems upgrading to F23, and have to click a little button to enable a 3rd party copr (which can do pretty much anything to your system...) which will mean very little to most people.

Can't someone just tell the FPC they got it wrong in this case? FPC is not a useful thing if we're promoting workarounds for our default product.

Richard.

On Thu, 2015-09-10 at 15:16 +0100, Richard Hughes wrote:

On 10 September 2015 at 15:09, Paul W. Frields stickster@gmail.com wrote:

...

• The user selects installation, and receives a notice that the application is not part of official Fedora repositories.

Isn't this a workaround for the FPC decision? It kinda means thousands of users are going to have problems upgrading to F23, and have to click a little button to enable a 3rd party copr (which can do pretty much anything to your system...) which will mean very little to most people.

Can't someone just tell the FPC they got it wrong in this case? FPC is not a useful thing if we're promoting workarounds for our default product.

FESCo didn't want to overrule FPC on this (in part because none of us had followed it too closely). That said, I'm raising a discussion to change the policy rather than work around it. See the devel@ list and feel free to voice support or disagreement.

On Thu, Sep 10, 2015 at 12:06 PM, Debarshi Ray rishi.is@lostca.se wrote:

On Thu, Sep 10, 2015 at 03:16:08PM +0100, Richard Hughes wrote:

...

On 10 September 2015 at 15:09, Paul W. Frields stickster@gmail.com wrote:

...

• The user selects installation, and receives a notice that the application is not part of official Fedora repositories.

Isn't this a workaround for the FPC decision? It kinda means thousands of users are going to have problems upgrading to F23, and have to click a little button to enable a 3rd party copr (which can do pretty much anything to your system...) which will mean very little to most people.

It is, and this why I disagree with the rest of FESCo on this.

...

Can't someone just tell the FPC they got it wrong in this case? FPC is not a useful thing if we're promoting workarounds for our default product.

FESCo could have overruled the FPC, but they chose not to [1].

Cheers, Debarshi

[1] Since I was the only one in FESCo opposing this decision, I chose to use "they" to refer to the committee, instead of "we".

This is accurate and perfectly acceptable.

In light of some further discussion today, I'd probably change my vote to support an override but it still would not come to quorum.

josh

On Thu, Sep 10, 2015 at 04:16:48PM +0000, Debarshi Ray wrote:

Hey Josh,

On Thu, Sep 10, 2015 at 12:13:22PM -0400, Josh Boyer wrote:

...

In light of some further discussion today, I'd probably change my vote to support an override but it still would not come to quorum.

That's OK. We will get there eventually. :)

/me is happy that he didn't chew jwb's head for nothing last evening

Current update: there's now a temporary exception for F23/24 for darktable, which can return so we avoid crushing the Design spin unnecessarily. Hopefully the discussion sgallagh started on devel@ will bear some fruit for a more reasonable approach to what we think is the reality of upstream developers.

On Thu, 2015-09-10 at 10:18 -0400, Máirín Duffy wrote:

On 09/10/2015 10:09 AM, Paul W. Frields wrote:

...

• The user selects installation, and receives a notice that the application is not part of official Fedora repositories. (I

don't know the current text.) When the user approves, the copr .repo definition is set to enabled=1.

Is that copr .repo just for darktable and its deps, or is it a larger "curated outer ring" copr with more stuff in it?

Just darktable and its deps. Every app installed in that way would have its own separate repo file (and COPR repository backing it)

On 09/10/2015 05:42 AM, Luya Tshimbalanga wrote:

On 09/09/15 03:33 PM, Josh Boyer wrote:

...

...

I'm extremely hesitant to go down the route of removing applications from Fedora due to packaging guideline issues, then turning around and making them available in coprs and featuring them in Software. That

To be clear, Darktable was retired on the f23 and master branches this afternoon. If you want to feature it in Software, you need to use the Copr for F23.

Really? As a maintainer of Design Suite Labs, I am surprised Darktable was retired while the package is still accessible on Fedora 23 and one of highlight of the spin.

I am sad and disappointed how this went down. This is a package that Workstation is clearly interested in, as various people pointed out in the FESCo meeting. Yet, the decision to drop it was rushed without consulting the Workstation WG or even asking the package maintainers (madko in Fedora, ohaessler in EPEL) to come to the meeting to discuss this.

And it all went down in less than 8 hours, from the filing of the FESco ticket to the blocking of the package.

Kalev, sad panda.

On 10 September 2015 at 13:10, Kalev Lember kalevlember@gmail.com wrote:

I am sad and disappointed how this went down. This is a package that Workstation is clearly interested in, as various people pointed out in the FESCo meeting.

This is also one of the must-have applications that GNOME Software shows by default in the front page banner. I'm also really disappointed in FESCo and the FPC for the actions taken.

Richard.

On 09/09/2015 06:20 PM, Michael Catanzaro wrote:

Hm... we want to keep Darktable featured in GNOME Software. But I think we are taking the anti-bundling crusade a bit too far, especially considering we're about to *mandate* bundling for the *vast majority* of libraries by nature of xdg-app.

FWIW this application is critical to my workflow getting things done in Fedora; it's not optional and is a needed application. I know it is for others using Fedora for design work - including the Fedora design team - as well:

1) Now that it's been retired from F23, what is going to happen when we do an upgrade from F22 to F23? Is the F22 version going to remain on our systems, potentially in a broken and unusable state? It doesn't seem that it would be possible for me to get the newer version as part of the system upgrade, unless there was some logic in place to add the copr somehow and upgrade as part of the process (since we already clearly opted in to running the software?)

2) Is the Fedora Design Suite still going to be able to be built with Darktable in it, or will it have to be treated as a remix now and renamed?

3) For fresh installs of F23, how involved is it to enable a copr and install darktable from GNOME software?

Apologies if this isn't the appropriate place to ask these questions; I'm happy to redirect given a pointer.

~m

On 09/10/2015 08:47 AM, Stephen Gallagher wrote:

The short version is that what will likely happen is that the old version will remain if it meets the deps or the upgrade will fail its dependency check and not be possible to run until the offending packages were manually uninstalled.

If the upgrade fails its dep check, is it going to be obvious what things the user needs to remove and how in order to proceed with the upgrade?

I think it's ideal for the old version to remain if the deps are met - I think it would be a very jarring (at best) user experience to boot up your freshly upgraded system and have random things that you intentionally installed missing for no apparent reason.

...

2. Is the Fedora Design Suite still going to be able to be built

with Darktable in it, or will it have to be treated as a remix now and renamed?

3. For fresh installs of F23, how involved is it to enable a copr

and install darktable from GNOME software?

Done right, it should be pretty much the same experience as if it was in the official repos, except with a click-through acknowledging that it's not coming from us, but a semi-official third-party.

Is there a system currently in place to enable these click-thrus? How are they meant to display / what is the intention there? The first time you run Darktable, as some kind of splash? Or a clickthrough when you download the design suite from our website?

~m

Okay, so from what I understand thus far then:

1) If I upgrade to F23, I will either be left with F22 darktable and get confused/frustrated when I try to upgrade it (eg when a new feature comes out tha tI want,) or I will be left with a system that I cannot upgrade at all (still an open question as to how obvious the workaround of removing darktable would be?)

2) The Design Suite is going to either (a) drop darktable (b) be dropped itself (c) massively overhauled to become a Fedora Remix.

3) Still don't understand the F23 experience of installing darktable.

In terms of user experience, this simply sucks and makes me feel like slavish adherence to obscure packaging rules is more important than our user base.

~m

On 09/10/2015 09:57 AM, Stephen Gallagher wrote:

I couldn't agree more[1].

[1] https://lists.fedoraproject.org/pipermail/devel/2015-September/2142 62.html

Darktable has been in Fedora for years. How was it able to get into Fedora and be allowed in up until this point?

~m

On 10 September 2015 at 14:45, Máirín Duffy duffy@fedoraproject.org wrote:

Okay, so from what I understand thus far then:

1. If I upgrade to F23, I will either be left with F22 darktable and get

confused/frustrated when I try to upgrade it (eg when a new feature comes out tha tI want,) or I will be left with a system that I cannot upgrade at all (still an open question as to how obvious the workaround of removing darktable would be?)

2. The Design Suite is going to either (a) drop darktable (b) be dropped

itself (c) massively overhauled to become a Fedora Remix.

3. Still don't understand the F23 experience of installing darktable.

In terms of user experience, this simply sucks and makes me feel like slavish adherence to obscure packaging rules is more important than our user base.

As an interested user following the discussion this is how it looks to me too.

Reading the transcripts of the FPC meetings where this was discussed, there seems to be no thought given to what's in the best interests of Fedora's users. Moreover, there's no discussion about if/how the status quo is genuinely a problem (but perhaps that's because everyone present already knew why). In fairness to Rathann, he seems to be of the opinion that's there's no real problem but there is room for improvement, hence his willingness to go with a temporary exemption, but he was overruled.

It's sad when bureaucracy trumps common sense.

-- "Racing turtles, the grapefruit is winning..."

On Sep 10, 2015 10:27 AM, "Paul W. Frields" stickster@gmail.com wrote:

On Thu, Sep 10, 2015 at 09:45:50AM -0400, Máirín Duffy wrote:

...

Okay, so from what I understand thus far then:

1. If I upgrade to F23, I will either be left with F22 darktable and get

confused/frustrated when I try to upgrade it (eg when a new feature

comes

...

out tha tI want,) or I will be left with a system that I cannot upgrade

at

...

all (still an open question as to how obvious the workaround of removing darktable would be?)

2. The Design Suite is going to either (a) drop darktable (b) be dropped

itself (c) massively overhauled to become a Fedora Remix.

3. Still don't understand the F23 experience of installing darktable.

In terms of user experience, this simply sucks and makes me feel like slavish adherence to obscure packaging rules is more important than our

user

...

base.

/me catches up with thread

I'm not sure if 2(c) is necessary, if we have disabled repo support, but I don't understand how that works with the upgrade process. Need moar clue?

I don't know the full details of the disabled repo support, but is there a way to add a script that checks whether the user has darktable currently installed and if so then automatically enable the repo? This way the first upgrade will have the previously mainline package swapped with the copr package?

But agreed, this is truly disappointing and doesn't appear that Fedora is acting like "friends" in the case of a well-maintained and tightly integrated upstream. A slavish, single-minded approach to all upstreams is going to basically force the state (brought up earlier in the thread) where meaningful future apps all go to COPR.

I agree, the people who made the decision to kick darktable need to say "We screwed up" and immediately bring it back in. This kind of policy will guarantee that future packagers to Fedora will either just do it through Copr, or just do it via an external repo.

On Thu, Sep 10, 2015 at 10:38:11AM -0400, Máirín Duffy wrote:

...

On Thu, Sep 10, 2015 at 09:45:50AM -0400, Máirín Duffy wrote:

...

2. The Design Suite is going to either (a) drop darktable (b) be dropped

itself (c) massively overhauled to become a Fedora Remix.

3. Still don't understand the F23 experience of installing darktable.

In terms of user experience, this simply sucks and makes me feel like slavish adherence to obscure packaging rules is more important than our user base.

On 09/10/2015 10:27 AM, Paul W. Frields wrote:

...

/me catches up with thread

I'm not sure if 2(c) is necessary, if we have disabled repo support, but I don't understand how that works with the upgrade process. Need moar clue?

A lot of us use design-suite as a package group and not a live image. My (perhaps flawed assumption) is that the disabled repo support wouldn't help in this case as darktable couldn't be included in the package group being from a different physical repo?

In the context of using design-suite as a package group... is there a way forward without doing it as a remix in a separate repo from the main fedora repos?

You're right -- the design-suite composition was not something I was factoring in. Overtaken By Events now (see earlier update to list), but thanks for raising good points.