Re: Fedora development of Snap packages

[Vít Ondruch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Dne 22.6.2016 v 19:19 Jiri Eischmann napsal(a):
> Michael Catanzaro píše v St 22. 06. 2016 v 10:22 -0500:
>> On Wed, 2016-06-22 at 15:43 +0200, Vít Ondruch wrote:
>>> Eric,
>>>
>>> So how about similar article about Flatpack? I'd be interested to
>>> see
>>> the comparison between these two ...
>>>
>>>
>>> Vít
>>
>> FWIW, I saw some blog last week about how they used a debug build of
>> LibreOffice to build the snap, which is what accounted for the huge
>> size.
>
> They managed to get it down to 287 MB. LO for Flatpak is 160 MB + ~150
> MB is the GNOME runtime. But the GNOME runtime can be shared with many
> other apps. So in terms of size, flatpak installations are slightly
> bigger in worst scenarios (you use the runtime just for one app) and
> significantly smaller in real life scenarios.
> But it's just because of the architecture with shared runtimes.
> Otherwise there is no reason for size differences, both package the
> same apps and same dependencies. Both technologies also support
> deduplication, which may have a significant impact on size if you have,
> for instance, installed several versions of the same app. But I assume
> its efficiency is roughly the same.
>
> Jiri
>

Thx for explanation!

V.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXa7toAAoJEAzgnueZF7h8o4cP+gKtfuuZsd8ndOHdvMc/nP6r
MT4OxU5oQXknoO1BCuNskrLvf0qsZaiPgAKD5UnGV5V5tifUoOS2dCbuawGEVaCH
VsIlbj4nUKhD8jErLjtcHT2HoeCgtdLPxXGxtlpW3y/nKNIC1VOOO8ilt8dXq0S3
BjQSOhX0Ab5VrdFTcLH8Sr8iPW04019ZCoxRQ/djg4Tf/jIGwWVW+GZ7UmVvmRFJ
x+U7NB9zbPEFJ1mjpz1s+dhTSkW9WICy8GWR2bGTHN9QtEQfFJqWwDBnPadsNvtu
bFzDvEj/TN84vFqF0EDQS+19/4XOmpKSQvp4xFoLhSEFFNG89CoP5pkvdl7JYHZu
faIb0nKMrb2vi/UYMoPyq5z2QfBmDJMQJLDn/1QsONS15BYMxWV4S1sILtfghXn8
slchNy0EaS+TB/QXo94HAKSikgG9GRGu8tNN8bk0KMSo3ISRfFqJx2ShLBhuY/iB
58p8UXql9g+xGMn0D9pWIPxIWz5RMPjWV4YGRqm1tT0BBrFs100ysDc29BSvUhuo
s6AApXgVOKy/P6Pt50m8e3ex65nRJhd5HEK7j/LhlCz/lAsMdnenUF3aKQDx7TiD
QM+70TLNt+82aoP94CUd1NM+WG9r+/RjH4+PKGl3TiMy5T0NAzl9IJARqwYSewmH
fKxq1eIcy+i8nJJ/mrY+
=wZpD
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Jiri Eischmann]

Michael Catanzaro píše v St 22. 06. 2016 v 10:22 -0500:
> On Wed, 2016-06-22 at 15:43 +0200, Vít Ondruch wrote:
> > Eric,
> > 
> > So how about similar article about Flatpack? I'd be interested to
> > see
> > the comparison between these two ...
> > 
> > 
> > Vít
> 
> FWIW, I saw some blog last week about how they used a debug build of
> LibreOffice to build the snap, which is what accounted for the huge
> size.

They managed to get it down to 287 MB. LO for Flatpak is 160 MB + ~150
MB is the GNOME runtime. But the GNOME runtime can be shared with many
other apps. So in terms of size, flatpak installations are slightly
bigger in worst scenarios (you use the runtime just for one app) and
significantly smaller in real life scenarios.
But it's just because of the architecture with shared runtimes.
Otherwise there is no reason for size differences, both package the
same apps and same dependencies. Both technologies also support
deduplication, which may have a significant impact on size if you have,
for instance, installed several versions of the same app. But I assume
its efficiency is roughly the same.

Jiri

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rob Clark]

On Tue, Jun 14, 2016 at 4:02 PM, Michael Catanzaro  wrote:
> On Tue, 2016-06-14 at 15:40 -0400, Ben Rosser wrote:
>> This is a slight tangent, but by "remove Fedora packages", do you
>> mean
>> actually remove them from the distribution entirely or simply not
>> show the
>> packaged version in e.g. GNOME Software in favor of the upstream
>> Flatpak?
>> The latter makes sense to me, the former seems potentially
>> controversial.
>
> I was thinking remove the Fedora package. What's the point in
> maintaining a secret Fedora package for a graphical app, when we're
> going to be presenting a different version of that app to users? And as
> Josh says, this would also create confusion regarding where to report
> bugs, and also confusion when users have two different sets of bugs
> depending on whether you use a Fedora package or the upstream Flatpak.
> But maybe we will need to keep the Fedora packages to support spins,
> e.g. we probably don't want to start removing packages before KDE grows
> support for Flatpaks in its graphical installer.

one small extra wrinkle, which I didn't notice anyone mention yet:
removal of any package avail on all arch's in favour of 3rd party
flakpak that are only available for x86 is a bit annoying for other
archs ;-)

BR,
-R

> There's no plan to systematically go around removing Fedora packages in
> favor of Flatpaks; rather, we plan to do this on a case-by-case basis
> at the request of upstreams that have developed Flatpaks and want those
> Flatpaks to be available in Fedora. Package maintainers would be
> allowed to dispute the change, again on a case-by-case basis, but I
> don't expect that to happen often. We're also planning to allow third-
> party RPMs to replace Fedora-provided RPMs following the same
> procedure.
>
> Full details at [1], just keep in mind this is a WIP document in the
> preproposal stage; i.e. we were not planning to propose it on this list
> yet.
>
> [1] https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Wed, 2016-06-22 at 15:43 +0200, Vít Ondruch wrote:
> Eric,
> 
> So how about similar article about Flatpack? I'd be interested to see
> the comparison between these two ...
> 
> 
> Vít

FWIW, I saw some blog last week about how they used a debug build of
LibreOffice to build the snap, which is what accounted for the huge
size.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Wed, 2016-06-22 at 15:43 +0200, Vít Ondruch wrote:
> Eric,
> 
> So how about similar article about Flatpack? I'd be interested to see
> the comparison between these two ...
> 
> 
> Vít

FWIW, I saw some blog last week about how they used a debug build of
LibreOffice to build the snap, which is what accounted for the huge
size.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Vít Ondruch]

Dne 14.6.2016 v 21:06 Eric Griffith napsal(a):
>
> I'm testing it out for Phoronix. The copr works correctly, it installs
> fine. Running snapper works fine, once you figure out what the correct
> instructions should be (snapcraft.io 's
> instructions are slightly wrong).
>
> Applications appear to run correctly and integrate fine in the
> Workstation environment.. minus LibreOffice.
>
> File sizes are massive compared to traditional packages. The Document
> Foundation's rpm package for Linux x64 is 229 MBs. A LibreOffice 5.2
> Beta snap that I found clocked in at 1.1 GB.
>

Eric,

So how about similar article about Flatpack? I'd be interested to see
the comparison between these two ...


Vít



> On Jun 14, 2016 14:26, "James Hogarth"  > wrote:
>
> So I was rather surprised by this Softpaedia article today:
>
> 
> http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml
>
> It claims that Canonical state that they have been working with
> Fedora developers to make this the universal packaging format.
>
> The snapcraft.io  site instructions say to
> use a COPR by a Canonical employee who is not a Fedora packager.
>
> Does anyone in marketing or development now what the article is
> referring to and what's going on?
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org 
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Kevin Fenzi]

On Thu, 16 Jun 2016 14:14:29 -0300
"Gerald B. Cox"  wrote:

> On Thu, Jun 16, 2016 at 12:18 PM, Jiri Eischmann
>  wrote:
> 
> >
> > KDE has been interested in Flatpak for over a year. They even have a
> > KDE runtime and a couple of KDE apps packaged:
> > https://community.kde.org/Flatpak  
> 
> 
> That's a good thing...but I noticed that the page you directed me to
> above was just created a few weeks ago, May 30th, 2016.  My point was
> while people may well be working on it, most people don't know
> anything about it

It used to be called xdg-app, so the flatpak name is pretty new. 

> - whereas snappy has been getting alot of press.  Granted, it
> formally was Ubuntu specific - but say what you want about Ubuntu,
> they do a great job on marketing their brand.  Flatpak may well be
> superior and "better positioned" - however, unless people start
> discussing it and marketing it - that won't make a difference and
> we'll have a situation where the vast majority of applications are
> packaged for snappy and not Flatpak.  Is that a bad thing?  I don't
> know - but it is usually the way things end up.  Just an observation.

Well, we are discussing it now. ;) 

kevin


pgpdb_2B9ZAv1.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Fri, 17 Jun 2016 15:05:01 -0400, you wrote:

>I still think we, as a distribution, should not be in the business of
>discouraging downstream packaging in favor of *upstream* provided flatpaks,
>though (which was my original objection to the idea).

Which is better for the user:

1) upstream Flatpak that the user can get support from upstream if
they run into problems

2) Fedora package (either rpm or Flatpak) that upstream won't support,
so if the user runs into problems they are told to talk to Fedora,
which while I certainly appreciate the effort done by packagers they
often aren't familiar with the codebases and can't offer any help?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Ben Rosser]

On Fri, Jun 17, 2016 at 9:58 AM, Matthew Miller 
wrote:

> On Thu, Jun 16, 2016 at 02:24:26PM -0400, Ben Rosser wrote:
> > > I think that once the full sandboxing / portal system is in place,
> > > there _will_ be a tangible reason to prefer Flatpak.
> > Well, assuming that turns out to be the case, should our packaging
> > guidelines eventually become "do not make RPM packages of end-user
> > applications but instead make a downstream flatpak package"? I'd probably
> > have mixed feelings about this, too, and it's not what the Workstation
> > proposal suggests at the moment, either, but it seems to be where we're
> > eventually leading here.
> >
> > Or, we could have tooling to turn a RPM into a flatpak, perhaps (I know
> > there's a script to do this for AppImages), and use this in our build
> > infrastructure?
>
> Yes, is the direction I'm thinking. The Layered Image Build Service we
> have for Docker can automatically rebuild when there are updates to
> component RPMs, and it'd be nice if we could channel Flatpak through
> that. Flatpak does have a little bit of awkwardness, though, since it
> needs to understand nonstandard paths and locations, so it'd probably
> involve rebuilding the RPMs, or at least some kind of crazy rearranging
> of binaries.
>
>
The more I think about it, the more I like the idea of flatpaks generated
from RPMs automatically by our infrastructure. (In part because this means
that if I really want to, I could presumably still get the RPMs themselves
instead. Presumably DNF or other tools could become configurable in this
regard.) Though, if Fedora moves in that direction, it should probably be
as seamless as possible from a user's perspective... e.g. "firefox" should
probably launch Firefox regardless of whether or not I have the RPM or
flatpak installed.

I still think we, as a distribution, should not be in the business of
discouraging downstream packaging in favor of *upstream* provided flatpaks,
though (which was my original objection to the idea).

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Przemek Klosowski]

On 06/16/2016 05:57 PM, Gerald Henriksen wrote:

On Thu, 16 Jun 2016 15:44:11 -0400, Przemek wrote:


I get that, but as I said, RPM can have sandboxing too, and so far it
looks like the main vulnerability vector is unpatched software. Flatpack
wouldn't have helped with heartbleed, and the right remediation for it
was rapid patching---which was hampered by all the bundled SSL libraries
even without many containers in the mix.

I do see the utility of containers, and realize that properly curated
containers can be patched as well as native packages. It's just that I
am concerned that they will diffuse responsibility for patching so much
that effectively curation will fail.

To me though you are talking about an ideal world where everything is
properly packaged into rpms and everybody deals with security issues
promptly.

There is a lot of evidence however that we aren't living in such an
ideal world, and as a result there is a lot of software installed
outside of rpms that rarely gets updated.

How much of this self installed software would get updated when the
next vulnerability is found (or for that matter, how much self
installed software still has old bundled SSL exposing systems)?
The way I see it is the single-distribution model turned out to be too 
difficult to third party software authors, who just couldn't provide 
packages for every distribution in a fragmented marketplace. At the same 
time, the distributions like Fedora don't have the manpower to do the 
packaging work for everyone. Therefore, we the users started loading 
random configure+make/npm/pip/curl|sh stuff.


The container plan promises a solution by offering portable packages, so 
the software authors have to only do the packaging once. That makes 
sense, and will probably work for the authors. In any case, it's got to 
be a better situation than the configure+make world.


My concern is that everyone is focused on production and delivery, but 
not necessarily on maintenance.  For instance, the consumers/end users 
need to be able to assess the vulnerability of their setup and patch 
what's necessary. The single distribution model works well for that: you 
just inspect all the packages you have. In principle, the model of 
multiple container sources is also discoverable, but the responsibility 
for properly packaging, describing and maintaining things is diffused 
among multiple parties.


I think by now the tea leaves can be read: containers are going to be 
with us. I just hope that people would see the need for discipline and 
cooperation so that the resulting containerized systems are as easy to 
maintain as the unified  distributions.


The best case is we'll have an ecosystem of universal portable packages 
updated for every possible environment. The worst case is like the huge 
FTP repositories of abandoned, redundant Visual Basic programs of the 
early '90s. I sure hope for the best.



So while Snap / Flatpak / Docker may mean 50 different copies of a
library need to be fixed, the fact that those packagers (presumably
being as responsible as existing rpm maintainers) actually release new
fixed versions might actually mean systems will be far more secure
than currently.
Exactly! it turns out that making the thing in the first place is the 
easy part; taking care of it during its lifetime is the hard part. 
Reminds me of parenting.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Fri, Jun 17, 2016 at 09:53:05AM -0600, Kevin Fenzi wrote:
> Well, it's strongly discouraged currently: 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages
> it's not at all easy to make work right, so not sure this is the right
> tool for this use. 

Well, the use case given in the old documentation is putting it
somewhere else for disk space reasons. That's really a bad reason
anyway, so without further justification no wonder it withered. Beyond
having better justification, there are other difference here:

