1:25 p.m.
There has been a lively discussion within KDE regarding the Konqueror
browser; and subsequently it has been decided that a non-KDE, GTK browser
will be the default for the spin.
Why, because Firefox is the only choice for Fedora, Chromium is not allowed.
Here is a good excerpt:
On Tue, Aug 11, 2015 at 9:56 AM, Dan Mossor <danofsatx(a)gmail.com> wrote:
The correct avenue here, in light of the news from the upstream
products,
is to keep the status quo regardless of the lack of usability. When we
finally get a fully-featured Qt based browser, that is when we switch. We
DO NOT switch to a GTk based browser that has zero integration with the
Plasma desktop - single click selection of files and directories within
Firefox doesn't even work, let alone the theming and other issues.
Ironically, those two items, as well as integration with kWallet, work fine
with Google Chrome (which is not a choice in this discussion).
Tom Calloway has been working on Chromium - and his copr is up-to-date for
anyone who wants to try it.
https://copr.fedoraproject.org/coprs/spot/chromium/
It's been a slow slog working through the issues keeping it from the
official repository, but progress
has been made: https://code.google.com/p/chromium/issues/detail?id=28287
Things have also changed over the years, and Chrome/Chromium's popularity
has continued to grow and is now packaged in Ubuntu, Debian and Suse.
Firefox has exceptions mainly because it is deemed "to popular" to keep out
of the distribution. I think it is obvious to everyone that
Chrome/Chromium is "at least" as popular than Firefox.
I realize we have our guidelines and we're not Debian, Suse or Ubuntu...
and that's a good thing. But, if we're making exceptions for Firefox
because of it's popularity shouldn't we do the same for Chromium.
1:28 p.m.
Once upon a time, Gerald B. Cox <gbcox(a)bzb.us> said:
I realize we have our guidelines and we're not Debian, Suse or
Ubuntu...
and that's a good thing. But, if we're making exceptions for Firefox
because of it's popularity shouldn't we do the same for Chromium.
What packaging exceptions are being made for Firefox?
--
Chris Adams <linux(a)cmadams.net>
1:41 p.m.
On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams <linux(a)cmadams.net> wrote:
What packaging exceptions are being made for Firefox?
They can be found here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
1:54 p.m.
On Tue, Aug 11, 2015 at 2:41 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams <linux(a)cmadams.net> wrote:
> What packaging exceptions are being made for Firefox?
They can be found here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I think if we're willing to grant such an exception to Firefox, we should
be willing to extend the same to Chromium. That is, of course, provided
that we can actively work towards cutting away at bundled libraries and
getting the engine switched from FFmpeg to GStreamer. Right now, the effort
to switch from ffmpeg to GStreamer is being done largely by Samsung
<https://github.com/Samsung/ChromiumGStreamerBackend>;, and I think that
variant of Chromium is much more appealing due to the pluggable codec
framework in GStreamer. I'd rather not have Fedora ship Chromium with a
gimped ffmpeg if we didn't have to, but it would be acceptable if using
Samsung's efforts to offer GStreamer support isn't appealing right now and
that the bundled ffmpeg libraries are split out into a subpackage.
--
真実はいつも一つ！/ Always, there's only one truth!
4:30 a.m.
On Tue, 2015-08-11 at 14:54 -0400, Neal Gompa wrote:
I think if we're willing to grant such an exception to Firefox,
we
should be willing to extend the same to Chromium. That is, of course,
provided that we can actively work towards cutting away at bundled
libraries and getting the engine switched from FFmpeg to GStreamer.
Right now, the effort to switch from ffmpeg to GStreamer is being
done largely by Samsung, and I think that variant of Chromium is much
more appealing due to the pluggable codec framework in GStreamer. I'd
rather not have Fedora ship Chromium with a gimped ffmpeg if we
didn't have to, but it would be acceptable if using Samsung's efforts
to offer GStreamer support isn't appealing right now and that the
bundled ffmpeg libraries are split out into a subpackage.
Unfortunately I would not count on Samsung's work to be upstreamed, as
Google will never use it. The GStreamer folks are hoping for it to be
upstreamed but acknowledge there is no chance it will be built by
default. This is an optimistic hope; it is not unlikely that it will
need to be maintained out-of-tree indefinitely. In this case, it would
be better to use Samsung's Chrome as our upstream, rather than
Google's.
Still, I think the bundling exceptions are reasonable. In particular,
there is no reason for Firefox to receive exceptions if Chromium does
not. (The justification for Firefox is "active security team"; Chrome
has that too.)
2:12 p.m.
On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
Meanwhile, on OS X I was already given notification of Firefox being
updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
koji, there are no Bodhi entries for it, so it's not in any repo.
So I don't really buy any of the security arguments of either "no
bundled libraries" or the FF exception to it. The delay appears to be
packaging itself. Mozilla produces an OS X and Windows specific
packages, and they update themselves rather than going through the OS
update system. This doesn't happen on Linux, where it's expected
Firefox gets updated by the distro repo and packaging system. Yet I
see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder
why that binary doesn't just run unmodified anywhere and I'm waiting
for 40.0 to show up in Bodhi?
--
Chris Murphy
2:18 p.m.
On 08/11/2015 12:12 PM, Chris Murphy wrote:
Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I
wonder why that binary doesn't just run unmodified anywhere and I'm
waiting for 40.0 to show up in Bodhi?
If you don't see the value of distro integration and testing, then by
all means, go use mozilla's binaries.
2:38 p.m.
On Tue, Aug 11, 2015 at 1:18 PM, Josh Stone <jistone(a)redhat.com> wrote:
On 08/11/2015 12:12 PM, Chris Murphy wrote:
> Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I
> wonder why that binary doesn't just run unmodified anywhere and I'm
> waiting for 40.0 to show up in Bodhi?
If you don't see the value of distro integration and testing, then by
all means, go use mozilla's binaries.
I do not see the value in manually checking koji for Firefox updates
and then manually downloading and installing them. That's just not
going to happen by pretty much anybody. I have u-t enabled, I do
testing, this update is not in u-t yet.
If I knew Mozilla's Linux binaries provided its own update mechanism
and notification, yes I would do exactly that. And I'd still ask what
the benefit is of duplicating this effort? It sounds like it's not
actually a benefit, rather it's "because packaging".
--
Chris Murphy
3:07 p.m.
On 08/11/2015 12:38 PM, Chris Murphy wrote:
On Tue, Aug 11, 2015 at 1:18 PM, Josh Stone
<jistone(a)redhat.com> wrote:
> On 08/11/2015 12:12 PM, Chris Murphy wrote:
>> Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I
>> wonder why that binary doesn't just run unmodified anywhere and I'm
>> waiting for 40.0 to show up in Bodhi?
>
> If you don't see the value of distro integration and testing, then by
> all means, go use mozilla's binaries.
I do not see the value in manually checking koji for Firefox updates
and then manually downloading and installing them. That's just not
going to happen by pretty much anybody. I have u-t enabled, I do
testing, this update is not in u-t yet.
The value at that stage is trusting the package maintainers to judge
whether this is ready for broad use yet. Perhaps in this case they're
aware of issues like what Bill mentioned. It doesn't belong in
updates-testing until they think it's good to go.
If I knew Mozilla's Linux binaries provided its own update
mechanism
and notification, yes I would do exactly that. And I'd still ask what
the benefit is of duplicating this effort? It sounds like it's not
actually a benefit, rather it's "because packaging".
I believe it does, but you can check Preferences > Advanced > Update.
The "Firefox updates" section is disabled in Fedora builds, but should
be there from Mozilla.
And "because packaging" has a lot to do with integration with system
libraries. Mozilla's tarball includes a lot of bundled libraries,
beyond those that already have Fedora exceptions.
3:18 p.m.
On Aug 11, 2015 10:38 PM, "Chris Murphy" <lists(a)colorremedies.com> wrote:
On Tue, Aug 11, 2015 at 1:18 PM, Josh Stone <jistone(a)redhat.com> wrote:
> On 08/11/2015 12:12 PM, Chris Murphy wrote:
>> Yet I see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I
>> wonder why that binary doesn't just run unmodified anywhere and I'm
>> waiting for 40.0 to show up in Bodhi?
>
> If you don't see the value of distro integration and testing, then by
> all means, go use mozilla's binaries.
I do not see the value in manually checking koji for Firefox updates
and then manually downloading and installing them. That's just not
going to happen by pretty much anybody. I have u-t enabled, I do
testing, this update is not in u-t yet.
If I knew Mozilla's Linux binaries provided its own update mechanism
and notification, yes I would do exactly that.
I am pretty sure they get updated just like Windows and OS X binaries, but
the tar ball should be extracted in a user writable location.
I sometimes extract it into .firefox (hidden) folder in my home and create
a shortcut in KDE menu.
Mustafa
And I'd still ask what
the benefit is of duplicating this effort? It sounds like it's not
actually a benefit, rather it's "because packaging".
--
Chris Murphy
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3:29 p.m.
Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
> If I knew Mozilla's Linux binaries provided its own update
mechanism
> and notification, yes I would do exactly that.
I am pretty sure they get updated just like Windows and OS X binaries,
but the tar ball should be extracted in a user writable location
nonsense
*if* you use binary tarballs they *should not* be extracted in a user
writeable location as *no binary* whenever possible should have
permissions allowing a ordinary user to change them
they should be extracted to /usr/local/ with root-only write-permissions
and you have to just start the application as root for updates - not
only on Linux, on *any* operating system
and since most users are not able to cope with this security principals
package managers exists
_________________________________________
http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
World-writable files, particularly system files, can be a security hole
if a cracker gains access to your system and modifies them.
Additionally, world-writable directories are dangerous, since they allow
a cracker to add or delete files as he wishes
_________________________________________
as long as you did not inherit that principles you have no clue about
security and will be the first victim of exploits on non-windows systems
4 p.m.
On Aug 11, 2015 11:29 PM, "Reindl Harald" <h.reindl(a)thelounge.net> wrote:
Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
>
> > If I knew Mozilla's Linux binaries provided its own update mechanism
> > and notification, yes I would do exactly that.
>
> I am pretty sure they get updated just like Windows and OS X binaries,
> but the tar ball should be extracted in a user writable location
nonsense
*if* you use binary tarballs they *should not* be extracted in a user
writeable
location as *no binary* whenever possible should have permissions
allowing a ordinary user to change them
they should be extracted to /usr/local/ with root-only write-permissions
and you
have to just start the application as root for updates - not only
on Linux, on *any* operating system
and since most users are not able to cope with this security principals
package
managers exists
_________________________________________
http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
World-writable files, particularly system files, can be a security hole
if a
cracker gains access to your system and modifies them. Additionally,
world-writable directories are dangerous, since they allow a cracker to add
or delete files as he wishes
My home is not world writable.
The way you pointed is the better way, of course, but I think even my
simple way is better than waiting for package updates from the repos when
an exploit is in the wild.
_________________________________________
as long as you did not inherit that principles you have no clue about
security and
will be the first victim of exploits on non-windows systems
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
4:03 p.m.
On Aug 12, 2015 12:00 AM, "Mustafa Muhammad" <mustafa1024m(a)gmail.com>
wrote:
On Aug 11, 2015 11:29 PM, "Reindl Harald" <h.reindl(a)thelounge.net>
wrote:
>
>
>
> Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
>>
>> > If I knew Mozilla's Linux binaries provided its own update mechanism
>> > and notification, yes I would do exactly that.
>>
>> I am pretty sure they get updated just like Windows and OS X binaries,
>> but the tar ball should be extracted in a user writable location
>
>
> nonsense
>
> *if* you use binary tarballs they *should not* be extracted in a user
writeable location as *no binary* whenever possible should have permissions
allowing a ordinary user to change them
>
> they should be extracted to /usr/local/ with root-only
write-permissions and
you have to just start the application as root for
updates - not only on Linux, on *any* operating system
>
> and since most users are not able to cope with this security principals
package managers exists
> _________________________________________
>
> http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
>
> World-writable files, particularly system files, can be a security hole
if a
cracker gains access to your system and modifies them. Additionally,
world-writable directories are dangerous, since they allow a cracker to add
or delete files as he wishes
My home is not world writable.
The way you pointed is the better way, of course, but I think even my
simple way is
better than waiting for package updates from the repos when
an exploit is in the wild.
By the way, running an application as root, even fit just updating it is
dangerous.
> _________________________________________
>
> as long as you did not inherit that principles you have no clue about
security
and will be the first victim of exploits on non-windows systems
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
4:07 p.m.
Am 11.08.2015 um 23:03 schrieb Mustafa Muhammad:
On Aug 12, 2015 12:00 AM, "Mustafa Muhammad" <mustafa1024m(a)gmail.com
<mailto:mustafa1024m@gmail.com>> wrote:
>
>
> On Aug 11, 2015 11:29 PM, "Reindl Harald" <h.reindl(a)thelounge.net
<mailto:h.reindl@thelounge.net>> wrote:
> >
> >
> >
> > Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
> >>
> >> > If I knew Mozilla's Linux binaries provided its own update
mechanism
> >> > and notification, yes I would do exactly that.
> >>
> >> I am pretty sure they get updated just like Windows and OS X binaries,
> >> but the tar ball should be extracted in a user writable location
> >
> >
> > nonsense
> >
> > *if* you use binary tarballs they *should not* be extracted in a
user writeable location as *no binary* whenever possible should have
permissions allowing a ordinary user to change them
> >
> > they should be extracted to /usr/local/ with root-only
write-permissions and you have to just start the application as root for
updates - not only on Linux, on *any* operating system
> >
> > and since most users are not able to cope with this security
principals package managers exists
> > _________________________________________
> >
> > http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
> >
> > World-writable files, particularly system files, can be a security
hole if a cracker gains access to your system and modifies them.
Additionally, world-writable directories are dangerous, since they allow
a cracker to add or delete files as he wishes
>
> My home is not world writable.
> The way you pointed is the better way, of course, but I think even my
simple way is better than waiting for package updates from the repos
when an exploit is in the wild.
By the way, running an application as root, even fit just updating it is
dangerous
besides your home *is wolrd writable* when a remote xploit happens to a
any application you are running do some simple calculation what is more
likely to be exploited:
* your application running with your user all day long
handling random input data from all over the web
* your application started once as root only for the
purpose of install updates
if you don't realize the difference there is no help...
4:04 p.m.
Am 11.08.2015 um 23:00 schrieb Mustafa Muhammad:
On Aug 11, 2015 11:29 PM, "Reindl Harald" <h.reindl(a)thelounge.net
<mailto:h.reindl@thelounge.net>> wrote:
>
> Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
>>
>> > If I knew Mozilla's Linux binaries provided its own update mechanism
>> > and notification, yes I would do exactly that.
>>
>> I am pretty sure they get updated just like Windows and OS X binaries,
>> but the tar ball should be extracted in a user writable location
>
>
> nonsense
>
> *if* you use binary tarballs they *should not* be extracted in a user
writeable location as *no binary* whenever possible should have
permissions allowing a ordinary user to change them
>
> they should be extracted to /usr/local/ with root-only
write-permissions and you have to just start the application as root for
updates - not only on Linux, on *any* operating system
>
> and since most users are not able to cope with this security
principals package managers exists
> _________________________________________
>
> http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
>
> World-writable files, particularly system files, can be a security
hole if a cracker gains access to your system and modifies them.
Additionally, world-writable directories are dangerous, since they allow
a cracker to add or delete files as he wishes
My home is not world writable
you still don't get it
if you are running whatever application and *you have write permissions*
from the moment a remote exploit is sucessful your home *is world
writable* - period
4:35 p.m.
On 08/11/2015 02:04 PM, Reindl Harald wrote:
Am 11.08.2015 um 23:00 schrieb Mustafa Muhammad:
>
> On Aug 11, 2015 11:29 PM, "Reindl Harald" <h.reindl(a)thelounge.net
> <mailto:h.reindl@thelounge.net>> wrote:
> >
> > Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
> >>
> >> > If I knew Mozilla's Linux binaries provided its own update
mechanism
> >> > and notification, yes I would do exactly that.
> >>
> >> I am pretty sure they get updated just like Windows and OS X binaries,
> >> but the tar ball should be extracted in a user writable location
> >
> >
> > nonsense
> >
> > *if* you use binary tarballs they *should not* be extracted in a user
> writeable location as *no binary* whenever possible should have
> permissions allowing a ordinary user to change them
> >
> > they should be extracted to /usr/local/ with root-only
> write-permissions and you have to just start the application as root for
> updates - not only on Linux, on *any* operating system
> >
> > and since most users are not able to cope with this security
> principals package managers exists
> > _________________________________________
> >
> > http://www.tldp.org/HOWTO/Security-HOWTO/file-security.html
> >
> > World-writable files, particularly system files, can be a security
> hole if a cracker gains access to your system and modifies them.
> Additionally, world-writable directories are dangerous, since they allow
> a cracker to add or delete files as he wishes
>
> My home is not world writable
you still don't get it
if you are running whatever application and *you have write permissions*
from the moment a remote exploit is sucessful your home *is world
writable* - period
I think you're mixing terminology.
"World-writable" is often used referring to the S_IWOTH flag, where
"others" (vs. user/group) have write permission. I believe that's what
your linked tldp article is talking about.
You seem to be talking about literally anyone in the world using a
remote exploit, gaining the permissions of a user account, and then they
can write home. It's still only writable by that user id, barring new
chmods, but the user account itself is compromised.
4:42 p.m.
Am 11.08.2015 um 23:35 schrieb Josh Stone:
> if you are running whatever application and *you have write
permissions*
> from the moment a remote exploit is sucessful your home *is world
> writable* - period
I think you're mixing terminology.
"World-writable" is often used referring to the S_IWOTH flag, where
"others" (vs. user/group) have write permission. I believe that's what
your linked tldp article is talking about.
You seem to be talking about literally anyone in the world using a
remote exploit, gaining the permissions of a user account, and then they
can write home. It's still only writable by that user id, barring new
chmods, but the user account itself is compromised.
that's a needless discussion and just nitpicking
no binary you regulayr run should be writeable by anybod but root, there
is no but of if - period - if somebody thinks there is an exception he
has no clue of security
"but the user account itself is compromised" is the point
the more applications are writable in your userhome that easier it get
compromised and after that you lose any control wich other files are
compromised
that affects any applicatoon BUT ESPECIALLY applications dealing with
random data from the internet and so at first a BROWSER which deals with
that by defintion
7:32 p.m.
On 08/11/2015 10:29 PM, Reindl Harald wrote:
Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
> > If I knew Mozilla's Linux binaries provided its own update mechanism
> > and notification, yes I would do exactly that.
>
> I am pretty sure they get updated just like Windows and OS X binaries,
> but the tar ball should be extracted in a user writable location
nonsense
Please be more respectful to others. What happened to the “Friends”
part of Fedora?
*if* you use binary tarballs they *should not* be extracted in a
user
writeable location as *no binary* whenever possible should have
permissions allowing a ordinary user to change them
This is simply not the way how end users install original Mozilla
Firefox binaries.
--
Florian Weimer / Red Hat Product Security
7:42 p.m.
> *if* you use binary tarballs they *should not* be extracted in a
user
> writeable location as *no binary* whenever possible should have
> permissions allowing a ordinary user to change them
This is simply not the way how end users install original Mozilla
Firefox binaries.
In addition, if you have write access to ~/, you can also change .bashrc
to add paths to executable files and do all sorts of other nasty things.
FWIW I run Mozilla's Firefox nightly builds and they work perfectly fine
on Fedora. I've also found the lag behind the official releases
annoying, also for some other large end-user packages (blender), for no
perceived benefit. But it's not especially painful.
3:33 a.m.
Am 12.08.2015 um 02:42 schrieb Thomas Daede:
>> *if* you use binary tarballs they *should not* be extracted
in a user
>> writeable location as *no binary* whenever possible should have
>> permissions allowing a ordinary user to change them
>
> This is simply not the way how end users install original Mozilla
> Firefox binaries.
In addition, if you have write access to ~/, you can also change .bashrc
to add paths to executable files and do all sorts of other nasty things
that's why chattr exists
chattr +i ~/.bashrc
chattr +i ~/.bash_profile
[root@rh:~]$ touch /home/harry/.bashrc
touch: cannot touch '/home/harry/.bashrc': Permission denied
9:44 a.m.
On 12 August 2015 at 09:33, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 12.08.2015 um 02:42 schrieb Thomas Daede:
>>>
>>> *if* you use binary tarballs they *should not* be extracted in a user
>>> writeable location as *no binary* whenever possible should have
>>> permissions allowing a ordinary user to change them
>>
>>
>> This is simply not the way how end users install original Mozilla
>> Firefox binaries.
>
>
> In addition, if you have write access to ~/, you can also change .bashrc
> to add paths to executable files and do all sorts of other nasty things
that's why chattr exists
chattr +i ~/.bashrc
chattr +i ~/.bash_profile
[root@rh:~]$ touch /home/harry/.bashrc
touch: cannot touch '/home/harry/.bashrc': Permission denied
However a compromised application that can write files can probably
make executable and fork too. So while immutable provides limited
protection, if the real attack surface is the web browser and the
worry is privilege escalation then overwriting .bashrc is a side show.
Having to run the browser as root to update it (which would remove
most of the advantage of automated updates by the mozilla binary)
replaces exposing user privileges with exposing root privileges. If
you really wanted to be paranoid about this you'd make a separate user
account with write permission for that binary to be used for updates.
(Which is one of the reasons package managers are a good idea.)
--
imalone
http://ibmalone.blogspot.co.uk
3:34 a.m.
Am 12.08.2015 um 02:32 schrieb Florian Weimer:
On 08/11/2015 10:29 PM, Reindl Harald wrote:
>
> Am 11.08.2015 um 22:18 schrieb Mustafa Muhammad:
>> > If I knew Mozilla's Linux binaries provided its own update mechanism
>> > and notification, yes I would do exactly that.
>>
>> I am pretty sure they get updated just like Windows and OS X binaries,
>> but the tar ball should be extracted in a user writable location
>
> nonsense
Please be more respectful to others. What happened to the “Friends”
part of Fedora?
> *if* you use binary tarballs they *should not* be extracted in a user
> writeable location as *no binary* whenever possible should have
> permissions allowing a ordinary user to change them
This is simply not the way how end users install original Mozilla
Firefox binaries
because people are doing it wrong don't mean they should do it that way
and that's what the OP said "should be extracted in a user writable
location"
8:44 p.m.
Chris Murphy composed on 2015-08-11 13:38 (UTC-0600):
Josh Stone wrote:
> If you don't see the value of distro integration and testing,
then by
> all means, go use mozilla's binaries.
As a KDE user of Mozilla products since long before its very first v1.0
product (Mozilla Suite) release, I've long since seen any point getting into
discussion of the topic of DE integration. It's no more than a pipe dream for
KDE users.
If I knew Mozilla's Linux binaries provided its own update
mechanism
and notification, yes I would do exactly that.
Why would you think it doesn't just because it's Linux and Linux has package
managers to shield mere mortals from having to deal with such things when you
must know it works for Windows and Mac users?
A mechanism for multiple versions of individual Mozilla products to be
simultaneously installed (AFAIK) remains absent from distros' package
managers. I'm sure most of us testing its pre-releases (and those developing
them) or otherwise needing access to non-current versions while using
releases for normal affairs long ago learned Mozilla binaries do what they
need to do without any need for any supposed DE "integration". That includes
updating themselves.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
2:19 p.m.
On Tue, Aug 11, 2015 at 12:12 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox <gbcox(a)bzb.us>
wrote:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Meanwhile, on OS X I was already given notification of Firefox being
updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
koji, there are no Bodhi entries for it, so it's not in any repo.
So I don't really buy any of the security arguments of either "no
bundled libraries" or the FF exception to it. The delay appears to be
packaging itself. Mozilla produces an OS X and Windows specific
packages, and they update themselves rather than going through the OS
update system. This doesn't happen on Linux, where it's expected
Firefox gets updated by the distro repo and packaging system. Yet I
see a Linux tar.bz2 for Firefox at downloads.mozilla.org so I wonder
why that binary doesn't just run unmodified anywhere and I'm waiting
for 40.0 to show up in Bodhi?
IMO it would be really really neat if Fedora could deterministically
rebuild whatever binary Mozilla distributes and have a binary
identical package.
/me stops daydreaming
I think that, in general, Fedora is too slow about turning a security
update submitted to stable via Bodhi into an actual available update.
For high-profile things like Firefox, we're pretty good about getting
karma, but even that depends on people manually installing an update
that isn't actually available in updates-testing so they can give it
karma.
--Andy
8:19 p.m.
On 8/12/15, Andrew Lutomirski <luto(a)mit.edu> wrote:
IMO it would be really really neat if Fedora could deterministically
rebuild whatever binary Mozilla distributes and have a binary
identical package.
/me stops daydreaming
I think that, in general, Fedora is too slow about turning a security
update submitted to stable via Bodhi into an actual available update.
For high-profile things like Firefox, we're pretty good about getting
karma, but even that depends on people manually installing an update
that isn't actually available in updates-testing so they can give it
karma.
Delay from package manager can't be avoided, signing, mirroring,
testing, building...
But for some popular packages we should open a seperate channel to
push them immediately after successful koji build(also marked as ok
for push from packager).
Firefox and chromium are hitting exploits always.
/daydreaming as well.
--
Yours sincerely,
Christopher Meng
http://awk.io
2:36 p.m.
Chris Murphy (lists(a)colorremedies.com) said:
On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox <gbcox(a)bzb.us>
wrote:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Meanwhile, on OS X I was already given notification of Firefox being
updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
koji, there are no Bodhi entries for it, so it's not in any repo.
FWIW, I installed that build from koji a few days ago. It crashed every 15
minutes or so. Hence, I assumed the reason it's not in Bodhi was intentional.
Bill
2:37 p.m.
On Tue, Aug 11, 2015 at 12:36 PM, Bill Nottingham <notting(a)splat.cc> wrote:
FWIW, I installed that build from koji a few days ago. It crashed
every 15
minutes or so. Hence, I assumed the reason it's not in Bodhi was
intentional.
I haven't had any issues with it.... if you did, you should report it to
Tom.
2:43 p.m.
On Tue, Aug 11, 2015 at 12:37 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
On Tue, Aug 11, 2015 at 12:36 PM, Bill Nottingham
<notting(a)splat.cc>
wrote:
> FWIW, I installed that build from koji a few days ago. It crashed every 15
> minutes or so. Hence, I assumed the reason it's not in Bodhi was
> intentional.
>
I haven't had any issues with it.... if you did, you should report it to
Tom.
Sorry Bill, I thought you were talking about Chromium... re-read and
realized Firefox...
2:41 p.m.
Am 11.08.2015 um 21:36 schrieb Bill Nottingham:
Chris Murphy (lists(a)colorremedies.com) said:
> On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
>> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>
> Meanwhile, on OS X I was already given notification of Firefox being
> updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
> koji, there are no Bodhi entries for it, so it's not in any repo.
FWIW, I installed that build from koji a few days ago. It crashed every 15
minutes or so. Hence, I assumed the reason it's not in Bodhi was intentional
FWIW i installed the koji build days ago, working as web-developer in my
daily job and did not notice a single crash
Aug 07 10:33:36 Updated: firefox-39.0.3-1.fc21.x86_64
Aug 08 04:55:20 Updated: firefox-40.0-2.fc21.x86_64
Aug 11 16:41:24 Updated: firefox-40.0-3.fc21.x86_64
2:39 p.m.
Am 11.08.2015 um 21:12 schrieb Chris Murphy:
On Tue, Aug 11, 2015 at 12:41 PM, Gerald B. Cox <gbcox(a)bzb.us>
wrote:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Meanwhile, on OS X I was already given notification of Firefox being
updated to 40.0.0 just a bit ago. And while I see Firefox 40.0 in
koji, there are no Bodhi entries for it, so it's not in any repo.
So I don't really buy any of the security arguments of either "no
bundled libraries" or the FF exception to it
that's just a Fedora problem noticeable for a lot of critical updates
not make it even to updates-testing while CentOS offers updated packages
at the same time
it's not Firefox specific
4:07 p.m.
Once upon a time, Gerald B. Cox <gbcox(a)bzb.us> said:
On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams
<linux(a)cmadams.net> wrote:
> What packaging exceptions are being made for Firefox?
They can be found here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
So FF bundles a small number of libraries, and has an exception because
of an "active security team".
How many libraries does Chromium bundle? How many people are working on
it? Sounds like spot is the only person working on packaging.
--
Chris Adams <linux(a)cmadams.net>
8:33 p.m.
On Tue, Aug 11, 2015 at 5:07 PM, Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Gerald B. Cox <gbcox(a)bzb.us> said:
> On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams <linux(a)cmadams.net> wrote:
> > What packaging exceptions are being made for Firefox?
>
> They can be found here:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
So FF bundles a small number of libraries, and has an exception because
of an "active security team".
How many libraries does Chromium bundle? How many people are working on
it? Sounds like spot is the only person working on packaging.
--
Chris Adams <linux(a)cmadams.net>
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Chromium/Chrome also has a very active security team, so if that's the
reason for allowing it with Firefox, it could also be allowed for the same
reason.
--
真実はいつも一つ！/ Always, there's only one truth!
8:21 a.m.
Le 11 août 2015 5:08 PM, "Chris Adams" <linux(a)cmadams.net> a écrit :
Once upon a time, Gerald B. Cox <gbcox(a)bzb.us> said:
> On Tue, Aug 11, 2015 at 11:28 AM, Chris Adams <linux(a)cmadams.net> wrote:
> > What packaging exceptions are being made for Firefox?
>
> They can be found here:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
So FF bundles a small number of libraries, and has an exception because
of an "active security team".
How many libraries does Chromium bundle? How many people are working on
No, no and no.
FF and Chromium are not the same, Chromium brings bundling and crappy
practices at whole another scale.
We're not treating Chromium any differently, there are good reasons it's
not in our repo while FF is.
it? Sounds like spot is the only person working on packaging.
Spot is likely in the best spot to judge if Chromium could be submitted
even with exceptions.
H.
--
Chris Adams <linux(a)cmadams.net>
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
6:36 p.m.
Gerald B. Cox píše v Út 11. 08. 2015 v 11:25 -0700:
There has been a lively discussion within KDE regarding the Konqueror
browser; and subsequently it has been decided that a non-KDE, GTK
browser will be the default for the spin.
Why, because Firefox is the only choice for Fedora, Chromium is not
allowed.
And how would Chromium make this particular situation better? It looks
even less integrated in KDE than Firefox.
Nevertheless, it looks like we will need to find a solution to this
because Qt developers have decided to replace Qt WebKit with Qt Web
Engine which is nothing, but a bundled Chromium. So if we want Qt apps
in Fedora to draw HTML in the future, we probably won't have a lot of
choice.
Jiri
On Tue, Aug 11, 2015 at 9:56 AM, Dan Mossor <danofsatx(a)gmail.com>
wrote:
> The correct avenue here, in light of the news from the upstream
> products, is to keep the status quo regardless of the lack of
> usability. When we finally get a fully-featured Qt based browser,
> that is when we switch. We DO NOT switch to a GTk based browser
> that has zero integration with the Plasma desktop - single click
> selection of files and directories within Firefox doesn't even
> work, let alone the theming and other issues. Ironically, those two
> items, as well as integration with kWallet, work fine with Google
> Chrome (which is not a choice in this discussion).
Tom Calloway has been working on Chromium - and his copr is up-to
-date for anyone who wants to try it.
https://copr.fedoraproject.org/coprs/spot/chromium/
It's been a slow slog working through the issues keeping it from the
official repository, but progress
has been made:
https://code.google.com/p/chromium/issues/detail?id=28287
Things have also changed over the years, and Chrome/Chromium's
popularity has continued to grow and is now packaged in Ubuntu,
Debian and Suse. Firefox has exceptions mainly because it is deemed
"to popular" to keep out of the distribution. I think it is obvious
to everyone that Chrome/Chromium is "at least" as popular than
Firefox.
I realize we have our guidelines and we're not Debian, Suse or
Ubuntu... and that's a good thing. But, if we're making exceptions
for Firefox because of it's popularity shouldn't we do the same for
Chromium.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3:06 p.m.
On Tue, Aug 11, 2015 at 4:36 PM, Jiri Eischmann <eischmann(a)redhat.com>
wrote:
And how would Chromium make this particular situation better? It
looks
even less integrated in KDE than Firefox.
Nevertheless, it looks like we will need to find a solution to this
because Qt developers have decided to replace Qt WebKit with Qt Web
Engine which is nothing, but a bundled Chromium. So if we want Qt apps
in Fedora to draw HTML in the future, we probably won't have a lot of
choice.
That wasn't my point. The point was that Firefox was chosen because it was
the only available alternative.
Chromium isn't in the distribution, so it couldn't even be considered.
8:36 p.m.
On 8/12/15, Gerald B. Cox <gbcox(a)bzb.us> wrote:
There has been a lively discussion within KDE regarding the
Konqueror
browser; and subsequently it has been decided that a non-KDE, GTK browser
will be the default for the spin.
Why, because Firefox is the only choice for Fedora, Chromium is not
allowed.
Also because KDE has been ignored by web surfers for years. If they
care, K-based browser would have been here already. For the past 13
years:
https://bugzilla.mozilla.org/show_bug.cgi?id=140751
--
Yours sincerely,
Christopher Meng
http://awk.io
9:11 p.m.
On Tue, Aug 11, 2015 at 2:25 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
I realize we have our guidelines and we're not Debian, Suse or Ubuntu...
and that's a good thing. But, if we're making exceptions for Firefox
because of it's popularity shouldn't we do the same for Chromium.
I agree with Gerald. If there are exceptions for firefox due to popularity
then chromium deserves the same bundling exceptions. Otherwise we are not
being fair.
10:14 a.m.
New subject: [Fedora-packaging] Is it time to allow Chromium in Fedora?
On Tue, Aug 11, 2015 at 10:11:39PM -0400, Gary Gatling wrote:
> I realize we have our guidelines and we're not Debian, Suse
or Ubuntu...
> and that's a good thing. But, if we're making exceptions for Firefox
> because of it's popularity shouldn't we do the same for Chromium.
I agree with Gerald. If there are exceptions for firefox due to popularity
then chromium deserves the same bundling exceptions. Otherwise we are not
being fair.
It's important to note that "popularity" is not the sole reason for
exceptions for Firefox. Overall, everyone should review the existing
discussion in the guidelines about bundling exceptions and consider how
this might fit in (possibly including revisions if they make sense):
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reason...
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:29 a.m.
New subject: [Fedora-packaging] Is it time to allow Chromium in Fedora?
On 12/08/15 17:14, Matthew Miller wrote:
It's important to note that "popularity" is not the
sole reason for
exceptions for Firefox. Overall, everyone should review the existing
discussion in the guidelines about bundling exceptions and consider how
this might fit in (possibly including revisions if they make sense):
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reason...
Well, while true (I think), isn't this only one side of the coin? The
other is then the unresolved question how to make it easier to establish
a useful set of tools which includes sw which for good reasons
(non-free, GL breakage, etc) cannot be part of Fedora.
I wish I had some good solution, but... However, note all these
"post-install" Fedora howtos out there which describes how to install
things which is needed for many users, but cannot be part of Fedora
repos (Chromium is one example). Is there really nothing we can do about
this?
"scratching my head"
--alec
10:53 a.m.
New subject: [Fedora-packaging] Is it time to allow Chromium in Fedora?
On Wed, Aug 12, 2015 at 11:14 AM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
On Tue, Aug 11, 2015 at 10:11:39PM -0400, Gary Gatling wrote:
> > I realize we have our guidelines and we're not Debian, Suse or
Ubuntu...
> > and that's a good thing. But, if we're making exceptions for Firefox
> > because of it's popularity shouldn't we do the same for Chromium.
> I agree with Gerald. If there are exceptions for firefox due to
popularity
> then chromium deserves the same bundling exceptions. Otherwise we are not
> being fair.
It's important to note that "popularity" is not the sole reason for
exceptions for Firefox. Overall, everyone should review the existing
discussion in the guidelines about bundling exceptions and consider how
this might fit in (possibly including revisions if they make sense):
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reason...
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
While it is true that Chromium does indeed bundle a lot more than Firefox
does, I think they've also been putting in quite a bit of work into
actually solving this problem[0]. To be absolutely fair to Chromium, they
recognized the issue very quickly after they started making Linux releases.
On top of the fact that Chromium development moves extremely quickly[1] and
they appear to be quite responsive on security issues and work hard to
design the application to be secure in itself[2]. If I remember correctly,
it was Chromium's rapid development pace that triggered Firefox's own
development practices to change[3].
I think that it's hard for us to continue to ignore Chromium, too. Despite
everything, Chrome is preferred web browser by Fedorans second to Firefox,
and not by a wide margin with Google+ users and a somewhat wide margin with
Facebook users[4]. I imagine the lack of Chromium in Fedora is pretty much
the reason for low usage and Firefox being default the reason for it
remaining the top browser.
If there's a huge stopper of some kind, we should engage with the Chromium
folks more directly on solving it. I don't know exactly what that would
involve, but we should do something about it, I think.
[0]: https://code.google.com/p/chromium/issues/detail?id=28287
[1]: https://www.chromium.org/getting-involved/dev-channel
[2]: https://www.chromium.org/Home/chromium-security
[3]:
http://www.computerworld.com/article/2506843/desktop-apps/firefox-follows...
[4]:
https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-amon...
--
真実はいつも一つ！/ Always, there's only one truth!
2:07 p.m.
New subject: [Fedora-packaging] Is it time to allow Chromium in Fedora?
On 11/08/15 20:25, Gerald B. Cox wrote:
...
Things have also changed over the years, and Chrome/Chromium's
popularity has continued to grow and is now packaged in Ubuntu, Debian
and Suse. Firefox has exceptions mainly because it is deemed "to
popular" to keep out of the distribution. I think it is obvious to
everyone that Chrome/Chromium is "at least" as popular than Firefox.
To understand the work this has created for Debian users and
maintainers, you may want to review this bug report which has ultimately
been traced to bundled library issues:
https://code.google.com/p/chromium/issues/detail?id=501318
If the Fedora community is willing to put the time into helping Chromium
developers merge their patches into upstream projects and avoid bundled
libraries that would help spread the workload that the Debian/Ubuntu
people are currently stuck with.
Regards,
Daniel
11:12 a.m.
New subject: [Fedora-packaging] Is it time to allow Chromium in Fedora?
On Wed, Aug 12, 2015 at 12:07 PM, Daniel Pocock <daniel(a)pocock.pro> wrote:
To understand the work this has created for Debian users and
maintainers, you may want to review this bug report which has ultimately
been traced to bundled library issues:
https://code.google.com/p/chromium/issues/detail?id=501318
Hey Daniel,
Thanks...Sorry, I had missed your post earlier; and it's clear it isn't the
friendliest application for packaging in a Linux distro; but progress is
slowly being made.
On the positive side, for those who'd like to give it a spin, Tom's copr is
great.
If you're coming from Chrome, it's a fairly seamless transition.
Everything just works
(at least as far as I can tell); and it looks and acts identical.
Extensions are all there,
PepperFlash, no issues. If you've already got Chrome, just:
ln -s /opt/google/chrome-unstable/PepperFlash/libpepflashplayer.so
/usr/lib64/chromium-browser/PepperFlash/
ln -s /opt/google/chrome-unstable/PepperFlash/manifest.json
/usr/lib64/chromium-browser/PepperFlash/
It's impressive. He really did an excellent job.
3215
days inactive
3218
days old
41 comments
21 participants
participants (21)
-
Alec Leamas -
Andrew Lutomirski -
Bill Nottingham -
Chris Adams -
Chris Murphy -
Christopher Meng -
Daniel Pocock -
Felix Miata -
Florian Weimer -
Gary Gatling -
Gerald B. Cox -
Haïkel -
Ian Malone -
Jiri Eischmann -
Josh Stone -
Matthew Miller -
Michael Catanzaro -
Mustafa Muhammad -
Neal Gompa -
Reindl Harald -
Thomas Daede