Proposed F19 Feature: Shared System Certificates
by Jaroslav Reznik
= Features/SharedSystemCertificates =
https://fedoraproject.org/wiki/Features/SharedSystemCertificates
Feature owner(s): Kai Engert <kaie(a)redhat.com>, Stef Walter <stefw(a)redhat.com>
Make NSS, GnuTLS, OpenSSL and Java share a default source for retrieving
system certificate anchors and black list information. This is an initial
but useful step in the direction of a comprehensive solution.
== Detailed description ==
The goal is to have a systemwide trust store of static data, that is used by
crypto toolkits as input for certificate trust decisions.
By default, the trust store will continue to contain the trust list as
published by the Mozilla CA Certificate list (but use of others are possible),
including positive and negative trust (blacklists). The system will allow
updating of the core Mozilla CA list. The trust list can be adjusted, added
to and overridden by administrators.
There will be a global directory that is scanned for input files, which will
include the RPM-package-owned Mozilla trust bundle, and which may contain
any number of additional files.
In order to achieve this, the following implementation would be used.
Much of the upstream implementation of this is p11-kit and can be shared with
other distros.
This initial implementation is a step towards a later more comprehensive
representation of locally stored trust policy information. The upstream
p11-kit project has more information on the long term concept.
p11-kit will provide a PKCS#11 trust module which provides trust information
based on a directory of certificates, some of which may have trust information
attached.
The PEM trusted certificate file format is supported here, as are others.
p11-kit will provide a tool to extract information from the PKCS#11 trust
module in the following formats:
Extract to a CA PEM bundle with TRUSTED CERTIFICATE information for OpenSSL.
Extract to a dirhash style directory for OpenSSL.
Extract to a CA bundle with plain certificates, for serverAuth,
clientAuth, etc.
Extract to the Java cacerts file.
This tool uses the PKCS#11 module as its source of trust information,
allowing future work to build off of this effort.
This tool is an interim bridge between OpenSSL, GnuTLS and Java until
they are able to read PKCS#11 trust information directly.
NSS: Uses the above PKCS#11 trust module directly to pull in trust information.
The PKCS#11 trust module is a drop in replacement for libnssckbi.so.
We can use update-alternatives to manage this drop in replacement.
NSS using applications would not need to be changed to work with this
module.
OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the
PKCS#11 trust module.
These extracted certificates will be placed in a location so that they
can be consumed by OpenSSL by default.
The aim is that neither OpenSSL nor OpenSSL applications will have to
be changed for this to work.
In the long term future we hope that we can build a bridge so that
OpenSSL can consume trust information directly from the PKCS#11 trust module.
GnuTLS: The p11-kit tool tool will extract a CA bundle to be used by GnuTLS
from the PKCS#11 trust module.
This CA bundle would be placed in the location where most GnuTLS
applications today are configured to use it.
It would pull out all the certificates that are trusted for serverAuth
since GnuTLS does not yet provide a way to consume detailed usage directly.
Black listed certificates would obviously not be included in this bundle.
We are working with GnuTLS can consume trust information from the PKCS#11
trust module in the future.
Java: The p11-kit tool will extract a Java compatible cacerts file from the
PKCS#11 trust module.
Again it is our aim that this changes later, once we can provide a bridge
for java to load trust information from PKCS#11.
The recurring theme is that the PKCS#11 trust module is the source of trust policy
information. Over time, (but not in this Fedora release) there will be:
Work done to both make the trust module have a comprehensive model of stored
trust policy.
Steps taken to make it possible to use GnuTLS, OpenSSL and Java directly with
that stored trust policy.
Obviously applications can continue to use their own CA list as appropriate,
for example in servers such as httpd or postfix.
For more information:
http://p11-glue.freedesktop.org/sharing-trust-policy.html
http://p11-glue.freedesktop.org/trust-module.html
10 years, 10 months
Proposed F19 Feature: Guile2
by Jaroslav Reznik
= Features/Guile2 =
https://fedoraproject.org/wiki/Features/Guile2
Feature owner(s): Jan Synacek <jsynacek(a)redhat.com>
Update GNU Guile to version 2.0.x in Fedora 19.
== Detailed description ==
Current guile package will be upgraded to 2.0.x.
compat-guile18 package will provide additional time for the
packages to be ported to guile-2.0.x.
10 years, 10 months
Proposed F19 Feature: FreeIPA v3 Trust Improvements
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/IPAv3TrustImprovements =
https://fedoraproject.org/wiki/Features/IPAv3TrustImprovements
Feature owner(s): Alexander Bokovoy <abokovoy(a)redhat.com>
Multiple Domain Controllers and multiple additional DNS domains managed by
FreeIPA can now be accessible via trusting relationship by Active Directory
domain members. Additionally, Global Catalog service is provided for use by
AD clients, allowing FreeIPA users to be included into access-control lists
of AD resources.
== Detailed description ==
In Fedora 18 only a single designated Domain Controller in FreeIPA realm is
supported for interoperability with Active Directory and only a primary DNS
domain associated with the FreeIPA realm is advertised to the trusted party.
With the changes coming in future FreeIPA release, support for multiple
domain controllers per FreeIPA realm and multiple DNS domain suffixes associated
with the realm will be available. FreeIPA will also provide Global Catalog
service implementation which is key feature to allow discretionary access to
Active Directory resources for FreeIPA users --- making possible, for example,
interactive logon to Windows machines under a FreeIPA identity.
10 years, 10 months
Moving unmaintained features from PackageDB to other apps
by Toshio Kuratomi
Dear all,
After many years of API compatibility, it is time for us to start making
changes to the Fedora PackageDB[0] that change the API and the features that it
makes available. In two weeks we'll be pushing the first update that starts
us down this path. In this update most users of the PackageDB as an API
won't notice any changes. However, users of the PackageDB web UI will see
a major change. The AppDB that was added a few years ago has been removed.
This means that information about builds in the download repositories,
applications in Fedora, tags, and user ratings have been removed from the
PackageDB interface.
Some of these have already been migrated to the packages [1] and tagger
apps[2]. Others will bee added there in the future.
This change is anticipated to go live in two weeks, February 4th.
[0]: https://admin.fedoraproject.org/pkgdb/
[1]: https://apps.fedoraproject.org/packages/
[2]: https://apps.fedoraproject.org/tagger/
-Toshio
10 years, 10 months
F19 upgrade ICU to 50.1.1 in sync with Boost upgrade
by Eike Rathke
Hi,
I plan to upgrade ICU to version 50.1.1, best next week to have that
ready before the Boost upgrade will happen to avoid having to rebuild
the entire chain twice. So don't get overly alarmed by broken
dependencies of other packages.. but still fix them in time for the
Boost upgrade.
Thanks
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
10 years, 10 months
Proposed F19 Feature: Replace MySQL with MariaDB
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/ReplaceMySQLwithMariaDB =
https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB
* Detailed description:
MariaDB is a fork of the MySQL database project that provides a drop-in
replacement for MySQL. It preserves API/ABI compatibility with MySQL and
adds some new features.
The original company behind MySQL, MySQL AB, were bought out by Sun which was
then bought by Oracle. Recent changes made by Oracle indicate they are moving
the MySQL project to be more closed. They are no longer publishing any useful
information about security issues (CVEs), and they are not providing complete
regression tests any more, and a very large fraction of the mysql bug database
is now not public.
MariaDB, which was founded by some of the original MySQL developers, has a more
open-source attitude and an active community. We have found them to be much
easier to work with, especially in regards to security matters.
We would like to replace MySQL with MariaDB in early development cycle for
Fedora 19. MySQL will continue to be available for at least one release, but
MariaDB will become the default. Also, we do not intend to support concurrent
installation of both packages on the same machine; pick one or the other.
10 years, 10 months
Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/GCC48 =
https://fedoraproject.org/wiki/Features/GCC48
* Detailed description:
GCC 4.8.0 is going to be released in mid March to mid April and is currently
in regression bugfix only mode. I've performed a test mass rebuild on x86_64
with gcc-4.8.0-0.1.fc19, out of 12712 packages 11687 built successfully, 933
packages failed to build both with gcc-4.8.0-0.1.fc19 and gcc-4.7.2-9.fc19
(thus unlikely gcc related), 67 packages failed due to issues on the side of
the packages, 22 failed due to bugs on the gcc side that should be fixed
already in gcc-4.8.0-0.3.fc19 and 3 failed due to issues still to be fixed
on the GCC side.
See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html
for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks
a mass rebuild should be performed.
10 years, 10 months
Proposed F19 Feature: BIND10 - next generation of the popular BIND9 DNS server rewritten from scratch
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/BIND 10 =
https://fedoraproject.org/wiki/Features/BIND10
* Detailed description:
BIND10 suite implements two crucial network services - DNS and DHCP.
The BIND10 is going to replace both widely used ISC BIND9 and ISC DHCP4
software in the future. It is written from scratch and has modular design.
The main advantages are:
- modular design
-- authoritative nameserver runs in separate processes. Bug in supplementary
process won't affect availability of the server domain
-- b10-ddns (DDNS service), b10-xfrin (incomming zone transfers), b10-xfrout
(outcomming zone transfers), b10-stats (statistics)
-- recursive server runs as separate process (b10-resolver)
- modern design, improved scalability
- officially supported SQL database backends (only SQLite currently but
MySQL and PostgreSQL are planned)
10 years, 10 months
Proposed F19 Feature: Boost 1.53 Uplift - brings Boost 1.53.0 to Fedora 19
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/F19Boost153 =
https://fedoraproject.org/wiki/Features/F19Boost153
* Detailed description:
That feature aims at synchronising the top of the Fedora tree with the
current Boost upstream release. The current Fedora release is boost-1.50.0.
As of Fedora 13, the canonical sources used for the package switched from
the official Boost release (with BJam build) to an alternate repository
(with CMake build, for boost-1.41.0). That alternate repository has been
deprecated and may be deleted any time soon (as of January 2013).
boost-1.41.0 has been delivered from that (now deprecated) Boost-CMake
repository (hosted on Gitorious), where the code base had slightly diverged
from upstream.
>From Fedora 14, boost-1.44.0 has been rebased on upstream, with a mere patch
implementing CMake support. Moreover, there is a new Git repository reflecting
those changes, hosted on GitHub (and cloned on Gitorious). That repository
relies on the Ryppl project (in particular, on the Boost Subversion replicated
repository), created and maintained by two Boost developers, namely Eric
Niebler and Dave Abrahams.
>From Fedora 18, boost-1.50.0 was rebased back to Boost.Build v2, as keeping
two distinct build systems sometimes conducted to two distinct binary
distributions, for instance, when compared to Debian/Ubuntu deliveries.
Note that upstream Boost has decided, at the end of 2012, to switch to:
Git repository, with GitHub as one of the main hosting services and project
management facilities
(later on, when the switch to Git will be stable enough) a modularized
organisation, and
CMake as the primary build system, replacing BJam/BBuild
The objective is now to keep delivering the latest stable Boost release for
each new Fedora release.
10 years, 10 months
Proposed F19 Feature: RemovePyXML - the goal of this Feature is to remove the PyXML package from Fedora
by Jaroslav Reznik
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/RemovePyXML =
https://fedoraproject.org/wiki/Features/RemovePyXML
* Detailed description:
PyXML has been dead upstream for many years. The main authors of it have
stated this explicitly on the python-dev mailing list. It's successor,
the python stdlib's xml module, has been getting bugfixes that PyXML has not.
The current Fedora package maintainer (rrakus) asked about removing it in
February, 2012.
The Python stdlib in python2.x also has the dubious behaviour of importing PyXML
if it is installed and replacing its own code with PyXML's. In some cases, this
leads to bugs (For instance: Eric bug, Docutils bug) as the old PyXML code does
not cope with some usages that the version in the stdlib does.
We want to remove this package from Fedora. To do that we need to decide what
happens to the packages that depend on it. After analyzing the packages that
use it, most of them will be ported to another xml library as part of this
Feature. However, a few packages will be dropped from Fedora instead.
--
PS: CC'ing the maintainer of PyXML, he's aware of this Feature and he is ok
with the proposal
10 years, 10 months