* it doesn't need to be _generally_ relocatable, but just to /app

* the complaint about anaconda and yum not understanding it isn't 
  relevant


-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Fri, Jun 17, 2016 at 10:25:13AM -0400, Neal Gompa wrote:
> > Yes, is the direction I'm thinking. The Layered Image Build Service we
> > have for Docker can automatically rebuild when there are updates to
> > component RPMs, and it'd be nice if we could channel Flatpak through
> > that. Flatpak does have a little bit of awkwardness, though, since it
> > needs to understand nonstandard paths and locations, so it'd probably
> > involve rebuilding the RPMs, or at least some kind of crazy rearranging
> > of binaries.
> Is this what relocatable packages are supposed to solve?
> http://www.rpm.org/max-rpm/ch-rpm-reloc.html

Yeah, that might be one way. Not very many packages are made so that
works, though. Maybe we could put more effort into it.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Tue, 2016-06-14 at 14:32 -0500, Michael Catanzaro wrote:
> There's an article on Ars as well. The "working with Fedora
> developers"
> claim is probably a misunderstanding on Softpedia's part; it's not
> true, and I doubt Canonical would have said that.

Just for the record... the Softpedia article doesn't actually say
"Canonical state that they have been working with Fedora developers to
make this the universal packaging format." It does say they've been
"working for some time with developers from various major GNU/Linux
distributions" and that "the Snap package format is working natively on
popular GNU/Linux operating systems like [...] Fedora [...]," so it's
clear why there was confusion, but it doesn't say that they've been
working with Fedora specifically.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Jiri Eischmann]

Alexander Larsson píše v Čt 16. 06. 2016 v 21:11 +0200:
> On Thu, 2016-06-16 at 14:24 -0400, Ben Rosser wrote:
> > On Thu, Jun 16, 2016 at 1:30 PM, Matthew Miller  > ct.org> wrote:
> > > On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:
> > > > ship pip, npm, etc? Where I become uncomfortable, and the
> > > reason I chimed
> > > > in on this thread initially, is with the idea that these new
> > > containerized
> > > > packaging systems are in some way *superior* to traditional
> > > packaging. Or
> > > > at least that's what I read between the lines of the proposal
> > > to allow
> > > > upstreams to ask for their flatpaks or whatever to be shipped
> > > in place of
> > > > RPMs.
> > > 
> > > I think that once the full sandboxing / portal system is in
> > > place,
> > > there _will_ be a tangible reason to prefer Flatpak.
> > > 
> > > 
> > 
> > Well, assuming that turns out to be the case, should our packaging
> > guidelines eventually become "do not make RPM packages of end-user
> > applications but instead make a downstream flatpak package"? I'd
> > probably have mixed feelings about this, too, and it's not what the
> > Workstation proposal suggests at the moment, either, but it seems
> > to be where we're eventually leading here.
> > 
> > Or, we could have tooling to turn a RPM into a flatpak, perhaps (I
> > know there's a script to do this for AppImages), and use this in
> > our build infrastructure?
> 
> For atomic workstation, this is the goal. We even need that, because
> in that setup the OS (/usr) would be a read-only image (based on
> rpms), so we could not install new rpms. Instead we'd take our
> existing rpms and create flatpaks from them.

It's useful for upstream projects, too. For instance, we decided not to
include Java in the upstream LibreOffice flatpak because it's a big
burden to maintain (checking for updates, rebuilding,...) the whole
Java stack because of minor functionality. But then it's not a drop-in
replacement for current official installation files and it will
probably be required eventually.
Then it's probably best to hook the flatpak building to some
distribution, take the bundled components from RPMs and let the distro
maintainers do the maintenance. An update of a distro RPM triggers an
automated rebuild of the flatpak.

Packages are IMHO far from being obsoleted.

Jiri 

signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Przemek Klosowski]

On 06/16/2016 03:09 PM, Alexander Larsson wrote:

On Thu, 2016-06-16 at 14:07 -0400, Przemek Klosowski wrote:

I think that once the full sandboxing / portal system is in place,

there _will_ be a tangible reason to prefer Flatpak.

  Definitely true for third party packages that currenly require
pip/npm/rubygems/(curl | sh  :), but you seem to be saying that
Flatpack will be preferable even when there's an existing  Fedora
package. I think this needs to be well justified: security is a mixed
bag (RPMs can have sandboxing via SELinux and otherwise, and
containers/flatpacks complicate security updates), and other aspects
also seem to have balancing pros and cons.

You seems to think about a different "security" than what flatpak
provides. Say you run a game, packaged by fedora. Its nicely packaged
and reviewed, so you're not running unreviewed, unsigned scripts as
root to install it. This is traditional "unix security".

However, if the game talks to the network and has bug, it can still
easily be attacked and the resulting powned process has full access to
your ssh keys, your email containing private info, your gpg agent, etc,
etc.
I get that, but as I said, RPM can have sandboxing too, and so far it 
looks like the main vulnerability vector is unpatched software. Flatpack 
wouldn't have helped with heartbleed, and the right remediation for it 
was rapid patching---which was hampered by all the bundled SSL libraries 
even without many containers in the mix.


I do see the utility of containers, and realize that properly curated 
containers can be patched as well as native packages. It's just that I 
am concerned that they will diffuse responsibility for patching so much 
that effectively curation will fail.


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Thu, 2016-06-16 at 14:24 -0400, Ben Rosser wrote:
> On Thu, Jun 16, 2016 at 1:30 PM, Matthew Miller 
> .org> wrote:
> > On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:
> > > ship pip, npm, etc? Where I become uncomfortable, and the reason
> > I chimed
> > > in on this thread initially, is with the idea that these new
> > containerized
> > > packaging systems are in some way *superior* to traditional
> > packaging. Or
> > > at least that's what I read between the lines of the proposal to
> > allow
> > > upstreams to ask for their flatpaks or whatever to be shipped in
> > place of
> > > RPMs.
> > 
> > I think that once the full sandboxing / portal system is in place,
> > there _will_ be a tangible reason to prefer Flatpak.
> > 
> > 
> > 
> 
> Well, assuming that turns out to be the case, should our packaging
> guidelines eventually become "do not make RPM packages of end-user
> applications but instead make a downstream flatpak package"? I'd
> probably have mixed feelings about this, too, and it's not what the
> Workstation proposal suggests at the moment, either, but it seems to
> be where we're eventually leading here.
> 
> Or, we could have tooling to turn a RPM into a flatpak, perhaps (I
> know there's a script to do this for AppImages), and use this in our
> build infrastructure?
> 
> 
> 
> 
For atomic workstation, this is the goal. We even need that, because in
that setup the OS (/usr) would be a read-only image (based on rpms), so
we could not install new rpms. Instead we'd take our existing rpms and
create flatpaks from them.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Thu, 2016-06-16 at 14:07 -0400, Przemek Klosowski wrote:
> I think that once the full sandboxing / portal system is in place,
> > there _will_ be a tangible reason to prefer Flatpak.
>  Definitely true for third party packages that currenly require
> pip/npm/rubygems/(curl | sh  :), but you seem to be saying that
> Flatpack will be preferable even when there's an existing  Fedora
> package. I think this needs to be well justified: security is a mixed
> bag (RPMs can have sandboxing via SELinux and otherwise, and
> containers/flatpacks complicate security updates), and other aspects
> also seem to have balancing pros and cons.

You seems to think about a different "security" than what flatpak
provides. Say you run a game, packaged by fedora. Its nicely packaged
and reviewed, so you're not running unreviewed, unsigned scripts as
root to install it. This is traditional "unix security". 

However, if the game talks to the network and has bug, it can still
easily be attacked and the resulting powned process has full access to
your ssh keys, your email containing private info, your gpg agent, etc,
etc.

A sandboxed app such as one using flatpak (and a game could be
sandboxed already using flatpak, as it doesn't need portals) would
never ever be able to access this, so even if powned it would not leak
the users data. (Obviously not counting holes in the sandbox due to
kernel bugs or whatever.)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Wed, 2016-06-15 at 12:46 -0400, Matthew Miller wrote:
> On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > > That's precisely what they are doing on non-Ubuntu distributions,
> > > disabling confinement.
> > Thats is pretty crappy. That means things will keep accidentally
> > being
> > packaged that depends on things not in the ubuntu core. It also
> > means
> > that there is zero sandboxing.
> 
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?

Even with "host filesystem access" the sandboxed app doesn't see /usr
from the host, only things like /home and /opt. So its not generally
possible to pick up host dependencies.

The same is supposed to be true for snappy, because it uses apparmor to
make the snap no be able to access /usr. But that requires the ubuntu
patched apparmor support, so this is disable on all non-ubuntu builds
of snappy.

Also, I'd like to point out that flatpak isn't always open wrt
sandboxing even now. Its possible to grant an app filesystem access,
and many currently do, but its also possible to run e.g. games without
filesystem access, and we do sandbox a lot of other things (pid
namespace, uid namespace, network access, filtered dbus access, seccomp
filtering, etc). Its just not currently realisting to not grant some
kind of filesystem access for apps that read user files until we finish
the work on the file selector portal.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Ben Rosser]

On Thu, Jun 16, 2016 at 1:30 PM, Matthew Miller 
wrote:

> On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:
> > ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
> > in on this thread initially, is with the idea that these new
> containerized
> > packaging systems are in some way *superior* to traditional packaging. Or
> > at least that's what I read between the lines of the proposal to allow
> > upstreams to ask for their flatpaks or whatever to be shipped in place of
> > RPMs.
>
> I think that once the full sandboxing / portal system is in place,
> there _will_ be a tangible reason to prefer Flatpak.
>
>
Well, assuming that turns out to be the case, should our packaging
guidelines eventually become "do not make RPM packages of end-user
applications but instead make a downstream flatpak package"? I'd probably
have mixed feelings about this, too, and it's not what the Workstation
proposal suggests at the moment, either, but it seems to be where we're
eventually leading here.

Or, we could have tooling to turn a RPM into a flatpak, perhaps (I know
there's a script to do this for AppImages), and use this in our build
infrastructure?

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Przemek Klosowski]

On 06/16/2016 01:30 PM, Matthew Miller wrote:

On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:

ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
in on this thread initially, is with the idea that these new containerized
packaging systems are in some way *superior* to traditional packaging. Or
at least that's what I read between the lines of the proposal to allow
upstreams to ask for their flatpaks or whatever to be shipped in place of
RPMs.

I think that once the full sandboxing / portal system is in place,
there _will_ be a tangible reason to prefer Flatpak.
Definitely true for third party packages that currenly require 
pip/npm/rubygems/(curl | sh  :), but you seem to be saying that Flatpack 
will be preferable even when there's an existing  Fedora package. I 
think this needs to be well justified: security is a mixed bag (RPMs can 
have sandboxing via SELinux and otherwise, and containers/flatpacks 
complicate security updates), and other aspects also seem to have 
balancing pros and cons.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Andrew Lutomirski]

On Thu, Jun 16, 2016 at 10:30 AM, Matthew Miller
 wrote:
> On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:
>> ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
>> in on this thread initially, is with the idea that these new containerized
>> packaging systems are in some way *superior* to traditional packaging. Or
>> at least that's what I read between the lines of the proposal to allow
>> upstreams to ask for their flatpaks or whatever to be shipped in place of
>> RPMs.
>
> I think that once the full sandboxing / portal system is in place,
> there _will_ be a tangible reason to prefer Flatpak.

Unless we can get the same sandboxing to work for RPMs, too.  I'd
*love* to be able to:

sudo dnf install inkscape
inkscape

and have it be sandboxed.  If we do s/inkscape/firefox, even better.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote:
> ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
> in on this thread initially, is with the idea that these new containerized
> packaging systems are in some way *superior* to traditional packaging. Or
> at least that's what I read between the lines of the proposal to allow
> upstreams to ask for their flatpaks or whatever to be shipped in place of
> RPMs.

I think that once the full sandboxing / portal system is in place,
there _will_ be a tangible reason to prefer Flatpak.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald B. Cox]

On Thu, Jun 16, 2016 at 2:12 PM, Ben Rosser  wrote:

> In my vision of the future, we'd ship flatpaks and friends as a supplement
> to, but not as a replacement of, RPMs. In fact, we'd go the other way. If
> some GUI application was install-able as a flatpak in Fedora, and there was
> someone interested in maintaining a downstream package, we would allow and
> encourage them to do so.


I would hope that would be the intent.  There have been times when I've
wanted to install software that wasn't in the Fedora or 3rd party
repository only to find that the vendor provides an apt package, not a
rpm.  A snappy or flakpak would be extremely convenient in this instance.
If and when the software would be available in a Fedora or other
repository, I believe that would be preferable.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald B. Cox]

On Thu, Jun 16, 2016 at 12:18 PM, Jiri Eischmann 
wrote:

>
> KDE has been interested in Flatpak for over a year. They even have a
> KDE runtime and a couple of KDE apps packaged:
> https://community.kde.org/Flatpak


That's a good thing...but I noticed that the page you directed me to above
was just created a few weeks ago, May 30th, 2016.  My point was while
people may well be working on it, most people don't know anything about it
- whereas snappy has been getting alot of press.  Granted, it formally was
Ubuntu specific - but say what you want about Ubuntu, they do a great job
on marketing their brand.  Flatpak may well be superior and "better
positioned" - however, unless people start discussing it and marketing it -
that won't make a difference and we'll have a situation where the vast
majority of applications are packaged for snappy and not Flatpak.  Is that
a bad thing?  I don't know - but it is usually the way things end up.  Just
an observation.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Ben Rosser]

On Thu, Jun 16, 2016 at 12:56 AM, Gerald Henriksen 
wrote:

