Firefox addon signing
by Michael Cronenworth
I'm sure those that need to know, know, but for those that haven't heard[1]
Mozilla's official Firefox build will enforce addons to contain a Mozilla signature
without any runtime option to disable the check.
Initially this prevents Fedora packaged addons since they are unsigned. The Mozilla
signing process takes time and can't be part of a package building process.
Is Fedora going to get authorization to build Firefox with a runtime disable option?
[1] https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experi...
8 years, 7 months
F23 Self Contained Change: RPM MPI Requires Provides
by Jan Kurik
= Proposed Self Contained Change: RPM MPI Requires Provides =
https://fedoraproject.org/wiki/Changes/RpmMPIReqProv
Change owner(s): Sandro Mani <manisandro at gmail dot com>
Have the rpm-build find-provides and find-requires scripts encode the MPI compiler name in the provides string of a binary to distinguish otherwise identical provides between packages $foo, $foo-openmpi and $foo-mpich.
== Detailed Description ==
Currently, the packages libfoo, libfoo-openmpi and libfoo-mpich providing the library libfoo.so all have a provides string of i.e.
libfoo.so()(64bit)
While yum used a shortest-package-name rule to choose which package to pick, dnf does not have any rules, and seems to just pick the first match it comes across. Currently the only solution would be to filter the provides from the -openmpi, -mpich packages and add explicit Requires: where needed. I'd like to propose to extend the provides string in such way that it also encodes the MPI implementation, i.e.:
$ rpm -qp --provides libfoo
libfoo.so()(64bit)
$ rpm -qp --provides libfoo-mpich
libfoo.so()(64bit)(mpich-x86_64)
$ rpm -qp --provides libfoo-openmpi
libfoo.so()(64bit)(openmpi-x86_64)
To this end, I'm proposing to adapt the find-requires and find-provides scripts as (or similarly to):
find-provides
find-requires
Discussion of these changes are tracked in bug #1232504.
This change is intended to coordinate the rebuild of all MPI related packages to ensure all such packages consistently use the new provides format.
== Scope ==
* Proposal owners:
- Work on find-provides and find-requires based on feedback.
- As soon as updated find-provides and find-requires shipped with rpm-build, do a mass-rebuild of all MPI packages.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 8 months
Btrfs as default filesystem for Fedora 23?
by Neal Gompa
Hey all,
Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).
Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
now.
Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast
for my 48TB array).
As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23
<https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html>.
At this point, I'm personally convinced that it is certainly ready and
doable for F23.
Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
The question now is: as a distribution, where are we on this? The tools
seem to work, the filesystem appears stable, and I've not been able to
cause the filesystem to corrupt itself with any kind of user error or cause
it to keel over. So, what's left?
--
真実はいつも一つ！/ Always, there's only one truth!
8 years, 8 months
updating f22 llvm to 3.5.2 release?
by Jens-Ulrik Petersen
Hi,
I opened https://bugzilla.redhat.com/show_bug.cgi?id=1221923
about this too but thought it would be good to ask here.
F22 currently has llvm-3.5.0 (F23 is now on 3.6.0):
I believe there is a newer 3.5.2 bugfix release -
would it make sense to make a F22 update for that?
Is there any expected risk with doing that?
Anyway for F23 I probably have to make a llvm35 package
again for building ghc-7.10 on armv7 (and ideally aarch64).
3.5.0 has a critical bug that breaks ghc, so it would
be based on 3.5.2 anyway.
Jens
8 years, 9 months
dnssec-trigger + GNOME + NetworkManager integration
by Tomas Hozza
Hi all.
I would like to start a new fresh discussion where we can hopefully
converge towards successful integration of default DNS resolver with
NetworkManager on Fedora Workstation (GNOME).
I think there are (at least) two major issues that need to be resolved:
- system-wide Captive Portal detection
- proper UI integration
How is dnssec-trigger integrated with NM
----------------------------------------
I'll start briefly with what dnssec-trigger does and how it is
integrated with NM, so we are on the same boat.
We use Unbound as local DNS resolver that does also DNSSEC validation.
It needs to be configured with proper DNS forwarders in order to do the
validation successfully.
Dnssec-trigger is a daemon and script that reconfigures Unbound
dynamically on every network change (using NetworkManager dispatcher).
In our intended setup, dnssec-trigger handles the content of
/etc/resolv.conf. It gathers all the current configuration from NM using
libnm-glib. This means that we are able to handle any connection that NM
is aware of, including VPNs and split DNS configuration. Our goal is to
do DNSSEC validation whenever possible, therefore we have also public
fallback Fedora infrastructure or DNS resolvers running on port 443.
Since dnssec-trigger handles resolv.conf and reconfigures Unbound, NM's
purpose is to do all the network configuration EXCEPT DNS related
configuration.
Captive Portal
--------------
Dnssec-trigger also handles Captive Portal detection, since this
situation is most of the times DNS spoofing attack and DNSSEC is exactly
the mechanism that should protect users from such attack.
Now we know that we have at least 3 components on the system, that are
trying to do the same thing - Captive Portal detection:
- dnssec-trigger
- NetworkManager
- GNOME Shell
We don't have a problem with turning the detection off, however we need
to agree on system-wide solution that works properly.
We already know that the Captive Portal detection in NM relies on the
system stub resolver, however after our previous discussion I was under
the impression that there are some plans to rework it. Is this correct Dan?
I hope that GNOME Shell somehow only displays the state provided by NM.
Bastien, please correct me if I'm wrong and please elaborate on the
details of what the functionality does (e.g. if you launch a new browser
or so).
In dnssec-trigger the detection is done by resolving a predefined
hostname using DHCP-provided resolvers, downloading a remote file and
then comparing the actual content with what was expected. This may not
be perfect, but is mostly works. The important point is that DHCP
provided resolvers are queried directly, not via system stub resolver.
On the other hand, if NM dispatcher would be able to notify other
services in case of detected Captive Portal, dnssec-trigger would be
able to add the correct DHCP-provided resolver into the resolv.conf for
the purpose of Logging into the Captive Portal. This is mainly due to
the browser window using system's stub resolver.
UI integration
--------------
Now the dnssec-trigger comes with not really well integrated UI
(dnssec-trigger panel) [2]. The panel is written in GTK2 and resides in
the already deprecated status panel (on the bottom of the screen). It is
used mainly for the following interaction with the user:
- Inform the user about Captive Portal, in case there is one (to allow
user to switch into so called "hotspot signon mode") by pop-up window
- enable user to switch to "hotspot signon mode" (basically insecure
mode) manually
- enable the user to reprobe DHCP-provided DNS servers if these are
DNSSEC enabled - meaning to test if these are able to provide all the
data needed for DNSSEC validation.
- inform user in case the local network-provided DNS servers don't
support DNSSEC and the local network blocks outgoing DNS communication
on standard DNS ports and also when tunelled - in other words, user much
choose between insecure mode or disconnecting from the network.
This boils down to what we need from some new version of the UI that we
need to be well integrated with GNOME:
1. Be able to inform user about some situations (Captive portal
detected, network blocks all DNS communication, ...) and enable the user
to take an action. (This could be possibly done by the notifications
system in latest GNOME)
-> this may be solved also in GNOME already, and may be OK if done
technically correctly. Please note my note earlier on NM notifying other
services when Captive Portal is detected
2. Possibly have some indicator showing if the system is in "Secure" or
"Insecure" state.
3. Enable the user to switch between those two states manually
4. Additionally enable the user to trigger the reprobe of
connection-provided DNS resolvers and display result of the probe (last
one).
-> this should not be needed for regular use. It is more of a debugging tool
[1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
[2] http://www.nlnetlabs.nl/projects/dnssec-trigger/#screenshots
I'm all for simple and clean integration. Let's identify specific
solutions and pieces we can start working on.
Thanks.
Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc. http://cz.redhat.com
8 years, 9 months
F23 Self Contained Change: io.js Technology Preview
by Jan Kurik
= Proposed Self Contained Change: io.js Technology Preview =
https://fedoraproject.org/wiki/Changes/iojs
Change owner(s): T.C. Hollingsworth <tchollingsworth at gmail dot com>
io.js is an npm compatible platform originally based on Node.js™ that supports version 6 of the ECMAScript standard and additional features, developed with an open governance model. io.js will be offered as an optional replacement for `/usr/bin/node` on Fedora systems as a Technology Preview. node.js will remain the default implementation of `/usr/bin/node` in Fedora 23.
== Detailed Description ==
io.js is an npm compatible platform originally based on Node.js™ that supports version 6 of the ECMAScript standard and additional features, developed with an open governance model. For more information about io.js and the differences between node.js, visit the io.js website.
io.js will support the same set of binary modules currently supported by node.js on Fedora. It is expected to be obsoleted by a future version of the `nodejs` package, as these two projects have announced their intention to merge.
We will support both parallel-installation of the iojs interpreter alongside the existing node.js interpreter, and permit replacement of `/usr/bin/node` with io.js in an additional package. All existing noarch nodejs-* packages will work with both interpreters. (Though obviously you'll have to specify iojs if you haven't installed it the /usr/bin/node support package.) Seperate nodejs-* and iojs-* will be provided for binary modules.
== Scope ==
* Proposal owners:
-- Package and build a special v8 package for io.js only.
-- Package and build iojs
-- Update nodejs guidelines for multiple interpreters
-- Rebuild modules with above changes
-- Anything that needs updates for Node.js 0.12 will need it for io.js too.
* Other developers:
-- Anything that needs updates for Node.js 0.12 will need it for io.js too.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines:
-- Updates to the node.js guidelines and packaging infrastructure to permit building binary modules for multiple interpreters will be necessary. (These are also necessary to allow for a nodejs010/nodejs012 split in EPEL, so will get done anyway.)
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 9 months
FESCO Elections - June 2015 - Results
by Jan Kurik
Greetings, all!
The elections for FESCo - June 2015 have concluded, and the results
are shown below.
FESCo is electing 4 seats this time.
A total of 90 ballots were cast, meaning a candidate
could accumulate up to 540 votes (90 * 6).
The results for the elections are as follows:
# votes | name
- --------+----------------------
363 | Stephen Gallagher (sgallagh)
294 | Josh Boyer (jwboyer)
293 | Dennis Gilmore (ausil)
274 | Haïkel Guémar (hguemar)
- --------+----------------------
177 | Germano Massullo (germano)
159 | David King (amigadave)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
--
Jan Kuřík
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
8 years, 9 months
