3:09 p.m.
Hello,
Today FESCo resolved ticket 1475[1], which was discussing how to
handle the Darktable package. As Stephen Gallagher noted, this is a
somewhat popular package for Workstation setups. It was suggested
that Workstation include the more up-to-date Copr of Darktable in it's
"playground" or "included by not enabled" repository setup. I'm
forwarding this request to the Workstation group for review.
Thank you.
josh
[1] https://fedorahosted.org/fesco/ticket/1475
4:31 p.m.
On Wed, Sep 09, 2015 at 04:09:38PM -0400, Josh Boyer wrote:
Today FESCo resolved ticket 1475[1], which was discussing how to
handle the Darktable package. As Stephen Gallagher noted, this is a
somewhat popular package for Workstation setups. It was suggested
that Workstation include the more up-to-date Copr of Darktable in it's
"playground" or "included by not enabled" repository setup. I'm
forwarding this request to the Workstation group for review.
Thank you.
josh
[1] https://fedorahosted.org/fesco/ticket/1475
Thanks Josh. I think this could be an ideal use for the disabled repo
support. I'll be up front that I haven't seen the latest dialog that
gets presented to the console for activating one of those repos. Does
it accurately cover this case?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
5:20 p.m.
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.
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
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]!)
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.
Michael
[1] https://lists.fedoraproject.org/pipermail/devel/2015-September/2140
77.html
[2] https://github.com/klauspost/rawspeed/issues/109
[3]
https://github.com/klauspost/rawspeed/issues/109#issuecomment-126295602
5:33 p.m.
On Wed, Sep 9, 2015 at 6:20 PM, Michael Catanzaro <mcatanzaro(a)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
7:06 p.m.
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....
Cheers,
Michael
8:15 p.m.
On Wed, Sep 9, 2015 at 6:06 PM, Michael Catanzaro <mcatanzaro(a)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.
--
Chris Murphy
8:56 p.m.
On Sep 9, 2015 7:06 PM, "Michael Catanzaro" <mcatanzaro(a)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....
Cheers,
Michael
--
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.
--Pete
10:42 p.m.
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.
--
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
6:28 a.m.
On Thu, Sep 10, 2015 at 1:20 AM, Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
considering we're about to *mandate* bundling for the *vast
majority*
of libraries by nature of xdg-app.
Well, I'd assume the "vast majority" of the libraries would come from the
runtime and not be bundled in the app.
But I agree with your other point. Unbundling is pretty much useless if the
library can't be shared between apps.
--
-Elad.
7:10 a.m.
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.
7:13 a.m.
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
7:20 a.m.
On 09/10/2015 08:10 AM, Kalev Lember wrote:
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.
https://github.com/klauspost/rawspeed/issues/109#issuecomment-126295602
:-/
~m
7:34 a.m.
On 10 September 2015 at 13:10, Kalev Lember <kalevlember(a)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.
7:40 a.m.
On Wed, 2015-09-09 at 19:06 -0500, Michael Catanzaro 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....
So, one of the major pieces of the Fedora.next design philosophy was
this: we have never had a good differentiation between what it means
to be "in" Fedora vs. "on" Fedora. The packaging guidelines are just
about perfect for describing how best to build a *platform* ("in"
Fedora) but are a very high bar for attempting to build *applications*
("on" Fedora).
One of the original proposals in this space was to have "rings" of
policy, wherein the further out you get from the core of Fedora, the
less restrictive the policy could be. COPRs is one output from that,
being the "furthest ring". You can put anything in a COPR that is
legally distributable and package it however you want.
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.
I think we need to come up with a better term to use for these
specific repositories. They come *from* the COPR system, but they are
closer to being "official" Fedora than others.
I hope this helps explain the rationale here.
7:47 a.m.
On Thu, 2015-09-10 at 08:13 -0400, Máirín Duffy wrote:
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?)
The upgrade process is going to be somewhat tricky. I'm not sure
exactly how it will behave (it'll depend on whether the F22 version
depended on any libraries that had an ABI break on F23). Adding the
ability to automatically-enable the COPR is a very difficult problem.
We may in fact actually want to arrange it so that the package is
completely removed on upgrade (so that users can then go and get it
from GNOME Software again). Not an ideal solution, but perhaps the
only one that could be accomplished in the remaining time.
Unfortunately, this is a classic problem for retired packages. I've
often wondered if Fedora shouldn't have a special meta-package in the
repository (installed by default) that Obsoletes: packages that have
been retired (thereby ensuring that they are removed). But this is
getting a little off-topic.
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.
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.
Apologies if this isn't the appropriate place to ask these
questions;
I'm happy to redirect given a pointer.
8:13 a.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
8:16 a.m.
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
8:17 a.m.
On Thu, 2015-09-10 at 09:13 -0400, Máirín Duffy wrote:
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.
The problem with the old version remaining is bit-rot. But it's
definitely less jarring, sure.
> > 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
The click-through happens when you click "Install" in GNOME Software
(IIRC). No changes are made to the running software.
The Design Suite question is a really tough one. Darktable is no
longer in the standard Fedora repositories, so I'm not sure how
exactly one could produce Design Suite install media that includes it
(short of becoming a Remix, which is a heavyweight solution).
8:45 a.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
8:57 a.m.
On Thu, 2015-09-10 at 09:45 -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?)
That sums it up, yes.
2) The Design Suite is going to either (a) drop darktable (b) be
dropped
itself (c) massively overhauled to become a Fedora Remix.
I haven't been involved with any conversations with that SIG.
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.
I couldn't agree more[1].
[1] https://lists.fedoraproject.org/pipermail/devel/2015-September/2142
62.html
8:59 a.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
9:06 a.m.
Well we could just include the Copr and have it upgrade the F22 package?
----- Original Message -----
From: "Stephen Gallagher" <sgallagh(a)redhat.com>
To: desktop(a)lists.fedoraproject.org
Sent: Thursday, September 10, 2015 9:57:34 AM
Subject: Re: Darktable Copr
On Thu, 2015-09-10 at 09:45 -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?)
>
That sums it up, yes.
> 2) The Design Suite is going to either (a) drop darktable (b) be
> dropped
> itself (c) massively overhauled to become a Fedora Remix.
>
I haven't been involved with any conversations with that SIG.
> 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.
>
I couldn't agree more[1].
[1] https://lists.fedoraproject.org/pipermail/devel/2015-September/2142
62.html
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
9:09 a.m.
On Thu, Sep 10, 2015 at 09:16:38AM -0400, Máirín Duffy wrote:
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?
As I understand it, the installation experience is like this:
* Darktable shows up in GNOME Software as other apps.
* 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.
* From then on the user receives updates just as with other software.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
9:16 a.m.
On 10 September 2015 at 15:09, Paul W. Frields <stickster(a)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.
9:18 a.m.
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?
~m
9:19 a.m.
On Thu, Sep 10, 2015 at 4:16 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
On 10 September 2015 at 15:09, Paul W. Frields
<stickster(a)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.
Trying to work around our own policies is the worst thing ever.
Really if we want to ship the app we should do it like we always did
and not try to add ugly workarounds like using copr and making things
even complicated.
9:19 a.m.
On 10 September 2015 at 14:45, Máirín Duffy <duffy(a)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..."
9:27 a.m.
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?
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.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
9:30 a.m.
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)
9:31 a.m.
On Thu, 2015-09-10 at 15:16 +0100, Richard Hughes wrote:
On 10 September 2015 at 15:09, Paul W. Frields
<stickster(a)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.
9:37 a.m.
On Sep 10, 2015 10:27 AM, "Paul W. Frields" <stickster(a)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.
9:38 a.m.
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?
~m
11:06 a.m.
On Thu, Sep 10, 2015 at 03:16:08PM +0100, Richard Hughes wrote:
On 10 September 2015 at 15:09, Paul W. Frields
<stickster(a)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".
11:13 a.m.
On Thu, Sep 10, 2015 at 12:06 PM, Debarshi Ray <rishi.is(a)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(a)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
11:16 a.m.
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
Cheers,
Rishi
11:45 a.m.
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.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
11:47 a.m.
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.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
12:41 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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
6:02 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
On Fri, Sep 11, 2015 at 1:41 AM, Michael Catanzaro <mcatanzaro(a)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
6:07 a.m.
New subject: Our sandboxed apps won't really protect users
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(a)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
6:25 a.m.
New subject: Our sandboxed apps won't really protect users
On 11.09.2015 07:41, Michael Catanzaro wrote:
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 a very good point, but imho it's over-stated a bit since the
hypothetical malware apps aren't going to be as widely installed as
non-malware apps.
the desktop should provide an easy and obvious way to install trusted
apps from a curated app repository (xdg-app-store?), which ought to make
it hard for users to install trojaned builds of the popular apps.
sandboxing apps that aren't malware but do read untrusted input is still
very valuable as it limits the damage from potential exploits and *will*
increase security in practice.
10:16 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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
10:18 a.m.
New subject: Our sandboxed apps won't really protect users
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?
I have no clue if accessibility is working yet or not. It will have to
work, otherwise xdg-apps have no future, because accessibility is more
important.
Michael
10:25 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
I think the only way to make the sandbox meaningful is to *require* it for
apps that want to use the other neat features of xdg-apps, which are easier
distribution (app bundles) and stable runtimes.
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.
AFAIK, this is already the plan.
-Elad.
10:29 a.m.
New subject: Our sandboxed apps won't really protect users
On 09/11/2015 11:16 AM, Michael Catanzaro 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. 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.
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.
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.
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.
> 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.
We can't currently use SELinux to lock down apps
because of the way
the desktop is designed, if we move to a sandboxed app environment, we
can take advantage of it to enhance the security of the apps.
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
10:30 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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
10:38 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
On Fri, Sep 11, 2015 at 11:16 AM, Michael Catanzaro
<mcatanzaro(a)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. 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.
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
11:10 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
Hi,
On Fri, 2015-09-11 at 11:30 -0400, Owen Taylor wrote:
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.
Right. Agreed.
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.
Yes, you're right. Populating the software center is a clear goal that
sandboxed xdg-apps allow us to accomplish. So I'm wrong, and they are
worth pursuing, regardless of whether they protect against malicious
apps that are distributed outside the software center.
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.
Yes, I agree, good point.
Well, there is still one problem here: I expect it's actually quite
easy to get malicious software into Fedora, which is a rather huge hole
in this plan. So we do want to make sure that we're incrementally
moving towards having more sandboxed xdg-apps. We might do that by
grandfathering in existing packages, and saying new packages must be
sandboxed, but we don't have to. Eventually the goal should be to
minimize the set of unsandboxed software we distribute to the bare
minimum (probably core apps), but we don't have to achieve that
overnight, or even anytime soon, to get real benefits from the
technology.
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.
We should think harder about how to protect against malicious apps
distributed outside the software center. If Software doesn't allow
installing RPMs anymore, the bad guys are just going to trick users
into using the terminal to do so. It doesn't help that non-malicious
developers instruct users to install their apps using the terminal....
Michael
11:10 a.m.
New subject: Our sandboxed apps won't really protect users
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
11:10 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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
11:40 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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
1:37 p.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
On Fri, Sep 11, 2015 at 9:16 AM, Michael Catanzaro <mcatanzaro(a)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.
--
Chris Murphy
1:37 p.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
On Fri, Sep 11, 2015 at 11:40:52AM -0500, Michael Catanzaro wrote:
Well I've been thoroughly convinced that I was (mostly) wrong, so
no
further disagreement from me!
Without taking any sides, it's nice to hear someone say that on the
internet sometimes. :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:14 p.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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(a)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
10:35 a.m.
New subject: Our sandboxed apps won't really protect users
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 ?
10:38 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
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 http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
11:16 a.m.
New subject: Our sandboxed apps won't really protect users (was: Re: Darktable Copr)
On Sep 14, 2015 10:39 AM, "Paul W. Frields" <stickster(a)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
4:51 a.m.
New subject: Our sandboxed apps won't really protect users
On Mon, 2015-09-14 at 11:35 -0400, Matthias Clasen wrote:
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 ?
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. :/
11:17 a.m.
New subject: xdg-app and a11y (was Re: Our sandboxed apps won't really protect users)
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
7:16 a.m.
New subject: xdg-app and a11y (was Re: Our sandboxed apps won't really protect users)
On Tue, Sep 15, 2015 at 6:17 PM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
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.
Just as a data point, recent OS X versions have a per-application
white list of apps which have access to the a11y APIs while older
versions (<= 10.8) had a global switch, see
http://mizage.com/help/accessibility.html
Rui
3143
days inactive
3151
days old
desktop@lists.fedoraproject.org
59 comments
24 participants
participants (24)
-
Alexander Larsson -
Chris Murphy -
Christian Schaller -
Daniel J Walsh -
Debarshi Ray -
drago01 -
Elad Alfassa -
Eric Griffith -
Josh Boyer -
Kalev Lember -
kendell clark -
Luya Tshimbalanga -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Michael Stahl -
Máirín Duffy -
Owen Taylor -
Paul W. Frields -
Pete Travis -
Richard Hughes -
Richard Turner -
Rui Tiago Cação Matos -
Stephen Gallagher