> On Wed, 15 Jun 2016 22:18:00 -0400, you wrote:
>
> >Snaps function very much like how Apple's ecosystem does for software
> >delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
> >clear that the purpose of Snaps are to provide avenues to "encourage"
> >people to lock into the Ubuntu platform.
> >
> >So far, I've seen people gloss over the real crux of the problem,
> >which is that somehow we're trying to create walled gardens, and no
> >one wants to fix that.
>
> No, the problem is that the developers of open source projects and
> languages have viewed the strict rules around packages in a
> distribution as a problem, and have worked around it.
>
> Swift (you know, the hot new language that still isn't in Fedora), Go,
> Python, Node.js, etc. have all created their own "packaging" systems
> to either bypass the traditional Linux distribution or to handle
> running on macOS or Windows that don't have a packaging system.
>
> Combine this with the fact that a lot of the development (most?) is no
> longer happening on Linux for various reasons, and that the dependency
> chain on a lot of software is a packaging nightmare, and you have
> Ubuntu (with Snap), GNOME (with Flatpak), and the server people (with
> Docker) all coming up with simpler ways to try and get stuff packaged
> given the lack of volunteers to even try and get stuff packaged in the
> traditional way.
>
> The current method of packaging rpms in Fedora is not working - there
> are simply too many things that aren't getting packaged - and a
> simpler alternative needs to be found.
> --
>

I do not entirely disagree with you (though others in this thread might).
It's important that we understand that if users want to install software
not packaged in Fedora, they will, using whatever method they can. Whether
that's installing RPMs from some other distro, installing whatever format
is provided by upstream, building it themselves, installing packages from
e.g. PyPI for Python modules, etc. For better or worse, a user is very
rarely going to sit down and learn how to package the thing they're trying
to install for Fedora and try to get it included in our repositories.

So for example, if I need to install a Python package that's not available
through our repositories, I'll install it using pip. (Sometimes, because
I'm a packager, I say to myself "hm, I should package this for Fedora", but
not always). There's nothing wrong with that. *However*, if given the
option, I would always prefer to install the package from our repositories.

So I think that flatpaks [1] are a good thing in that they extend the
amount of software users can (hopefully easily) install on their systems,
because, as you say, there are things that aren't getting packaged due to
various reasons. I completely agree! Making it easier for users to install
software not packaged in Fedora isn't a bad thing-- otherwise, why do we
ship pip, npm, etc? Where I become uncomfortable, and the reason I chimed
in on this thread initially, is with the idea that these new containerized
packaging systems are in some way *superior* to traditional packaging. Or
at least that's what I read between the lines of the proposal to allow
upstreams to ask for their flatpaks or whatever to be shipped in place of
RPMs.

I strongly disagree with this. There is still a lot to be said, I think,
for having as much of the software on your system as possible built and
linked against system-wide libraries.

In my vision of the future, we'd ship flatpaks and friends as a supplement
to, but not as a replacement of, RPMs. In fact, we'd go the other way. If
some GUI application was install-able as a flatpak in Fedora, and there was
someone interested in maintaining a downstream package, we would allow and
encourage them to do so. Now, this is all "maintainer interest
permitting"-- if an upstream flatpak is available and nobody wants to
maintain the downstream package, then that's fine too. The package can be
orphaned and retired and users will still be able to install the software
through the flatpak (which is, obviously, superior to users not being able
to install the software at all!).

But if someone is willing to maintain a traditional package of a piece of
software that also has a flatpak available, I really think we should let
them do so. We're not, as so far as I know, in the habit of telling the
maintainers of leaf Python packages "please retire your package and let
users install it using pip [2]", and I suspect that, too, would be a pretty
controversial thing to do.

Ben Rosser

[1] flatpaks, snaps, etc., or similar technology. When I refer to
"flatpaks", I'm really talking about this type of upstream-provided
container package in general, not the specific GNOME implementation.

[2] Sure, the current difference here is that dnf, etc. can't install
Python packages direct from PyPI, at least at the moment, so this is a

Re: Fedora development of Snap packages

[James Hogarth]

>
> On Tue, Jun 14, 2016 at 4:32 PM, Michael Catanzaro 
> wrote:
>
>> Challenge for the marketing folks: can we get these tech journalism
>> sites writing about Flatpak instead? About GNOME Software's new support
>> for displaying and installing Flatpaks in F24? Otherwise, I see
>> upstreams adopting Snappy and not Flatpak.
>>
>
>

Isn't flatpak in gnome-software pushed back to F25 ?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald B. Cox]

On Tue, Jun 14, 2016 at 4:32 PM, Michael Catanzaro 
wrote:

> Challenge for the marketing folks: can we get these tech journalism
> sites writing about Flatpak instead? About GNOME Software's new support
> for displaying and installing Flatpaks in F24? Otherwise, I see
> upstreams adopting Snappy and not Flatpak.
>

I've seen lots of articles about Snappy and didn't even know that Flatpak
existed.  Granted I don't follow Gnome development and am more interested
in KDE and LxQT - but that said, I'm not particularly interested in Ubuntu
either.  If the idea behind flatpak is to make more packages available, it
ain't going to work if people don't know about it.  Most people will just
choose snappy or flatpak, ,and since both work - just use the snappy
format.  It's like Beta and VHS or more recently HD DVD and Blu-ray.  If
you have a universal format, one will become dominant - and for better or
worse, it's not necessarily about which one is better, it has to do with
marketing.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Gerald Henriksen]

On Wed, 15 Jun 2016 22:18:00 -0400, you wrote:

>Snaps function very much like how Apple's ecosystem does for software
>delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
>clear that the purpose of Snaps are to provide avenues to "encourage"
>people to lock into the Ubuntu platform.
>
>So far, I've seen people gloss over the real crux of the problem,
>which is that somehow we're trying to create walled gardens, and no
>one wants to fix that.

No, the problem is that the developers of open source projects and
languages have viewed the strict rules around packages in a
distribution as a problem, and have worked around it.

Swift (you know, the hot new language that still isn't in Fedora), Go,
Python, Node.js, etc. have all created their own "packaging" systems
to either bypass the traditional Linux distribution or to handle
running on macOS or Windows that don't have a packaging system.

Combine this with the fact that a lot of the development (most?) is no
longer happening on Linux for various reasons, and that the dependency
chain on a lot of software is a packaging nightmare, and you have
Ubuntu (with Snap), GNOME (with Flatpak), and the server people (with
Docker) all coming up with simpler ways to try and get stuff packaged
given the lack of volunteers to even try and get stuff packaged in the
traditional way.

The current method of packaging rpms in Fedora is not working - there
are simply too many things that aren't getting packaged - and a
simpler alternative needs to be found.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Bill Nottingham]

Neal Gompa (ngomp...@gmail.com) said: 
> And frankly, if you're trying to solve delivering software in a
> cross-distro fashion, you're doing it wrong. Take for example how RPMs
> "work": packages are generated with a set of generic dependencies
> based on the symbols of libraries and programs. There is literally no
> reason why I couldn't make a package on CentOS 7 and expect it to work
> on virtually every Linux distribution release from around that time.
> 
> To the best of my knowledge, the only significant breakage is with
> OpenSSL, where Fedora refused to set the same soversion that Debian,
> Mageia, Ubuntu, and other distros chose (1.0.0). This symbol break has
> led to it becoming impossible to ship something built on Fedora to
> work on a wide variety of distributions.
> 
> Much of the way RPM is designed is to *promote* cross-distro (and to
> some extent, cross-OS) packages. The fact that we don't is more of an
> artifact of the past than anything else. It continues to amaze me that
> we've given up on promoting our core technology in such a manner. In
> many, many, many ways, it is technically superior (in terms of
> flexibility and fitness for purpose) to the other alternatives out
> there, but everyone seems to have given up.

I would argue that the fact that very very very few upstreams even try to do
this puts the lie to the idea that RPM is a sufficient technology for this. 
Heck, Fedora doesn't even try to do this across Fedora versions in general
(MASS REBUILD THE WORLD!), and we control all of it.

Even those that do try for 'single' RPM builds accomplish this by
a) bundling the world outside of some really minimal LSB libs (for which
distros will yell at you... see this thread)
b) adding giant hacked shell scripts that includes a bunch of if statements
for distro-specific code (for which distros will yell at you... see this
thread)

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Kevin Kofler]

Michael Catanzaro wrote:
> Background info: In the Workstation working group, we're currently
> planning to allow replacing RPM packages for graphical apps with
> Flatpaks. We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora. I guess we
> could do the same with snaps, if they become sufficiently popular, but
> it'd be quite unfortunate to support two competing desktop
> containerization solutions.

I find this completely unacceptable (no matter whether you end up using 
Flatpak, Snap or whatever other flavor of containerized application format). 
A container is NOT an appropriate replacement for a distribution package.

Containers necessarily bundle at least some libraries, thus coming with all 
the drawbacks of bundled libraries: problems keeping up with security 
updates, wasted space (bandwidth, disk and RAM), etc.

They will also never be supported outside of GNOME Software and MAYBE, if 
you're lucky, some day, Plasma Discover. There are many more ways to install 
applications: Apper, Yumex-DNF, the DNF command line, etc. I strongly doubt 
those will ever support containers in an integrated way. (In fact, I hope 
they won't. I don't want my package manager spammed with things that are 
clearly not packages.)

Even if you use GNOME Software, there are still going to be major 
differences in user experience depending on whether the package is actually 
a Flatpak or an RPM, even if the UI tries to hide it from you. E.g., the 
download time and the disk space requirements will necessarily be 
significantly higher for the Flatpak. There may also be differences in user 
experience due to the use of different libraries (different versions, 
different patches applied, different build-time configuration, etc.). And 
the sandboxing part of the containerization can also negatively affect the 
user experience.

And whether we want to package an application as an RPM should always be a 
function of whether somebody here in Fedora wants to package it, NOT of 
whether upstream wants it packaged. If the license allows us to package the 
software, and if we have people willing to do it, why would we let us get 
terms dictated from upstream that are not part of the license and in fact 
blatantly conflict with it?

I have also been pointed to this link: http://kmkeen.com/maintainers-matter/

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Neal Gompa]

On Wed, Jun 15, 2016 at 9:39 PM, Colin Walters  wrote:
> Hi,
>
> On Tue, Jun 14, 2016, at 09:18 PM, Michael Catanzaro wrote:
>
>> Also, keep in mind that Flatpaks are not the only new type of software
>> we intend to support in Fedora. I know other folks are looking into
>> supporting Docker containers; I believe that's a Server WG initiative?
>
> One of the things that is still odd about Fedora is that people often
> say "Fedora" and most of the time they mean as a desktop OS.
>

Why do you think that is weird? Fedora is a perfectly fine desktop
Linux distribution. I'm wondering what your problem is if you think
that it can't be. Yeah, I get that many of you guys at Red Hat don't
care, but that doesn't mean that the rest of us don't. Besides, for a
lot of people, mentioning "Fedora" and "server" in the same sentence
in some positive manner would get you laughed right out! I personally
like server platforms with fresh software, as I'm a firm believer in
that keeping things fresh is the best way to be secure. Just because
it's an unpopular opinion doesn't make it any less of a valid
approach, though.

> Anyways, so yes we've invested quite a lot in Docker for server containers,
> and more specifically in Kubernetes and OpenShift v3.
>
> See:
>
> https://www.openshift.org/
>
> for lots more, and the effort we spend on Docker and Atomic Host
> is at http://www.projectatomic.io/ and that work lands in Fedora
> as well as CentOS.  Most of the production work honestly is in CentOS,
> but there have been discussions about improving the server/cloud/OpenShift
> state in Fedora as well.
>

Not that I don't like the underlying technologies that you're working
on (I do, and I think rpm-ostree is wicked cool!), but it's pretty
darn close-minded if you think of only one potential avenue for
usefulness. Michael Catanzaro suffers from the same problem, but only
from a different perspective.

If we start off with the assumption that the approaches being done by
Docker, Flatpak, and others is a reasonably sound approach (I could
easily make the argument otherwise, and I have earlier in the thread),
then it's important to pick apart what they are and what they do.

Docker is a platform for distributing container construction scripts
and base images. Much like how ebuilds and ports work, Dockerfiles are
simple instructions to create *something* to use. However, the
artifact it creates is a container filesystem tree, rather than a
package that can be integrated into a system. Nothing about Docker
provides any useful security in and of itself. Band-aids like using
sVirt and whatnot help, but that's not available to everyone, so you
can't assume everyone is using it.

Flatpak is a mechanism for provided self-contained applications
derived from already built artifacts, such as runtime images and
application build artifacts. It's supposed to provide sandboxing and
other things, but none of them are functional. It's also not very
flexible, as it's designed exclusively for graphical applications.

Snap is a mechanism like Flatpak, though it's also designed to support
more use-cases than Flatpak. To some degree, it combines Docker and
Flatpak into a single system. The big problem with Snaps is that
they're effectively dead in the water security-wise on any
distribution that isn't Ubuntu (and *maybe* openSUSE/SLES). Snaps,
unlike Flatpaks, are able to handle *all* kinds of things, from web
apps, to desktop graphical apps, to CLI and TUI apps, and even
services and servers.

Snaps have three big flaws:

