Open Floor Fedora Council IRC meeting today in #fedora-meeting
(18:00 UTC)
by Matthew Miller
A few things to talk about:
- Stephen Gallagher mentioned wanting to discuss the situation with
Firefox
- Followups from last week? (budget, ambassadors, ?)
- Langdon suggested to me that we look at Jitsi to replace hangouts
when we do video calls
Anyway, open floor -- bring anything else you have.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 1 month
Mozilla Firefox and Unsigned Extensions
by Stephen Gallagher
Esteemed Council Members,
For a while now, FESCo has been deliberating options on how to deal with
Mozilla's change to Firefox that disallows the loading of extensions that
haven't been signed by the Mozilla Foundation, particularly those extensions
that we ship in the Fedora repositories.
A month ago, FESCo drafted a letter that we sent to Mozilla (reproduced below).
They replied that they would provide us with a detailed response the next day. I
have subsequently pinged them each week for the last four.
At this time, FESCo would like the Council's permission to offer Mozilla one
more chance to reply privately, else the Fedora Project will make the contents
of the letter into an open letter, published prominently. This will be done in
the hopes of involving other distributions and entities that value user freedoms
to support us in this effort.
We would like to have this discussed and (hopefully) approved during the Council
meeting this Monday, February 29th, so that we can contact Mozilla with a
deadline of March 10th to reply.
The original letter:
Subject: Mozilla Firefox Extension Signing
==========================================
Greetings, Mozilla Foundation,
Members of the Fedora Project have recently raised concerns about the state of
Firefox extensions in version 43 and later. As you are aware, beginning with
Firefox version 43, only those extensions which have been signed by the Mozilla
Foundation and published on addons.mozilla.org are permitted to be installed
and used.
We are aware of the set of problems that Mozilla is attempting to solve with
the implementation of this new policy. You want to help users avoid installing
malware or other harmful, insecure or privacy-violating software. This is a
noble goal and one that we agree is worth pursuing.
However, this new policy in Firefox has made a number of things very difficult
for Fedora and (presumably) other Free Software distributions. The requirement
for package signing effectively prevents the Fedora project from offering
distribution packages for any extensions. There are multiple reasons that such
packages are made available:
* Users of Fedora may trust the distribution to sign their packages, but be
unwilling to extend that trust to individual upstreams, regardless of
Mozilla's relative reliability.
* The Fedora Project or a downstream remix might wish to ship certain
extensions to Firefox by default. A hypothetical example might be an
extension to manage login to the Fedora Project family of web services.
Another such example would be for us to ship with a security-enhancing
extension such as "HTTPS Everywhere" in the default configuration.
* A business might wish only to install packages provided by the distribution
onto their users' systems (this is particularly common among users of
enterprise distributions).
Furthermore, though the current policies on how an extension gets approved or
denied are quite good and transparent, some have expressed concern that at some
point this will change or be enforced incorrectly, resulting in denials of
useful extensions from distribution.
Representing the Fedora Project, we would like to request that Mozilla consider
implementing (or accepting patches from us to implement) one or more of the
following potential mitigating approaches:
* Firefox does not mandate signature checking for system-installed extensions.
- Only an administrative user (e.g. root) has privilege to install system-
wide extensions, and this user already has ultimate power by installing an
alternative Firefox build if malice was their goal.
* Firefox retains the option of disabling signature checking for its
extensions. A permissible compromise here would be for this feature to be
unavailable to ordinary users, but configurable only in the system-wide
configuration by an administrative user.
* Firefox adds the ability for the system administrator to add and remove
signing authorities that signature checking will honor. Fedora (and other
distributions) could then choose to ship with their own signing certificate
enabled by default.
- This is our preferred solution, as it should be the most robust and the
most in keeping with Mozilla's goals.
- This option would also therefore permit an administrator to add a signing
authority for private extensions or extensions under development.
Mozilla and the Fedora Project have had a long and mutually productive
relationship, so I am confident that we can work together to discover a way
forwards that will satisfy both the user-safety concerns as well as the ability
for users and distributions to run the software of their choosing.
Sincerely,
The Fedora Engineering Steering Committee
* Josh Boyer
* Kevin Fenzi
* Stephen Gallagher
* Haïkel Guémar
* Dennis Gilmore
* Kalev Lember
* Adam Miller
* Parag Nemade
* Jared Smith
as well as Matthew Miller, the Fedora Project Leader
8 years, 2 months
Council meeting on Feb-29th - apology
by Jan Kurik
Hi,
I am on PTO from Feb-29 to Mar-04, so I will not be present on the
Council meeting on Monday.
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
8 years, 2 months
cancel meeting today?
by Matthew Miller
I'm still recovering from travel, and came back to a day already booked
full of meetings. (Whoo?)
We've reached the end of the schedule I'd set forth anyway, so time
to make a new one -- I'll do that sometime this week.
Are there particular subprojects people would like to hear updates from
in the coming months?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 2 months
Fedora directions and priorities in 2016
by Matthew Miller
The beginning of a the new year is a good time for reflection... (even if
it is in the last few hours of January).
Over on the new CommOps team, there's a great initiative for all our
various Fedora subprojects to look back at successes for 2015 — see
https://communityblog.fedoraproject.org/share-your-year-in-review-with-fe...
Here, I'd like to discuss what we want to do _this_ year. What would the
ideal 2016 look like for Fedora? What do we collectively want to accomplish,
both in the big picture and in specific areas which will have big impact?
I have some ideas for things I think are important, but most of all I'd like
to have a discussion of all our thoughts as a community, and then the
Council can work on a short summary of the top points which we can refer to
throughout the year (and reflect back on once we've made it to 2017).
--------------------------------------------------------------------------
Here's what I'm thinking about:
Fedora Hubs (or, Up from the Depths of the Internet!)
=====================================================
For several years, I've been talking about Fedora's online presence as a
like the proverbial iceberg — it's mostly lurking beneath the surface.
Our primary engines for interaction are email and IRC (and we use a _lot_ of
both... stay tuned for some future posts on metrics around these things!).
Both tools are awesome and productive, but we also need a modern, visible
online "home". I want it to feel like the excitement and recharging energy
of Flock or FUDCon, all the time.
So, enter the "Fedora Hubs" concept. If you haven't heard about this before,
read more at:
* https://fedoraproject.org/wiki/Fedora_Hubs
* https://pagure.io/fedora-hubs
* http://blog.linuxgrrl.com/2015/07/01/fedora-hubs-update/
This year, let's see it become reality.
Initiatives for Project Growth
==============================
I'm working on a "State of Fedora" talk for DevConf.cz, and one of the
things that I'm happy to report is that our metrics are showing a lot of
real growth over the past year. Fedora 20 was a very successful release — one
of our most popular ever. But, the early numbers didn't really show an
overall increase in popularity — more, a flat line with the popularity maybe
explained by people upgrading from early releases. But the numbers for F21,
F22, and now F23 show continuing growth. For 2016, let's take that and run
with it.
First, we need to really step up our active marketing. Hitting the tables at
traditional Linux events isn't bringing in new users and contributors like
it might have in the early days. With the Three Editions strategy, we have
the beginning. Each edition has a target market and userbase defined. This
year, let's go beyond just making an awesome OS release and hoping people
will notice. Let's find where we can solve real problems people have with
their existing developer's workstation, small server environment, and in
cloud computing - bring real problems back, solve them, and get a real cycle
of feedback and growth.
Let's make sure that at key conferences and meetups, we have people talking
about great things that Fedora enabled them to do - not just about Fedora
itself. We have an initiative for better university involvement, and while
that's still getting off the ground, it has a lot of potential and can fit
right in, since student developers are part of the Workstation target, and
it's important to get the next generation of developers doing _their_ cool
stuff with Fedora.
Read more on this in the "PRDs" for each edition:
* https://fedoraproject.org/wiki/Workstation/Workstation_PRD
* https://fedoraproject.org/wiki/Cloud/Cloud_PRD
* https://fedoraproject.org/wiki/Server/Product_Requirements_Document
and this on the University Involvement objective:
* https://fedoraproject.org/wiki/Objectives/University_Involvement_Initiative
Making Fedora Atomic "Primary"
==============================
Continuing on the Editions marketing strategy... when we came up with that
idea, cloud computing was one of the key strategic areas we identified. The
idea of the Cloud Base image as it stands was to provide a minimal platform
on which people deploying to the cloud could add various software stacks and
create their own solutions. I think we did a fine job with that technically,
but it wasn't exciting enough to make anyone who didn't want to use Fedora
already take notice. It's good, but there's nothing _really_ compelling to
make someone make it their first choice.
With Atomic, though, I think we now have that. So, as a tweak to the
Editions strategy, I want to replace Cloud with Atomic. This addresses the
same scale-out commodity computing area, but does it in new, interesting
ways with technology that is really breaking new ground. (For people who
want the traditional cloud image, we can still keep making that as basically
something akin to a Spin, and if people are interested enough possibly
provide a Fedora Server variant of that as well, for easy launch of more
"pet-like" servers into public cloud providers.)
We talked about this at the last Flock - and in 2016, let's do it.
More about Project Atomic, Fedora Atomic's current every-two-week
releases, and a longer version of what I just said above:
* http://projectatomic.io/
* https://getfedora.org/en/cloud/download/atomic.html
* https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.o...
Making Modularization Mean Something
====================================
And finally, also in the category of "something I've been talking about for
a while, but now let's do something"... this idea of a more modular Fedora.
My "Fedora Rings" talk at Flock in Charleston two and a half years ago
proposed that a more loosely-coupled system would allow for better growth
into the next decade. It's one of those things that's easier said than done.
A more modular construction of the Fedora package collection, rather than
one big unified repo, would provide a number of advantages. We could
consider a longer lifecycle for select configurations of Fedora Server.
Fedora Workstation releases might be synchronized with upstream GNOME
releases, without either blocking other changes or being blocked on them. In
cases where size matters, we could have better management of the hundreds of
megabytes (literally!) of constantly-churning metadata. And we could better
provide multiple versions of software stacks, without the massive
duplication of effort this requires now.
I've started to see some people with concrete ideas of what this might look
like. This year, let's see some actual prototypes for these ideas. They
might not all work, and some might be terrible - but others could be great.
Let's find out!
----------------------------------------------------------------------------
These are things I'm thinking about. But of course it's not all about me.
What do *you* want for Fedora this year?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8 years, 2 months