1. For maximum usefulness an discovery, they have to be centrally
registered with Canonical, who is the sole publisher. This is further
compounded by the fact that none of the server components are planned
to be open sourced (I asked this morning in #snappy), so there's not
even a snowball's chance of democratizing the platform like there is
with Docker.

2. Snaps are designed for apps that "bundle all the things" and don't
provide an easy way to introspect and manage the state of the snaps
included. There's no information on what a snap is composed of, and
that's a huge security nightmare. The format is highly simplistic and
encourages very fat bundles, which is not good for bandwidth or
storage. Flatpaks are marginally better due to "runtimes" built into
the design.

3. Snaps are expressly designed to integrate tightly with Ubuntu, and
currently even relies on Ubuntu-specific code in various aspects of
the OS (AppArmor, Ubuntu Software, etc.). It even goes so far as
making it possible to compose and manage an operating system using
Ubuntu packages as inputs.

Snaps function very much like how Apple's ecosystem does for software
delivery, and perhaps even Microsoft's UWP ecosystem too. It's very
clear that the purpose of Snaps are to provide avenues to "encourage"
people to lock into the Ubuntu platform.

So far, I've seen people gloss over the real crux of the problem,
which is that somehow we're trying to create 

Re: Fedora development of Snap packages

[Colin Walters]

Hi,

On Tue, Jun 14, 2016, at 09:18 PM, Michael Catanzaro wrote:

> Also, keep in mind that Flatpaks are not the only new type of software
> we intend to support in Fedora. I know other folks are looking into
> supporting Docker containers; I believe that's a Server WG initiative?

One of the things that is still odd about Fedora is that people often
say "Fedora" and most of the time they mean as a desktop OS.

Anyways, so yes we've invested quite a lot in Docker for server containers,
and more specifically in Kubernetes and OpenShift v3.  

See:

https://www.openshift.org/

for lots more, and the effort we spend on Docker and Atomic Host
is at http://www.projectatomic.io/ and that work lands in Fedora
as well as CentOS.  Most of the production work honestly is in CentOS,
but there have been discussions about improving the server/cloud/OpenShift
state in Fedora as well.


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 June 2016 at 22:07, Paul W. Frields  wrote:

> On Wed, Jun 15, 2016 at 09:08:35AM -0700, Adam Williamson wrote:
> > On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> > > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > > > So I was rather surprised by this Softpaedia article today:
> > > >
> http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > > > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > > > It claims that Canonical state that they have been working with
> > > > Fedora developers to make this the universal packaging format.
> > > > The snapcraft.io site instructions say to use a COPR by a Canonical
> > > > employee who is not a Fedora packager.
> > > > Does anyone in marketing or development now what the article is
> > > > referring to and what's going on?
> > >
> > > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > > doesn't use filesystem namespaces like flatpak), how does this work on
> > > fedora? You can't use selinux and apparmour at the same time, so this
> > > shouldn't be able to work, unless they disable the containment feature.
> >
> > Right now, apparently, their install instructions tell you to disable
> > SELinux.
>
> Permissive mode is what they require:
> https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
>
>
>
In terms of security of the system that's effectively the same as disabling.

There's no need to differentiate in this context.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Tue, Jun 14, 2016 at 7:36 PM, Neal Gompa  wrote:

> The container/security thing is nothing specific or special to Flatpak
> and others, in fact it's more theater than anything else anyway, as it
> only works when conditions are "just right" (i.e., Wayland,
> supercharged containerization with SELinux, etc.).

If Flatpak applications silently run without sandboxing, I think it's
a problem. The user is being asked to trust that these applications
offer better security, so they need to do that or they need to be
informed in some user friendly manner.

I'd rather be bugged (spammed, whatever) every time I run a Flatpak
application that is not being sandboxed, than for this to be silently
not using sandboxing. I'd even rather have the application fail to
launch by default, if sandboxing won't occur, possibly with a user
override, even if that override were tedious, i.e. a flag used to
launch the application from command line, although maybe that's
creating too easy of an attack vector.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Dave Love]

Przemek Klosowski  writes:

> It would be nice if there was a 'container snapshot' facility that
> would convert between a native application package from Fedora or
> Debian and a portable container---possibly both ways. Obviously,
> native->container is desirable for portability; the opposite
> conversion is less obviously useful but might be a basis for a
> cross-platform packaging process in the future.

It's obviously not what you're thinking of, but there's Singularity,
under review .

As an example, I haven't managed to port Scilab packaging to EPEL6, but
with singularity I can run the f23 version (or the Debian one) on RHEL6:

  $ scilab -version
  Scilab version "5.5.2.1427793548"
  scilab-5.5.2

The executable is basically a Fedora 23 system image (installed with
yum, and quite large) with a configured entry point, in which you can
run other commands:

  $ singularity exec `which scilab` rpm -q basesystem
  basesystem-11-1.fc23.noarch

I'm not sure about "both ways", but you can operate on the contents as
appropriate.

> In my mind, containers are primarily useful to run arbitrary untrusted
> third party applications, but of course they need  a good enough
> sandbox system for that. I hope such system will emerge from the
> current work.

The above is a different "primarily useful" for some of us in research
computing, where we don't actually want operating system containment.
That's the job of the HPC resource manager, if anything.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Paul W. Frields]

On Wed, Jun 15, 2016 at 09:08:35AM -0700, Adam Williamson wrote:
> On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > > So I was rather surprised by this Softpaedia article today:
> > > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > > It claims that Canonical state that they have been working with
> > > Fedora developers to make this the universal packaging format.
> > > The snapcraft.io site instructions say to use a COPR by a Canonical
> > > employee who is not a Fedora packager.
> > > Does anyone in marketing or development now what the article is
> > > referring to and what's going on?
> > 
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work on
> > fedora? You can't use selinux and apparmour at the same time, so this
> > shouldn't be able to work, unless they disable the containment feature.
> 
> Right now, apparently, their install instructions tell you to disable
> SELinux.

Permissive mode is what they require:
https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

-- 
Paul W. Frieldshttp://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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 12:46:43PM -0400, Matthew Miller wrote:
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?

Or, let me rephrase: I *think* the difference, communication approaches
aside, is: With Flatpak, we're telling developers that they need to
currently package their apps with large holes poked by default because
portals aren't available yet, let alone the corresponding application
changes. With Snappy, developers are encouraged to package as if a
sandboxing framework is in effect, but that on many distros, it won't
be. Correct?

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rob Clark]

On Wed, Jun 15, 2016 at 12:07 AM, Florian Weimer  wrote:
> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>
>> I *strongly* disagree here.  The xdg-app folks seem to be doing a
>> pretty good job with their sandbox.  The kernel attack surface is
>> reduced considerably, as is the attack surface against the user via
>> ptrace and filesystem access.  If Wayland is available (which is
>> should be!) then so is the attack surface against X.
>
>
> What about the direct access to DRI device nodes?  Why isn't this a problem
> that reduces the effectiveness of the sandbox considerably?

I think the theory is only allow access to render-nodes, which can
only access other processes buffers via dma-buf import (ie. other
process had to pass you the file-descriptor, which would be how buffer
sharing w/ wayland compositor works)

Not completely sure off the top of my head what the current state of
things are w/ g-s wayland and use of render nodes vs legacy
everyone-open /dev/dri/card0 and do dri2 auth dance..  but
render-nodes plus dma-buf is the way to isolate various users of gpu
as best as possible.

BR,
-R

> Thanks,
> Florian
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Adam Williamson]

On Wed, 2016-06-15 at 12:46 -0400, Matthew Miller wrote:
> On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > > That's precisely what they are doing on non-Ubuntu distributions,
> > > disabling confinement.
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
> 
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?

It's different in that we're not issuing press releases loudly touting
how great it is. i.e. we're following responsible development
practices: while the product isn't actually done yet, we're talking
about it on blogs and at developer conferences and working to complete
it. While *their* product isn't actually done yet, Canonical is issuing
press releases which beg their readers to infer that a) Snappy is
completely done and b) all distributions have adopted it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:47, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > > That's precisely what they are doing on non-Ubuntu distributions,
> > > disabling confinement.
> > Thats is pretty crappy. That means things will keep accidentally being
> > packaged that depends on things not in the ubuntu core. It also means
> > that there is zero sandboxing.
>
> Can you elaborate on how this is different from Flatpak's
> currently-rather-open sandboxing (as seen elsewhere in this thread)?
>
> --
>

Perhaps because flatpak doesn't tell the user to disable selinux and is not
being actively promoted as the new secure application deployment technology
being embraced by multiple major distributions?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 06:25:17PM +0200, Alexander Larsson wrote:
> > That's precisely what they are doing on non-Ubuntu distributions,
> > disabling confinement.
> Thats is pretty crappy. That means things will keep accidentally being
> packaged that depends on things not in the ubuntu core. It also means
> that there is zero sandboxing.

Can you elaborate on how this is different from Flatpak's
currently-rather-open sandboxing (as seen elsewhere in this thread)?

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Przemek Klosowski]

On 06/15/2016 01:24 AM, Tomasz Torcz wrote:

Well, if a packager wants to maintain it, why not?
>
>As someone who's a bit skeptical about containers as the future of software
>distribution, I'd like to continue getting "traditionally packaged"
>applications from Fedora where possible. I became a Fedora packager as a
>large part because I wanted to expand the pool of such software that was
>available in Fedora, by making it available to other users. It seems like
>that's not a thing we're going to care about as much going forward, which I
>guess is... fine, but I kind of have mixed feelings about the whole thing.
>
>I suspect I am in a minority here, though.

   I hope you aren't, I share your sentiments exactly.
Count me among the sceptics. As Florian pointed out, containers are 
convenient, but opaque: they bypass the technical process that is the 
basis for Fedora's excellence. As such, they are a form of technical 
debt: fine to a degree, but not a primary way to run your household.


It would be nice if there was a 'container snapshot' facility that would 
convert between a native application package from Fedora or Debian and a 
portable container---possibly both ways. Obviously, native->container is 
desirable for portability; the opposite conversion is less obviously 
useful but might be a basis for a cross-platform packaging process in 
the future.


In my mind, containers are primarily useful to run arbitrary untrusted 
third party applications, but of course they need  a good enough sandbox 
system for that. I hope such system will emerge from the current work.



--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:25, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 04:44:27PM +0100, James Hogarth wrote:
> > Considering how this actively negates the security of our distribution
and
> > how this is being promoted in the media, with them pointing to the
> > snapcraft site and the instructions there with COPR looking like it's on
> > approved Fedora infrastructure (for those who don't understand anyone
can
> > COPR and there is no review) I honestly wonder if this is a good case
for
> > pulling a COPR repo...
> > Would FESCO have authority here or is that going to be inadvisable a
road?
>
> There are plenty of things packaged in COPR which don't work with
> SELinux or are otherwise even more horrible. That's okay; it's one of
> the reasons we have COPR in the first place. Some things will
> "incubate" there and hopefully become less horrible (and maybe even
> migrate into the distro proper). Other things might stay terrible
> forever. In this particular case, though, given the note about SELinux
> support being planned, it looks like it's the better of the two
> situations, really.
>
> --

But are those projects issuing press releases and promoting their semi
broken software across the various tech sites?

But you do have a point.

It's going to have to be something that those of us supporting in IRC check
for when someone has issues with their browser or libreoffice I suppose.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Wed, 2016-06-15 at 16:32 +0100, James Hogarth wrote:
> 
> 
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work
> on
> > fedora? You can't use selinux and apparmour at the same time, so
> this
> > shouldn't be able to work, unless they disable the containment
> feature.
> >
> That's precisely what they are doing on non-Ubuntu distributions,
> disabling confinement.

Thats is pretty crappy. That means things will keep accidentally being
packaged that depends on things not in the ubuntu core. It also means
that there is zero sandboxing.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 04:44:27PM +0100, James Hogarth wrote:
> Considering how this actively negates the security of our distribution and
> how this is being promoted in the media, with them pointing to the
> snapcraft site and the instructions there with COPR looking like it's on
> approved Fedora infrastructure (for those who don't understand anyone can
> COPR and there is no review) I honestly wonder if this is a good case for
> pulling a COPR repo...
> Would FESCO have authority here or is that going to be inadvisable a road?

There are plenty of things packaged in COPR which don't work with
SELinux or are otherwise even more horrible. That's okay; it's one of
the reasons we have COPR in the first place. Some things will
"incubate" there and hopefully become less horrible (and maybe even
migrate into the distro proper). Other things might stay terrible
forever. In this particular case, though, given the note about SELinux
support being planned, it looks like it's the better of the two
situations, really.

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 17:12, "Rahul Sundaram"  wrote:
>
>
>
> On Wed, Jun 15, 2016 at 11:45 AM James Hogarth wrote:
>>
>> Considering how this actively negates the security of our distribution
and how this is being promoted in the media, with them pointing to the
snapcraft site and the instructions there with COPR looking like it's on
approved Fedora infrastructure (for those who don't understand anyone can
COPR and there is no review) I honestly wonder if this is a good case for
pulling a COPR repo...
>>
>> Would FESCO have authority here or is that going to be inadvisable a
road?
>
> Extremely inadvisable.   Copr exists in part for experimental packages.
When you enable a copr repo, you are warned that this is not part of the
official infrastructure and you are relying on the packager alone for any
support.   Pulling a COPR repo for anything other than violation of
published guidelines such as legal issues will look political even if you
have legitimate technical concerns about the quality of the software.   Do
you want Canonical to pull the Flatpak PPA because the quality of Flatpak
on Ubuntu isn't perfect?
>
>

If it was being widely advertised via the sponsoring entities PR department
the new secure thing whilst disabling the security in the system and trying
to look officialish then honestly yes I would.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Rahul Sundaram]

On Wed, Jun 15, 2016 at 11:45 AM James Hogarth wrote:

> Considering how this actively negates the security of our distribution and
> how this is being promoted in the media, with them pointing to the
> snapcraft site and the instructions there with COPR looking like it's on
> approved Fedora infrastructure (for those who don't understand anyone can
> COPR and there is no review) I honestly wonder if this is a good case for
> pulling a COPR repo...
>
> Would FESCO have authority here or is that going to be inadvisable a road?
>
Extremely inadvisable.   Copr exists in part for experimental packages.
When you enable a copr repo, you are warned that this is not part of the
official infrastructure and you are relying on the packager alone for any
support.   Pulling a COPR repo for anything other than violation of
published guidelines such as legal issues will look political even if you
have legitimate technical concerns about the quality of the software.   Do
you want Canonical to pull the Flatpak PPA because the quality of Flatpak
on Ubuntu isn't perfect?

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Adam Williamson]

On Wed, 2016-06-15 at 17:08 +0200, Alexander Larsson wrote:
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > So I was rather surprised by this Softpaedia article today:
> > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > It claims that Canonical state that they have been working with
> > Fedora developers to make this the universal packaging format.
> > The snapcraft.io site instructions say to use a COPR by a Canonical
> > employee who is not a Fedora packager.
> > Does anyone in marketing or development now what the article is
> > referring to and what's going on?
> 
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.

Right now, apparently, their install instructions tell you to disable
SELinux.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 16:34, "Matthew Miller"  wrote:
>
> On Wed, Jun 15, 2016 at 05:08:07PM +0200, Alexander Larsson wrote:
> > Snappy fundamentally relies on apparmour to do confinement (i.e. it
> > doesn't use filesystem namespaces like flatpak), how does this work on
> > fedora? You can't use selinux and apparmour at the same time, so this
> > shouldn't be able to work, unless they disable the containment feature.
>
> As I understand it, that's exactly what they do — there's a new
> "--disable-confinement" flag which is used¹. Additionally the COPR
> instructions² ask users to switch SELinux to permissive mode for F24
> (but note that "this restriction will be lifted later).
>
>
> 1.
http://copr-dist-git.fedorainfracloud.org/cgit/zyga/snapcore/snap-confine.git/tree/snap-confine.spec?id=09ccbb9f0537e2f519b18c8d8ef5613f1cabf5cc
> 2. https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

Considering how this actively negates the security of our distribution and
how this is being promoted in the media, with them pointing to the
snapcraft site and the instructions there with COPR looking like it's on
approved Fedora infrastructure (for those who don't understand anyone can
COPR and there is no review) I honestly wonder if this is a good case for
pulling a COPR repo...

Would FESCO have authority here or is that going to be inadvisable a road?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Wed, Jun 15, 2016 at 05:08:07PM +0200, Alexander Larsson wrote:
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.

As I understand it, that's exactly what they do — there's a new
"--disable-confinement" flag which is used¹. Additionally the COPR
instructions² ask users to switch SELinux to permissive mode for F24
(but note that "this restriction will be lifted later).


1. 
http://copr-dist-git.fedorainfracloud.org/cgit/zyga/snapcore/snap-confine.git/tree/snap-confine.spec?id=09ccbb9f0537e2f519b18c8d8ef5613f1cabf5cc
2. https://copr.fedorainfracloud.org/coprs/zyga/snapcore/

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 16:09, "Alexander Larsson"  wrote:
>
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > So I was rather surprised by this Softpaedia article today:
> > http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> > ary-format-for-all-gnu-linux-distributions-505241.shtml
> > It claims that Canonical state that they have been working with
> > Fedora developers to make this the universal packaging format.
> > The snapcraft.io site instructions say to use a COPR by a Canonical
> > employee who is not a Fedora packager.
> > Does anyone in marketing or development now what the article is
> > referring to and what's going on?
>
> Snappy fundamentally relies on apparmour to do confinement (i.e. it
> doesn't use filesystem namespaces like flatpak), how does this work on
> fedora? You can't use selinux and apparmour at the same time, so this
> shouldn't be able to work, unless they disable the containment feature.
>

That's precisely what they are doing on non-Ubuntu distributions, disabling
confinement.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Wed, Jun 15, 2016 at 8:39 AM, Josh Boyer 
wrote:

> On Wed, Jun 15, 2016 at 10:13 AM, Chris Murphy 
> wrote:
> >
> >
> > On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer 
> > wrot:e
> >>
> >> How do you plan on addressing the problem reporting issue?  In your
> >> example, the Inkscape package will still exist in RPM form for other
> >> Editions.  That means there are potentially two versions of Inkscape,
> >> one from upstream and one packaged in Fedora.  How do you ensure
> >> problem reports are routed to the correct issue tracker?
> >
> >
> > Something Flatpak, or any other packaging method, could make easier for
> > developers and users is integrating an in-app bug reporting mechanism.
>
> That is a thing that could be done.
>
> > The packager chooses which (and possibly more than one) bug tracking
> system
> > to use and bakes that into the application in a way that abstracts the
> user
> > from this very long standing mess. So upstream packaged applications
> would
> > behind the scene submit the bug to the upstream preferred bug reporting
> > system; and Fedora packages applications to RHBZ or upstream or both.
>
> One of the issues with this idea is scale.  It requires app developers
> to do this.  Not every app developer will do this.  Which means the
> distributions are still going to have to solve this problem.


The idea is to provide the incentive to opt in. By virtue of creating a
Flatpak packaged application, filling in a few blanks, your app and your
users get bug reporting almost for free. It's like a bug reporting API. A
reference implementation that uses RHBZ or even GNOME's BZ would also
incentivize this quite a bit, not least of which is someone will want to
write a github backend for the thing pretty quickly.

There isn't much to be done about upstreams who don't care about user
feedback, or possess an impressive quantity of hubris necessary to not
recognize how much of a pain it is to track down where to file bugs and
sign up for that bug reporting system - per application. Ha, I mean, there
could be some comedy sketches I could think of to make fun of them. But
that's not a technical solution to the problem.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Wed, 2016-06-15 at 08:24 +0200, Florian Weimer wrote:
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
> > On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  > > wrote:
> > > On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
> > > 
> > > > I *strongly* disagree here.  The xdg-app folks seem to be doing
> > > > a
> > > > pretty good job with their sandbox.  The kernel attack surface
> > > > is
> > > > reduced considerably, as is the attack surface against the user
> > > > via
> > > > ptrace and filesystem access.  If Wayland is available (which
> > > > is
> > > > should be!) then so is the attack surface against X.
> > > 
> > > 
> > > What about the direct access to DRI device nodes?  Why isn't this
> > > a problem
> > > that reduces the effectiveness of the sandbox considerably?
> > 
> > It's certainly a meaningful attack surface.  That being said, if it
> > works well, it should be about as dangerous as Chromium's render
> > sandbox, and the latter seems to work fairly well in practice.  I'm
> > assuming that xdg-app grants access to render nodes, not to the
> > legacy
> > node.
> 
> I'm not sure what kind of sandboxing there is.  I was just able to
> open 
> ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile 
> (both outside the sandbox, obviously).

You can opt-out of parts of the sandbox for flatpak apps, and right now
most apps allow access to the home-directory, because we've not yet
finished the work on portals which will allow mediated access to user
files. That said, simple apps like a game will work fine without
granting them access to the users file.

This means current applications packaged with flatpak is mostly about
distribution, and not so much sandboxing. However, we're working on
fixing this.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Alexander Larsson]

On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> So I was rather surprised by this Softpaedia article today:
> http://news.softpedia.com/news/snap-packages-become-the-universal-bin
> ary-format-for-all-gnu-linux-distributions-505241.shtml
> It claims that Canonical state that they have been working with
> Fedora developers to make this the universal packaging format.
> The snapcraft.io site instructions say to use a COPR by a Canonical
> employee who is not a Fedora packager.
> Does anyone in marketing or development now what the article is
> referring to and what's going on?

Snappy fundamentally relies on apparmour to do confinement (i.e. it
doesn't use filesystem namespaces like flatpak), how does this work on
fedora? You can't use selinux and apparmour at the same time, so this
shouldn't be able to work, unless they disable the containment feature.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Wed, Jun 15, 2016 at 8:22 AM, Matthew Miller 
wrote:

>
>
> I'm also worried about lifecycle issues here. What if some popular
> upstream makes a popular Flatpak, we ditch the RPM packaging, and then
> upstream stops updating it, or does a horrible job - how do we get
> _back_?
>


At the moment the design goal is saying that doesn't matter so it'll keep
on running. There's no arbitrary method of disqualifying a Flatpak package,
e.g. with some kind of versioning method --> Flatpak 2 on Fedora could
support Flatpak 1 and 2 package applications, or it could refuse to run
Flatpak 1.


For that matter, are all Flatpak applications going to be third party?
> I've been assuming that we'll have a way to package software in this
> way *within Fedora*. Having a large application ecosystem is key, and
> honestly, I don't see that as likely without our _own_ effort.
>

Exactly.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Robert Marcano]

On 06/14/2016 09:08 PM, Michael Catanzaro wrote:


Certainly we're not going to come along and try to delete packages over
the maintainers' objections. In general, I expect package maintainers
would be deciding whether or not to make the switch, but yeah: if the
upstream developers request that we switch to their Flatpak, I would
hope that package maintainers would be willing to accommodate upstream.


I wish packagers don't abandon their efforts replacing that for a 
upstream flatpacks. Currently I trust packagers, the Fedora rules 
mandates that all source should be available and buildable, that 
everything is built on a clear trusted environment.


Will I trust flatpacks from everyone?, no. Some will be very careful on 
building things. I don't know if someone is linking with extra things we 
don't know or if they built things on a safe environment, or if their 
machines are already hacked to affect their build.


If someone have the need for a new updated version of an application 
with a flatpack and they trust their build, sure install it. But I will 
be happy to still use the RPM packaged version if I don't need new 
things. I wish flatpacks to be more of a way to distribute applications 
that make easy for developers build only one binary for Linux, but not 
as make them the only way, or for commercial applications what will 
never release source.


Hopefully no upstream developer become annoying requesting RPMs to be 
removed.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Oliver Haessler]

 
> On 15/06/16 02:18, Michael Catanzaro wrote:
> 
> > On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:
> >> I suspect this view originates in a very Gnomeish view of the
> >> world
> >> where upstream and the Fedora packagers are very close but I
> >> wonder
> >> how
> >> well it matches with situations where upstream and distros have a
> >> more
> >> antagonistic relationship...
> >
> > It's designed for third party application developers; packages work
> > great for big coherent projects like GNOME and KDE that all distros
> > package, but they're terrible for an upstream developer trying to
> > distribute one piece of software to users on 20 different distros.
> > By
> > making [specific, approved] upstream Flatpaks accessible in GNOME
> > Software, no longer does upstream have to deal with Fedora
> > packagers
> > saying "you can't bundle this and that" or "your package doesn't
> > build
> > with GCC 74" or "this violates or packaging guidelines," nor worry
> > about downstream patches causing different behavior in different
> > distros. Instead, Fedora just gets out of the way. The thinking is
> > that
> > this will make upstreams like us more... especially since it allows
> > them to control the pace of updates.
> 
> I understand why upstreams want to distribute in this way sure.
> 
> I also understand why we say those things that upstream don't like
> and
> why allowing upstreams to do whatever random nonsense crosses their
> mind
> is potentially a bad idea.
> 
> To be fair flatpaks are not my biggest concern given that, as I
> understand things, they are fairly well isolated/contained both in
> terms
> or how they install and how they are run.
> 
> I have far more worries about third party rpms which can put files
> anyway, run any scriptlets they like at install time, and generally
> interfere with the system as a whole.
> 
> I'm sure we've all encountered third party rpms that make us want to
> throw up because they lumped everything together in some bizarrely
> chosen directory and have 5000 lines of scriptlets that seem to
> represent about 10 years worth of accumulated bodges.
> 
> Just to take an example I just grabbed Google's latest chrome rpm and
> checked it. Among other things it has 1051 lines of scriptlets and,
> for
> some reason, installs a system cron job that will run as root every
> day.

This seems to happen for often with 3rd party rpm. I have seen the same
on the slack rpm as well as the vivaldi browser rpm (they use all the same cron 
job),
which basically checks if the repo file for the tool is under /etc/yum.repos.d
and if it is missing because you deleted it (aka moved it to disabled) it will
be daily recreated. Might be "great" for a non technical user, however if you
administrate several machines and want to have control over the updates to 
apply,
that is really annoying.

> 
> Now sure that is probably a case that would be better suited to a
> flatpak but my point is that it gives an idea of the relative quality
> of
> upstream packaging, and in many ways it's actually probably fairly
> well
> packaged compared to many.
> 
> Upstreams have different goals to us, and less understanding of the
> right ways to do things on a given distro, so they are inclined to
> cargo
> cult fixes based on what some not necessarily well informed person
> tells
> them on a bug report or on whatever blog post google turns up when
> they
> search for a solution to a problem.
> 
> The question here I think is how do we prioritise being fast vs being
> correct, and your argument is that we should sacrifice some
> quality/correctness in favour of speed and allowing upstreams to do
> whatever is most convenient to them.
> 
> Tom
> 
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Josh Boyer]

On Wed, Jun 15, 2016 at 10:13 AM, Chris Murphy  wrote:
>
>
> On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer 
> wrot:e
>>
>> How do you plan on addressing the problem reporting issue?  In your
>> example, the Inkscape package will still exist in RPM form for other
>> Editions.  That means there are potentially two versions of Inkscape,
>> one from upstream and one packaged in Fedora.  How do you ensure
>> problem reports are routed to the correct issue tracker?
>
>
> Something Flatpak, or any other packaging method, could make easier for
> developers and users is integrating an in-app bug reporting mechanism.

That is a thing that could be done.

> The packager chooses which (and possibly more than one) bug tracking system
> to use and bakes that into the application in a way that abstracts the user
> from this very long standing mess. So upstream packaged applications would
> behind the scene submit the bug to the upstream preferred bug reporting
> system; and Fedora packages applications to RHBZ or upstream or both.

One of the issues with this idea is scale.  It requires app developers
to do this.  Not every app developer will do this.  Which means the
distributions are still going to have to solve this problem.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Matthew Miller]

On Tue, Jun 14, 2016 at 03:02:29PM -0500, Michael Catanzaro wrote:
> I was thinking remove the Fedora package. What's the point in
> maintaining a secret Fedora package for a graphical app, when we're
> going to be presenting a different version of that app to users? And as
> Josh says, this would also create confusion regarding where to report
> bugs, and also confusion when users have two different sets of bugs
> depending on whether you use a Fedora package or the upstream Flatpak.

Yeah, I'm really concerned about that particular confusion. I think the
new design for Software makes it reasonably clear at install time. But,
there's an inherent tension between making Flatpak software run
seamlessly and making sure users always know where blame (and credit!)
go for bugs and packaging problems.

I'm also worried about lifecycle issues here. What if some popular
upstream makes a popular Flatpak, we ditch the RPM packaging, and then
upstream stops updating it, or does a horrible job - how do we get
_back_?

Another concern is automated installation. Right now, one can do
kickstart installs for Workstation which pull in all desired apps. One
can even run a local mirror to make this faster and more reliable. But
how will this work if some (arbitrary?) apps need to be pulled from
third parties somewhere?

For that matter, are all Flatpak applications going to be third party?
I've been assuming that we'll have a way to package software in this
way *within Fedora*. Having a large application ecosystem is key, and
honestly, I don't see that as likely without our _own_ effort.

So much to figure out, here!

-- 
Matthew Miller

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Avram Lubkin]

As many others have expressed, third-party RPMs tend to be done very
poorly, Oracle Java is a good bad example. That said, if it's something a
user wants to install on their system, that's their prerogative, but it's
not part of Fedora and shouldn't be. What we could do is make it easier to
install and enable third-party repos, then you actively have to enable them
and supposedly you know what you're doing (or are blindly following
something you found on Google). For me, I use repos from two providers,
Google and RPM Fusion. I think that's pretty common I add the repos in a
script I use for new desktop builds. For Google I cat out a repo file and
for RPM Fusion I pull down their repo RPM. Being able to dnf install a
third party repo would be a cleaner and I wouldn't mind this approach. I
would guess there's no legality concern because it's just adding a repo
file, but that's for the lawyers to decide.

As far as GUI tools for installing and managing software. I never use them
and I think that's common for "power users". That said, I could care less
what they do, but expect I can have the same capabilities on the command
line, and would expect those capibilities to be available through DNF.

On containerization/sandboxing, I see this as useful from a security
perspective, but not for software installation. What I see in the
commercial world with SCL is developers don't even try to make their
software run natively. Instead they pull a ton of libraries/modules into an
SCL environment, package it all in a huge RPM, and then never update the
included libraries. I think it would be more useful to work towards some
sort of automatic sandboxing and decouple that from software installation.

Avram

On Wed, Jun 15, 2016 at 8:55 AM, Michael Catanzaro 
wrote:

> On Wed, 2016-06-15 at 08:57 +0100, Tom Hughes wrote:
> > I have far more worries about third party rpms which can put files
> > anyway, run any scriptlets they like at install time, and generally
> > interfere with the system as a whole.
>
> Yeah, I'm not sure I like this part of the plan either. The goal is to
> make it as easy as possible to package software for Fedora, but I'm
> thinking that anyone who wants to distribute an RPM repo with metadata
> enabled in Fedora ought to be required to follow our packaging
> guidelines. That Chrome RPM seems like a weird case... but if Google's
> RPM sucks, just imagine what other vendors will do. You can horribly
> break the user's system with a bad RPM; there was a recent "dnf
> uninstalls sqlite" bug caused by some third-party RPM that bundles
> sqlite and also Provides it
>
> With Flatpak, it's indeed less of an issue. Your Flatpak might suck,
> but it can't hurt the system.
>
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Chris Murphy]

On Tue, Jun 14, 2016 at 1:41 PM, Josh Boyer 
wrot:e
>
> How do you plan on addressing the problem reporting issue?  In your
> example, the Inkscape package will still exist in RPM form for other
> Editions.  That means there are potentially two versions of Inkscape,
> one from upstream and one packaged in Fedora.  How do you ensure
> problem reports are routed to the correct issue tracker?
>

Something Flatpak, or any other packaging method, could make easier for
developers and users is integrating an in-app bug reporting mechanism.

The packager chooses which (and possibly more than one) bug tracking system
to use and bakes that into the application in a way that abstracts the user
from this very long standing mess. So upstream packaged applications would
behind the scene submit the bug to the upstream preferred bug reporting
system; and Fedora packages applications to RHBZ or upstream or both.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Wed, 2016-06-15 at 08:57 +0100, Tom Hughes wrote:
> I have far more worries about third party rpms which can put files 
> anyway, run any scriptlets they like at install time, and generally 
> interfere with the system as a whole.

Yeah, I'm not sure I like this part of the plan either. The goal is to
make it as easy as possible to package software for Fedora, but I'm
thinking that anyone who wants to distribute an RPM repo with metadata
enabled in Fedora ought to be required to follow our packaging
guidelines. That Chrome RPM seems like a weird case... but if Google's
RPM sucks, just imagine what other vendors will do. You can horribly
break the user's system with a bad RPM; there was a recent "dnf
uninstalls sqlite" bug caused by some third-party RPM that bundles
sqlite and also Provides it

With Flatpak, it's indeed less of an issue. Your Flatpak might suck,
but it can't hurt the system.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Martin Kolman]

On Tue, 2016-06-14 at 20:08 -0500, Michael Catanzaro wrote:
> On Tue, 2016-06-14 at 20:53 +0100, Tom Hughes wrote:
> > 
> > I mean I really hope you're not saying that upstream developers
> > will
> > be 
> > able to start demanding that a third party packager's work is
> > removed 
> > from Fedora!
> Hm... it's not supposed to be an antagonistic process. We were
> expecting it to be more of an "oh, upstream made a Flatpak, that's
> better than an RPM, so let's switch to that now."
This its bit of an edge-case I still think it should be noted - some
mostly GUI apps can also be used as command line utilities. One example
is the above mentioned Inkscape - you can call the inkscape binary and
use it to non-interactively manipulate SVG files. 

Would that still work as expected when calling the Flatpak packaged
Inkscape (eq. wont the sandbox interfere & would the binary be even
accessible in a reasonable way from the command line) ? 

In any case it currently works fine with the RPM packaged Inkscape.

> 
> Certainly we're not going to come along and try to delete packages
> over
> the maintainers' objections. In general, I expect package maintainers
> would be deciding whether or not to make the switch, but yeah: if the
> upstream developers request that we switch to their Flatpak, I would
> hope that package maintainers would be willing to accommodate
> upstream.
> In the unlikely event that upstream gets into conflict with the
> Fedora
> packager over whether to replace the package with a Flatpak (or
> upstream-provided RPM), the current plan was for that to be handled
> on
> a case-by-case basis by FESCo. Hopefully such situations would be
> quite
> rare.
> 
> Michael
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Martin Kolman]

On Wed, 2016-06-15 at 10:54 +0200, Michael Stahl wrote:
> On 15.06.2016 08:24, Florian Weimer wrote:
> > 
> > On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
> > > 
> > > On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  > > om> wrote:
> > > > 
> > > > On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
> > > > 
> > > > > 
> > > > > I *strongly* disagree here.  The xdg-app folks seem to be
> > > > > doing a
> > > > > pretty good job with their sandbox.  The kernel attack
> > > > > surface is
> > > > > reduced considerably, as is the attack surface against the
> > > > > user via
> > > > > ptrace and filesystem access.  If Wayland is available (which
> > > > > is
> > > > > should be!) then so is the attack surface against X.
> > > > 
> > > > What about the direct access to DRI device nodes?  Why isn't
> > > > this a problem
> > > > that reduces the effectiveness of the sandbox considerably?
> > > It's certainly a meaningful attack surface.  That being said, if
> > > it
> > > works well, it should be about as dangerous as Chromium's render
> > > sandbox, and the latter seems to work fairly well in
> > > practice.  I'm
> > > assuming that xdg-app grants access to render nodes, not to the
> > > legacy
> > > node.
> > I'm not sure what kind of sandboxing there is.  I was just able to
> > open 
> > ~/.ssh/id_rsa from a Flatpak application, and change
> > ~/.bash_profile 
> > (both outside the sandbox, obviously).
> > 
> > I couldn't find any relevant device nodes in the file system
> > namespace.
> currently Flatpak doesn't have sandboxing enabled by default, since
> substantial parts of the implementation of interfaces that allow the
> applications to access resources outside the sandbox in a secure way
> ("Portals") are missing.
> 
> the design of the sandbox is documented here:
> 
> https://github.com/flatpak/flatpak/wiki/Sandbox
> 
> article about a sandboxed application (which doesn't need Portals):
> 
> https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-
> desktop-app/
I'll just note that making proper portals from a sandboxed environment,
so that they are both secure & don't hinder application functionality.

I've hit this in a negative way on an Ubuntu Touch running tablet -
they also use sandboxing for apps there, but apparently the open-file
portal can only handle a single file at a time. This basically breaks
any app that needs to work with many files at once - for example
viewing images from a uSD card you just inserted in an image viewer
application - you would have to open the images one at a time...

I'm sure this is something Flatpack can handle in a better way. :)
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Stahl]

On 15.06.2016 08:24, Florian Weimer wrote:
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
>> On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  wrote:
>>> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>>>
 I *strongly* disagree here.  The xdg-app folks seem to be doing a
 pretty good job with their sandbox.  The kernel attack surface is
 reduced considerably, as is the attack surface against the user via
 ptrace and filesystem access.  If Wayland is available (which is
 should be!) then so is the attack surface against X.
>>>
>>>
>>> What about the direct access to DRI device nodes?  Why isn't this a problem
>>> that reduces the effectiveness of the sandbox considerably?
>>
>> It's certainly a meaningful attack surface.  That being said, if it
>> works well, it should be about as dangerous as Chromium's render
>> sandbox, and the latter seems to work fairly well in practice.  I'm
>> assuming that xdg-app grants access to render nodes, not to the legacy
>> node.
> 
> I'm not sure what kind of sandboxing there is.  I was just able to open 
> ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile 
> (both outside the sandbox, obviously).
> 
> I couldn't find any relevant device nodes in the file system namespace.

currently Flatpak doesn't have sandboxing enabled by default, since
substantial parts of the implementation of interfaces that allow the
applications to access resources outside the sandbox in a secure way
("Portals") are missing.

the design of the sandbox is documented here:

https://github.com/flatpak/flatpak/wiki/Sandbox

article about a sandboxed application (which doesn't need Portals):

https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Tom Hughes]

On 15/06/16 02:18, Michael Catanzaro wrote:


On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:

I suspect this view originates in a very Gnomeish view of the world
where upstream and the Fedora packagers are very close but I wonder
how
well it matches with situations where upstream and distros have a
more
antagonistic relationship...


It's designed for third party application developers; packages work
great for big coherent projects like GNOME and KDE that all distros
package, but they're terrible for an upstream developer trying to
distribute one piece of software to users on 20 different distros. By
making [specific, approved] upstream Flatpaks accessible in GNOME
Software, no longer does upstream have to deal with Fedora packagers
saying "you can't bundle this and that" or "your package doesn't build
with GCC 74" or "this violates or packaging guidelines," nor worry
about downstream patches causing different behavior in different
distros. Instead, Fedora just gets out of the way. The thinking is that
this will make upstreams like us more... especially since it allows
them to control the pace of updates.


I understand why upstreams want to distribute in this way sure.

I also understand why we say those things that upstream don't like and 
why allowing upstreams to do whatever random nonsense crosses their mind 
is potentially a bad idea.


To be fair flatpaks are not my biggest concern given that, as I 
understand things, they are fairly well isolated/contained both in terms 
or how they install and how they are run.


I have far more worries about third party rpms which can put files 
anyway, run any scriptlets they like at install time, and generally 
interfere with the system as a whole.


I'm sure we've all encountered third party rpms that make us want to 
throw up because they lumped everything together in some bizarrely 
chosen directory and have 5000 lines of scriptlets that seem to 
represent about 10 years worth of accumulated bodges.


Just to take an example I just grabbed Google's latest chrome rpm and 
checked it. Among other things it has 1051 lines of scriptlets and, for 
some reason, installs a system cron job that will run as root every day.


Now sure that is probably a case that would be better suited to a 
flatpak but my point is that it gives an idea of the relative quality of 
upstream packaging, and in many ways it's actually probably fairly well 
packaged compared to many.


Upstreams have different goals to us, and less understanding of the 
right ways to do things on a given distro, so they are inclined to cargo 
cult fixes based on what some not necessarily well informed person tells 
them on a bug report or on whatever blog post google turns up when they 
search for a solution to a problem.


The question here I think is how do we prioritise being fast vs being 
correct, and your argument is that we should sacrifice some 
quality/correctness in favour of speed and allowing upstreams to do 
whatever is most convenient to them.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[James Hogarth]

On 15 Jun 2016 02:19, "Michael Catanzaro"  wrote:
>
> Hi,
>
> You're right, we hadn't yet planned for how to handle spins (at least
> I'm unaware of any such plans). Don't worry, nobody's going to start
> removing packages if that means making apps inaccessible to folks not
> using Workstation. Some compatibility story is clearly needed
> beforehand. Igor suggested that dnf could transparently switch to
> installing a Flatpak, for instance.
>
> Also, keep in mind that Flatpaks are not the only new type of software
> we intend to support in Fedora. I know other folks are looking into
> supporting Docker containers; I believe that's a Server WG initiative?
> This is why all our packages just moved under the rpms namespace in
> Fedora git.
>
> On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:
> > I suspect this view originates in a very Gnomeish view of the world
> > where upstream and the Fedora packagers are very close but I wonder
> > how
> > well it matches with situations where upstream and distros have a
> > more
> > antagonistic relationship...
>
> It's designed for third party application developers; packages work
> great for big coherent projects like GNOME and KDE that all distros
> package, but they're terrible for an upstream developer trying to
> distribute one piece of software to users on 20 different distros. By
> making [specific, approved] upstream Flatpaks accessible in GNOME
> Software, no longer does upstream have to deal with Fedora packagers
> saying "you can't bundle this and that" or "your package doesn't build
> with GCC 74" or "this violates or packaging guidelines," nor worry
> about downstream patches causing different behavior in different
> distros. Instead, Fedora just gets out of the way. The thinking is that
> this will make upstreams like us more... especially since it allows
> them to control the pace of updates.
>

Some upstreams are rather poor at tracking their third party libraries and
providing timely security updates.

One of the things our process ensures with the very strong preference to
unbundling is that our users get, for example, openssl fixes regardless of
how long an upstream takes.

On the flip side this will make things easier for companies like GOG to
package, support and distribute software purchased.

If we allow this to bypass our packaging guidelines why even have them for
our existing packagers?

Please don't forget about automated builds via kickstart and CM
technologies like ansible in the desire to push this out.

This sounds like it ultimately could be a lengthy conversation, similar to
the SCL one that stalled.

You might want to start on the FPC ticket and discussions sooner rather
than later if you want to target either F25 or F26 (ie any supported
release in the next 12 months).
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Andrew Lutomirski]

On Jun 14, 2016 11:24 PM, "Florian Weimer"  wrote:
>
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
>>
>> On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer 
wrote:
>>>
>>> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>>>
 I *strongly* disagree here.  The xdg-app folks seem to be doing a
 pretty good job with their sandbox.  The kernel attack surface is
 reduced considerably, as is the attack surface against the user via
 ptrace and filesystem access.  If Wayland is available (which is
 should be!) then so is the attack surface against X.
>>>
>>>
>>>
>>> What about the direct access to DRI device nodes?  Why isn't this a
problem
>>> that reduces the effectiveness of the sandbox considerably?
>>
>>
>> It's certainly a meaningful attack surface.  That being said, if it
>> works well, it should be about as dangerous as Chromium's render
>> sandbox, and the latter seems to work fairly well in practice.  I'm
>> assuming that xdg-app grants access to render nodes, not to the legacy
>> node.
>
>
> I'm not sure what kind of sandboxing there is.  I was just able to open
~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile (both
outside the sandbox, obviously).
>
> I couldn't find any relevant device nodes in the file system namespace.

Hmm.  Maybe the current Flatpak doesn't have the xdg-app sandbox enabled.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Florian Weimer]

On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:

On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  wrote:

On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:


I *strongly* disagree here.  The xdg-app folks seem to be doing a
pretty good job with their sandbox.  The kernel attack surface is
reduced considerably, as is the attack surface against the user via
ptrace and filesystem access.  If Wayland is available (which is
should be!) then so is the attack surface against X.



What about the direct access to DRI device nodes?  Why isn't this a problem
that reduces the effectiveness of the sandbox considerably?


It's certainly a meaningful attack surface.  That being said, if it
works well, it should be about as dangerous as Chromium's render
sandbox, and the latter seems to work fairly well in practice.  I'm
assuming that xdg-app grants access to render nodes, not to the legacy
node.


I'm not sure what kind of sandboxing there is.  I was just able to open 
~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile 
(both outside the sandbox, obviously).


I couldn't find any relevant device nodes in the file system namespace.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Florian Weimer]

On 06/15/2016 03:04 AM, Michael Catanzaro wrote:

In the specific case where upstream decides to ship a Flatpak and wants
to distribute that Flatpak in Fedora, then it seems advantageous to
make that available in Fedora rather than our RPMs, so you get updates
from upstream, exactly the way upstream intends, on upstream's
schedule, that run the same on every distro, without conflicting with
Fedora packages.


But those would just be third-party packages, like we have them today. 
We won't know what's in them, and we won't be able to update them, 
diagnose and fix bugs, or integrate them with the rest of the system 
because we have zero control over them.


And if Fedora doesn't rebuild from source, we won't know if it is 
possible to do so with the bits upstream provides.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Tomasz Torcz]

On Tue, Jun 14, 2016 at 04:45:25PM -0400, Ben Rosser wrote:
> > I was thinking remove the Fedora package. What's the point in
> > maintaining a secret Fedora package for a graphical app, when we're
> > going to be presenting a different version of that app to users?
> 
> 
> Well, if a packager wants to maintain it, why not?
> 
> As someone who's a bit skeptical about containers as the future of software
> distribution, I'd like to continue getting "traditionally packaged"
> applications from Fedora where possible. I became a Fedora packager as a
> large part because I wanted to expand the pool of such software that was
> available in Fedora, by making it available to other users. It seems like
> that's not a thing we're going to care about as much going forward, which I
> guess is... fine, but I kind of have mixed feelings about the whole thing.
> 
> I suspect I am in a minority here, though.

  I hope you aren't, I share your sentiments exactly.

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Andrew Lutomirski]

On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer  wrote:
> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>
>> I *strongly* disagree here.  The xdg-app folks seem to be doing a
>> pretty good job with their sandbox.  The kernel attack surface is
>> reduced considerably, as is the attack surface against the user via
>> ptrace and filesystem access.  If Wayland is available (which is
>> should be!) then so is the attack surface against X.
>
>
> What about the direct access to DRI device nodes?  Why isn't this a problem
> that reduces the effectiveness of the sandbox considerably?

It's certainly a meaningful attack surface.  That being said, if it
works well, it should be about as dangerous as Chromium's render
sandbox, and the latter seems to work fairly well in practice.  I'm
assuming that xdg-app grants access to render nodes, not to the legacy
node.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Florian Weimer]

On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:


I *strongly* disagree here.  The xdg-app folks seem to be doing a
pretty good job with their sandbox.  The kernel attack surface is
reduced considerably, as is the attack surface against the user via
ptrace and filesystem access.  If Wayland is available (which is
should be!) then so is the attack surface against X.


What about the direct access to DRI device nodes?  Why isn't this a 
problem that reduces the effectiveness of the sandbox considerably?


Thanks,
Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Andrew Lutomirski]

On Tue, Jun 14, 2016 at 6:36 PM, Neal Gompa  wrote:
>
> On Tue, Jun 14, 2016 at 9:04 PM, Michael Catanzaro  
> wrote:
> > On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote:
> >> Well, if a packager wants to maintain it, why not?
> >>
> >> As someone who's a bit skeptical about containers as the future of
> >> software
> >> distribution, I'd like to continue getting "traditionally packaged"
> >> applications from Fedora where possible. I became a Fedora packager
> >> as a
> >> large part because I wanted to expand the pool of such software that
> >> was
> >> available in Fedora, by making it available to other users. It seems
> >> like
> >> that's not a thing we're going to care about as much going forward,
> >> which I
> >> guess is... fine, but I kind of have mixed feelings about the whole
> >> thing.
> >>
> >> I suspect I am in a minority here, though.
> >
> > No, we'll still need RPM packages for lots and lots and lots of
> > applications. They're not going away.
> >
> > In the specific case where upstream decides to ship a Flatpak and wants
> > to distribute that Flatpak in Fedora, then it seems advantageous to
> > make that available in Fedora rather than our RPMs, so you get updates
> > from upstream, exactly the way upstream intends, on upstream's
> > schedule, that run the same on every distro, without conflicting with
> > Fedora packages. There's a huge technical advantage to that. But most
> > upstreams are not going to adopt this technology; it's just an option
> > to make distributing your application easier. Packagers are still
> > needed to package stuff that's not yet available on Fedora, same as
> > always.
>
> That's a weird position to take. The main selling point of Flatpaks is
> that they operate fully confined in the user's session space, separate
> from the rest of the system. I find it extremely hard to believe that
> we can't make these things coexist safely. In fact, there may even be
> advantages to having a Flatpak and a system version installed in
> parallel (especially for those who'd like to do certain things in a
> confined environment and other things in the regular one).
>
> If you're saying that the GNOME people can't handle this use case,
> then that's a huge problem. I expect this to be the most common one by
> far.
>
> On top of that, what you're suggesting implies that the work we all do
> as Fedora packagers is without value. We work very hard to provide a
> neatly integrated system that provides maximum functionality in a
> secure manner.
>
> To a certain extent, I also fundamentally disagree with the approach
> of modularity via the means of Docker containers and whatnot. I don't
> even like Flatpaks and Snaps and whatever other thing you want to come
> up with. At the end of the day, none of these things are solving the
> problem you are attempting to solve, and may introduce their own
> issues.
>
> Both Windows and macOS have a lot of security issues stemming from the
> lack of easy introspection of the state of the system due to the
> nature of how software delivery is done for these platforms. Docker,
> Flatpak, and Snaps all introduce this problem to the Linux platform,
> and make it far easier for Linux systems to become permanently
> vulnerable.
>
> The container/security thing is nothing specific or special to Flatpak
> and others, in fact it's more theater than anything else anyway, as it
> only works when conditions are "just right" (i.e., Wayland,
> supercharged containerization with SELinux, etc.).

I *strongly* disagree here.  The xdg-app folks seem to be doing a
pretty good job with their sandbox.  The kernel attack surface is
reduced considerably, as is the attack surface against the user via
ptrace and filesystem access.  If Wayland is available (which is
should be!) then so is the attack surface against X.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Neal Gompa]

On Tue, Jun 14, 2016 at 9:04 PM, Michael Catanzaro  wrote:
> On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote:
>> Well, if a packager wants to maintain it, why not?
>>
>> As someone who's a bit skeptical about containers as the future of
>> software
>> distribution, I'd like to continue getting "traditionally packaged"
>> applications from Fedora where possible. I became a Fedora packager
>> as a
>> large part because I wanted to expand the pool of such software that
>> was
>> available in Fedora, by making it available to other users. It seems
>> like
>> that's not a thing we're going to care about as much going forward,
>> which I
>> guess is... fine, but I kind of have mixed feelings about the whole
>> thing.
>>
>> I suspect I am in a minority here, though.
>
> No, we'll still need RPM packages for lots and lots and lots of
> applications. They're not going away.
>
> In the specific case where upstream decides to ship a Flatpak and wants
> to distribute that Flatpak in Fedora, then it seems advantageous to
> make that available in Fedora rather than our RPMs, so you get updates
> from upstream, exactly the way upstream intends, on upstream's
> schedule, that run the same on every distro, without conflicting with
> Fedora packages. There's a huge technical advantage to that. But most
> upstreams are not going to adopt this technology; it's just an option
> to make distributing your application easier. Packagers are still
> needed to package stuff that's not yet available on Fedora, same as
> always.

That's a weird position to take. The main selling point of Flatpaks is
that they operate fully confined in the user's session space, separate
from the rest of the system. I find it extremely hard to believe that
we can't make these things coexist safely. In fact, there may even be
advantages to having a Flatpak and a system version installed in
parallel (especially for those who'd like to do certain things in a
confined environment and other things in the regular one).

If you're saying that the GNOME people can't handle this use case,
then that's a huge problem. I expect this to be the most common one by
far.

On top of that, what you're suggesting implies that the work we all do
as Fedora packagers is without value. We work very hard to provide a
neatly integrated system that provides maximum functionality in a
secure manner.

To a certain extent, I also fundamentally disagree with the approach
of modularity via the means of Docker containers and whatnot. I don't
even like Flatpaks and Snaps and whatever other thing you want to come
up with. At the end of the day, none of these things are solving the
problem you are attempting to solve, and may introduce their own
issues.

Both Windows and macOS have a lot of security issues stemming from the
lack of easy introspection of the state of the system due to the
nature of how software delivery is done for these platforms. Docker,
Flatpak, and Snaps all introduce this problem to the Linux platform,
and make it far easier for Linux systems to become permanently
vulnerable.

The container/security thing is nothing specific or special to Flatpak
and others, in fact it's more theater than anything else anyway, as it
only works when conditions are "just right" (i.e., Wayland,
supercharged containerization with SELinux, etc.).

And frankly, if you're trying to solve delivering software in a
cross-distro fashion, you're doing it wrong. Take for example how RPMs
"work": packages are generated with a set of generic dependencies
based on the symbols of libraries and programs. There is literally no
reason why I couldn't make a package on CentOS 7 and expect it to work
on virtually every Linux distribution release from around that time.

To the best of my knowledge, the only significant breakage is with
OpenSSL, where Fedora refused to set the same soversion that Debian,
Mageia, Ubuntu, and other distros chose (1.0.0). This symbol break has
led to it becoming impossible to ship something built on Fedora to
work on a wide variety of distributions.

Much of the way RPM is designed is to *promote* cross-distro (and to
some extent, cross-OS) packages. The fact that we don't is more of an
artifact of the past than anything else. It continues to amaze me that
we've given up on promoting our core technology in such a manner. In
many, many, many ways, it is technically superior (in terms of
flexibility and fitness for purpose) to the other alternatives out
there, but everyone seems to have given up.

It's depressing...

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

Hi,

You're right, we hadn't yet planned for how to handle spins (at least
I'm unaware of any such plans). Don't worry, nobody's going to start
removing packages if that means making apps inaccessible to folks not
using Workstation. Some compatibility story is clearly needed
beforehand. Igor suggested that dnf could transparently switch to
installing a Flatpak, for instance.

Also, keep in mind that Flatpaks are not the only new type of software
we intend to support in Fedora. I know other folks are looking into
supporting Docker containers; I believe that's a Server WG initiative?
This is why all our packages just moved under the rpms namespace in
Fedora git.

On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote:
> I suspect this view originates in a very Gnomeish view of the world 
> where upstream and the Fedora packagers are very close but I wonder
> how 
> well it matches with situations where upstream and distros have a
> more 
> antagonistic relationship...

It's designed for third party application developers; packages work
great for big coherent projects like GNOME and KDE that all distros
package, but they're terrible for an upstream developer trying to
distribute one piece of software to users on 20 different distros. By
making [specific, approved] upstream Flatpaks accessible in GNOME
Software, no longer does upstream have to deal with Fedora packagers
saying "you can't bundle this and that" or "your package doesn't build
with GCC 74" or "this violates or packaging guidelines," nor worry
about downstream patches causing different behavior in different
distros. Instead, Fedora just gets out of the way. The thinking is that
this will make upstreams like us more... especially since it allows
them to control the pace of updates.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote:
> Well, if a packager wants to maintain it, why not?
> 
> As someone who's a bit skeptical about containers as the future of
> software
> distribution, I'd like to continue getting "traditionally packaged"
> applications from Fedora where possible. I became a Fedora packager
> as a
> large part because I wanted to expand the pool of such software that
> was
> available in Fedora, by making it available to other users. It seems
> like
> that's not a thing we're going to care about as much going forward,
> which I
> guess is... fine, but I kind of have mixed feelings about the whole
> thing.
> 
> I suspect I am in a minority here, though.

No, we'll still need RPM packages for lots and lots and lots of
applications. They're not going away.

In the specific case where upstream decides to ship a Flatpak and wants
to distribute that Flatpak in Fedora, then it seems advantageous to
make that available in Fedora rather than our RPMs, so you get updates
from upstream, exactly the way upstream intends, on upstream's
schedule, that run the same on every distro, without conflicting with
Fedora packages. There's a huge technical advantage to that. But most
upstreams are not going to adopt this technology; it's just an option
to make distributing your application easier. Packagers are still
needed to package stuff that's not yet available on Fedora, same as
always.

As for whether we should start discussing this... seems it's happening.
:)

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Tue, 2016-06-14 at 20:53 +0100, Tom Hughes wrote:
> I mean I really hope you're not saying that upstream developers will
> be 
> able to start demanding that a third party packager's work is
> removed 
> from Fedora!

Hm... it's not supposed to be an antagonistic process. We were
expecting it to be more of an "oh, upstream made a Flatpak, that's
better than an RPM, so let's switch to that now."

Certainly we're not going to come along and try to delete packages over
the maintainers' objections. In general, I expect package maintainers
would be deciding whether or not to make the switch, but yeah: if the
upstream developers request that we switch to their Flatpak, I would
hope that package maintainers would be willing to accommodate upstream.
In the unlikely event that upstream gets into conflict with the Fedora
packager over whether to replace the package with a Flatpak (or
upstream-provided RPM), the current plan was for that to be handled on
a case-by-case basis by FESCo. Hopefully such situations would be quite
rare.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Tom Hughes]

On 14/06/16 21:02, Michael Catanzaro wrote:


I was thinking remove the Fedora package. What's the point in
maintaining a secret Fedora package for a graphical app, when we're
going to be presenting a different version of that app to users? And as
Josh says, this would also create confusion regarding where to report
bugs, and also confusion when users have two different sets of bugs
depending on whether you use a Fedora package or the upstream Flatpak.
But maybe we will need to keep the Fedora packages to support spins,
e.g. we probably don't want to start removing packages before KDE grows
support for Flatpaks in its graphical installer.


And what about people that just use dnf! Not everybody that uses Fedora 
as a workstation actually uses "Fedora Workstation" you know. In fact I 
wouldn't mind betting a majority of people on this list use Fedora on 
their deskop without buying into the "Fedora Workstation" stuff and 
using a graphical package manager.



There's no plan to systematically go around removing Fedora packages in
favor of Flatpaks; rather, we plan to do this on a case-by-case basis
at the request of upstreams that have developed Flatpaks and want those
Flatpaks to be available in Fedora. Package maintainers would be
allowed to dispute the change, again on a case-by-case basis, but I
don't expect that to happen often. We're also planning to allow third-
party RPMs to replace Fedora-provided RPMs following the same
procedure.


I suspect this view originates in a very Gnomeish view of the world 
where upstream and the Fedora packagers are very close but I wonder how 
well it matches with situations where upstream and distros have a more 
antagonistic relationship...



Full details at [1], just keep in mind this is a WIP document in the
preproposal stage; i.e. we were not planning to propose it on this list
yet.


I'm not surprised given it seems to be quite half baked...

Clearly it's entirely aimed at Workstation users yet if allowed it would 
impact the distribution as a whole on a large scale with no apparent 
plan as to how to resolve that contradiction.


If graphical applications all disappear from the core repositories into 
upstream managed flatpak things that are only visible through Gnome 
Software then how are non-Workstation users supposed to access them?


Third party rpm repositories don't seem that well thought out either 
what with vague "they should try and follow our guidelines" but 
presumably no way of policing that given that I assume all this will 
bypass the package review process?


Equally if each package is supposed to have it's own repository I wonder 
if any thought has been given to how well dnf scales to hundreds or 
thousands of repositories?


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Ben Rosser]

On Tue, Jun 14, 2016 at 4:02 PM, Michael Catanzaro 
wrote:

> On Tue, 2016-06-14 at 15:40 -0400, Ben Rosser wrote:
> > This is a slight tangent, but by "remove Fedora packages", do you
> > mean
> > actually remove them from the distribution entirely or simply not
> > show the
> > packaged version in e.g. GNOME Software in favor of the upstream
> > Flatpak?
> > The latter makes sense to me, the former seems potentially
> > controversial.
>
> I was thinking remove the Fedora package. What's the point in
> maintaining a secret Fedora package for a graphical app, when we're
> going to be presenting a different version of that app to users?


Well, if a packager wants to maintain it, why not?

As someone who's a bit skeptical about containers as the future of software
distribution, I'd like to continue getting "traditionally packaged"
applications from Fedora where possible. I became a Fedora packager as a
large part because I wanted to expand the pool of such software that was
available in Fedora, by making it available to other users. It seems like
that's not a thing we're going to care about as much going forward, which I
guess is... fine, but I kind of have mixed feelings about the whole thing.

I suspect I am in a minority here, though.


> And as
> Josh says, this would also create confusion regarding where to report
> bugs, and also confusion when users have two different sets of bugs
> depending on whether you use a Fedora package or the upstream Flatpak.
>

That is a valid concern, and not something I'd have an immediate solution
for.


> There's no plan to systematically go around removing Fedora packages in
> favor of Flatpaks; rather, we plan to do this on a case-by-case basis
> at the request of upstreams that have developed Flatpaks and want those
> Flatpaks to be available in Fedora. Package maintainers would be
> allowed to dispute the change, again on a case-by-case basis, but I
> don't expect that to happen often. We're also planning to allow third-
> party RPMs to replace Fedora-provided RPMs following the same
> procedure.
>


> Full details at [1], just keep in mind this is a WIP document in the
> preproposal stage; i.e. we were not planning to propose it on this list
> yet.
>
> [1]
> https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>

Sure, I understand that the recent press coverage of Ubuntu's solution in
this space (Snap) has brought some of this stuff forward preemptively. My
gut reaction, though, to *replacing* Fedora packages with upstream-provided
containers, though, is, "...thanks, I'll pass". My gut reaction may be
entirely irrelevant in the larger scheme of things, but maybe it would be a
good idea to at least start discussing this even if a formal proposal is a
ways off yet? Though this is a tangent, as I said originally, so maybe this
thread is a bad place for such a discussion.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Tue, 2016-06-14 at 15:40 -0400, Ben Rosser wrote:
> This is a slight tangent, but by "remove Fedora packages", do you
> mean
> actually remove them from the distribution entirely or simply not
> show the
> packaged version in e.g. GNOME Software in favor of the upstream
> Flatpak?
> The latter makes sense to me, the former seems potentially
> controversial.

I was thinking remove the Fedora package. What's the point in
maintaining a secret Fedora package for a graphical app, when we're
going to be presenting a different version of that app to users? And as
Josh says, this would also create confusion regarding where to report
bugs, and also confusion when users have two different sets of bugs
depending on whether you use a Fedora package or the upstream Flatpak.
But maybe we will need to keep the Fedora packages to support spins,
e.g. we probably don't want to start removing packages before KDE grows
support for Flatpaks in its graphical installer.

There's no plan to systematically go around removing Fedora packages in
favor of Flatpaks; rather, we plan to do this on a case-by-case basis
at the request of upstreams that have developed Flatpaks and want those
Flatpaks to be available in Fedora. Package maintainers would be
allowed to dispute the change, again on a case-by-case basis, but I
don't expect that to happen often. We're also planning to allow third-
party RPMs to replace Fedora-provided RPMs following the same
procedure.

Full details at [1], just keep in mind this is a WIP document in the
preproposal stage; i.e. we were not planning to propose it on this list
yet.

[1] https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Igor Gnatenko]

When DNF will be able to install flatpack pkgs then we can stop supporting
distro packages for that.

-Igor Gnatenko
On Jun 14, 2016 9:33 PM, "Michael Catanzaro"  wrote:

> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> > Does anyone in marketing or development now what the article is
> > referring
> > to and what's going on?
>
> Hi,
>
> There's an article on Ars as well. The "working with Fedora developers"
> claim is probably a misunderstanding on Softpedia's part; it's not
> true, and I doubt Canonical would have said that. What's going on is
> that Canonical beat us to market in development... and now their
> marketing folks have beat us in marketing, too. We of course have zero
> plans to adopt Snappy in Fedora, and in fact multiple Fedora developers
> are working on a competing solution, Flatpak [1] (formerly xdg-app),
> which is also being adopted by GNOME and Endless. Until today, Snappy
> was viewed as Ubuntu-specific, which is why there was so little
> interest in it.
>
> We have not considered, and need to discuss, whether to allow that
> snapcore package into Fedora proper; there's a strong argument to be
> made that we should accept all free software, but doing that could
> undercut our Flatpak effort. If popular upstreams start distributing
> snaps, then we'll probably have to support it, though.
>
> Challenge for the marketing folks: can we get these tech journalism
> sites writing about Flatpak instead? About GNOME Software's new support
> for displaying and installing Flatpaks in F24? Otherwise, I see
> upstreams adopting Snappy and not Flatpak.
>
> Background info: In the Workstation working group, we're currently
> planning to allow replacing RPM packages for graphical apps with
> Flatpaks. We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora. I guess we
> could do the same with snaps, if they become sufficiently popular, but
> it'd be quite unfortunate to support two competing desktop
> containerization solutions.
>
> Michael
>
> [1] http://flatpak.org/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Tom Hughes]

On 14/06/16 20:32, Michael Catanzaro wrote:


We have not considered, and need to discuss, whether to allow that
snapcore package into Fedora proper; there's a strong argument to be
made that we should accept all free software, but doing that could
undercut our Flatpak effort. If popular upstreams start distributing
snaps, then we'll probably have to support it, though.


As others have already said, since when have we been in the business of 
deciding that certain things can't be packaged because they compete with 
other things?



Background info: In the Workstation working group, we're currently
planning to allow replacing RPM packages for graphical apps with
Flatpaks. We're also planning to remove Fedora packages for selected
apps that are offered as Flatpaks by upstream. For instance, if
(hypothetical) Inkscape were to offer a Flatpak download on their web
site, the Inkscape developers could request that we remove the Inkscape
Fedora package and display their Flatpak in GNOME Software instead;


The Inkscape developers? or the Inkscape packager(s) in Fedora?

I mean I really hope you're not saying that upstream developers will be 
able to start demanding that a third party packager's work is removed 
from Fedora!


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Josh Boyer]

On Tue, Jun 14, 2016 at 3:32 PM, Michael Catanzaro  wrote:
> On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
>> Does anyone in marketing or development now what the article is
>> referring
>> to and what's going on?
>
> Hi,
>
> There's an article on Ars as well. The "working with Fedora developers"
> claim is probably a misunderstanding on Softpedia's part; it's not
> true, and I doubt Canonical would have said that. What's going on is
> that Canonical beat us to market in development... and now their
> marketing folks have beat us in marketing, too. We of course have zero
> plans to adopt Snappy in Fedora, and in fact multiple Fedora developers
> are working on a competing solution, Flatpak [1] (formerly xdg-app),
> which is also being adopted by GNOME and Endless. Until today, Snappy
> was viewed as Ubuntu-specific, which is why there was so little
> interest in it.

"...interest in it within Fedora." is probably what you meant?

> We have not considered, and need to discuss, whether to allow that
> snapcore package into Fedora proper; there's a strong argument to be
> made that we should accept all free software, but doing that could
> undercut our Flatpak effort. If popular upstreams start distributing
> snaps, then we'll probably have to support it, though.

I'm sorry, but undercutting a competing effort isn't a disqualifier
for packaging within Fedora.  That would be like saying KDE undercuts
GNOME or emacs undercuts vi, etc.  Software should compete on it's
technical merits and generally be available within the Fedora
packaging repositories as long as its license and packaging is
acceptable.

> Challenge for the marketing folks: can we get these tech journalism
> sites writing about Flatpak instead? About GNOME Software's new support
> for displaying and installing Flatpaks in F24? Otherwise, I see
> upstreams adopting Snappy and not Flatpak.

That's certainly something worth doing.

> Background info: In the Workstation working group, we're currently
> planning to allow replacing RPM packages for graphical apps with
> Flatpaks. We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora. I guess we

How do you plan on addressing the problem reporting issue?  In your
example, the Inkscape package will still exist in RPM form for other
Editions.  That means there are potentially two versions of Inkscape,
one from upstream and one packaged in Fedora.  How do you ensure
problem reports are routed to the correct issue tracker?

Even ignoring a potential overlap with upstream Flatpak vs. RPM, the
problem reporting issue exists.  If GNOME Software is offering up
upstream flatpaks directly, I'm concerned it is going to lead to
confusion for users when they have issues.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Ben Rosser]

On Tue, Jun 14, 2016 at 3:32 PM, Michael Catanzaro 
wrote:

>
> We're also planning to remove Fedora packages for selected
> apps that are offered as Flatpaks by upstream. For instance, if
> (hypothetical) Inkscape were to offer a Flatpak download on their web
> site, the Inkscape developers could request that we remove the Inkscape
> Fedora package and display their Flatpak in GNOME Software instead; the
> goal here is to reduce friction between upstream and downstream that
> people complain about so often, while ensuring it's still very easy to
> find and install software that runs reliably on Fedora.
>
> Michael
>

This is a slight tangent, but by "remove Fedora packages", do you mean
actually remove them from the distribution entirely or simply not show the
packaged version in e.g. GNOME Software in favor of the upstream Flatpak?
The latter makes sense to me, the former seems potentially controversial.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Michael Catanzaro]

On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote:
> Does anyone in marketing or development now what the article is
> referring
> to and what's going on?

Hi,

There's an article on Ars as well. The "working with Fedora developers"
claim is probably a misunderstanding on Softpedia's part; it's not
true, and I doubt Canonical would have said that. What's going on is
that Canonical beat us to market in development... and now their
marketing folks have beat us in marketing, too. We of course have zero
plans to adopt Snappy in Fedora, and in fact multiple Fedora developers
are working on a competing solution, Flatpak [1] (formerly xdg-app),
which is also being adopted by GNOME and Endless. Until today, Snappy
was viewed as Ubuntu-specific, which is why there was so little
interest in it.

We have not considered, and need to discuss, whether to allow that
snapcore package into Fedora proper; there's a strong argument to be
made that we should accept all free software, but doing that could
undercut our Flatpak effort. If popular upstreams start distributing
snaps, then we'll probably have to support it, though.

Challenge for the marketing folks: can we get these tech journalism
sites writing about Flatpak instead? About GNOME Software's new support
for displaying and installing Flatpaks in F24? Otherwise, I see
upstreams adopting Snappy and not Flatpak.

Background info: In the Workstation working group, we're currently
planning to allow replacing RPM packages for graphical apps with
Flatpaks. We're also planning to remove Fedora packages for selected
apps that are offered as Flatpaks by upstream. For instance, if
(hypothetical) Inkscape were to offer a Flatpak download on their web
site, the Inkscape developers could request that we remove the Inkscape
Fedora package and display their Flatpak in GNOME Software instead; the
goal here is to reduce friction between upstream and downstream that
people complain about so often, while ensuring it's still very easy to
find and install software that runs reliably on Fedora. I guess we
could do the same with snaps, if they become sufficiently popular, but
it'd be quite unfortunate to support two competing desktop
containerization solutions.

Michael

[1] http://flatpak.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora development of Snap packages

[Eric Griffith]

I'm testing it out for Phoronix. The copr works correctly, it installs
fine. Running snapper works fine, once you figure out what the correct
instructions should be (snapcraft.io's instructions are slightly wrong).

Applications appear to run correctly and integrate fine in the Workstation
environment.. minus LibreOffice.

File sizes are massive compared to traditional packages. The Document
Foundation's rpm package for Linux x64 is 229 MBs. A LibreOffice 5.2 Beta
snap that I found clocked in at 1.1 GB.
On Jun 14, 2016 14:26, "James Hogarth"  wrote:

> So I was rather surprised by this Softpaedia article today:
>
>
> http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml
>
> It claims that Canonical state that they have been working with Fedora
> developers to make this the universal packaging format.
>
> The snapcraft.io site instructions say to use a COPR by a Canonical
> employee who is not a Fedora packager.
>
> Does anyone in marketing or development now what the article is referring
> to and what's going on?
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora development of Snap packages

[James Hogarth]

So I was rather surprised by this Softpaedia article today:

http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml

It claims that Canonical state that they have been working with Fedora
developers to make this the universal packaging format.

The snapcraft.io site instructions say to use a COPR by a Canonical
employee who is not a Fedora packager.

Does anyone in marketing or development now what the article is referring
to and what's going on?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org