libgcrypt soname bump in rawhide
by Tomas Mraz
I'm rebasing libgcrypt in rawhide to libgcrypt-1.6.1. The new upstream
release contains many improvements over the old one especially in terms
of new crypto algorithm support and performance improvements.
Unfortunately the rebase bumps soname to libgcrypt.so.20 due to dropping
some long-ago deprecated API calls. This should not break builds of any
reasonably current software. I've included the temporary old shared
library so the buildroots are not broken.
I will try to rebuild the dependencies eventually.
Regards,
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
9 years, 3 months
F21 System Wide Change: System-wide crypto policy
by Jaroslav Reznik
= Proposed System Wide Change: System-wide crypto policy =
https://fedoraproject.org/wiki/Changes/CryptoPolicy
Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com>
Unify the crypto policies used by different applications and libraries. That is
allow setting a consistent security level for crypto on all applications in a
Fedora system.
== Detailed Description ==
The idea is to have some predefined security levels such as LEVEL-80,
LEVEL-128, LEVEL-256,
or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
security levels
that the administrator of the system will be able to configure by modifying
/usr/lib/crypto-profiles/config
/etc/crypto-profiles/config
and being applied after executing update-crypto-profiles.
(Note: it would be better to have a daemon that watches those files and
runs update-crypto-profiles automatically)
After that the administrator should be assured that any application
that uses the system settings will follow a policy that adheres to
the configured profile.
Ideally setting a profile should be setting:
* the acceptable TLS/SSL (and DTLS) versions
* the acceptable ciphersuites and the preferred order
* acceptable parameters in certificates and key exchange, i.e.:
** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA)
** the acceptable elliptic curves (ECDH,ECDSA)
** the acceptable signature hash functions
* other TLS options such as:
** safe renegotiation
An idea of how this will be implemented is to have each Fedora application's
configuration
file or compilation option will set a system default option. That is for
example for
applications that use GnuTLS or OpenSSL a priority string or cipher named
"SYSTEM".
Then the shipped library will make sure that once the "SYSTEM" option is
encountered
the preconfigured system settings will be applied.
The preconfigured settings for each SSL library will be auto-generated
from the default profile in
/etc/crypto-profiles/generated/$(libname)/config
== Scope ==
There are changes required in GnuTLS, OpenSSL and NSS libraries. On a second
phase non-SSL crypto libraries could use these settings.
* Proposal owners: For GnuTLS and OpenSSL the "SYSTEM" cipher needs to be
understood and behave as described. For NSS the NSS_SetDomesticPolicy() can be
overloaded to behave as above.
After that a mechanism to specify crypto policies for Fedora has to be
devised, as well as the extraction to each libraries' settings.
* Other developers: Packages that use SSL crypto libraries should, after the
previous change is complete, start replacing the default cipher strings with
SYSTEM.
* Release engineering: This feature does not require coordination with release
engineering.
* Policies and guidelines: After the change is complete the packaging
guidelines, should mention above replacing the default cipher strings with
"SYSTEM". This of course need not affect programs that do not have a mechanism
for setting ciphers/modes that is already in wide use (e.g., browsers). It
mostly targets applications that use some reasonable (or unreasonable)
defaults and the user/administrator has little control of them.
9 years, 3 months
F21 System Wide Change: Ruby 2.1
by Jaroslav Reznik
= Proposed System Wide Change: Ruby 2.1 =
https://fedoraproject.org/wiki/Changes/Ruby_2.1
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>
Ruby 2.1 is the latest stable version of Ruby, with major increases in speed,
memory efficiency and reliability. With this major update from Ruby 2.0.0 in
Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the
superior Ruby development platform.
== Detailed Description ==
Ruby 2.1 is upstream's new major release of Ruby. Notable changes are:
* VM (method cache)
* RGenGC
* refinements
* syntax changes
** Rational/Complex Literal
** def’s return value
* Bignum use GMP
* String#scrub
* Socket.getifaddrs
* RDoc 4.1.0 and RubyGems 2.2.0
* “literal”.freeze is now optimized
* add Exception#cause
* update libraries like BigDecimal, JSON, NKF and Rake
* remove curses
Please also note, that Ruby moved to semantic versioning since this version.
Yet, it is source level backward compatible with Ruby 2.0.0, so your software
will continue to work.
== Scope ==
* Proposal owners:
** Update of Packaging Guidelines for Ruby packages. This needs to reflect
recent changes introduced by recent version of RubyGems shipped with Ruby 2.1.
** Rebuilding of Ruby packages providing native extensions (i.e. packages
which depends on libruby), including changes needed by updated packaging
guidelines.
* Other developers: N/A
* Release engineering:
** Rebuilding of Ruby packages providing native extensions (i.e. packages
which depends on libruby), including changes needed by updated packaging
guidelines.
* Policies and guidelines:
** Update of Packaging Guidelines for Ruby packages. This needs to reflect
recent changes introduced by recent version of RubyGems shipped with Ruby 2.1.
9 years, 3 months
F21 System Wide Change: Access control in PCSC
by Jaroslav Reznik
= Proposed System Wide Change: Access control in PCSC =
https://fedoraproject.org/wiki/Changes/PcscAccessControl
Change owner(s): Nikos Mavrogiannopoulos <nmav(a)redhat.com>
Add access control to PC/SC smart cards available in the system. Adding access
control would (a) prevent unauthorized processes/users from reading data on a
smart card, (b) prevent unauthorized processes/users from erasing a smart
card, (c) prevent unauthorized processes/users from talking to the smart card
firmware.
== Detailed Description ==
Add access control to PC/SC smart cards available in the system. Currently
smart cards may provide their own access control for certain elements of a
card such as a private key. Their access control method is typically a PIN,
but can also be a biometric based one. That however, is not sufficient to
prevent certain actions on the non-PIN protected elements. For example cards
that provide a PKCS #15 filesystem can be modified by anyone that has access in
the system (e.g., erased using pkcs15-init -E).
The default settings allowed should be similar to the default settings for
hard disks, i.e., root and the user in console should be able to access the
smart card.
Adding access control would
* prevent unauthorized processes/users from reading data on a smart card
* prevent unauthorized processes/users from erasing a smart card
* prevent unauthorized processes/users from talking to the smart card firmware
The way access control will be implemented is using polkit which is already
being used to control access to hard disks. As smart cards share a lot with
hard disks (e.g., a filesystem, and are inserted by the console user), sharing
the same access control method is beneficial.
== Scope ==
polkit support has to be added to PC/SC daemon. An initial version has already
been developed and communicated upstream
* Proposal owners: The polkit support has to be merged with the Fedora
package. That requires changes to the pcsc daemon only, but indirectly all
packages that potentially may use smart cards are affected (opensc, firefox,
...).
* Other developers: Packages that use PC/SC smart cards must be checked that
they work as expected after the access control change.
* Release engineering: No coordination is required.
* Policies and guidelines: If there is any security policy documentation
should be updated to include the new policies on smart cards (I couldn't find
any such documentation though)
9 years, 3 months
F21 System Wide Change: Remove python-setuptools-devel
by Jaroslav Reznik
= Proposed System Wide Change: Remove python-setuptools-devel =
https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel
Change owner(s): Toshio Kuratomi <toshio(a)fedoraproject.org>
The python-setuptools package has carried a virtual Provide for python-
setuptools-devel since 2009 for backwards compatibility. We're going to remove
this virtual Provide. Packages which still BuildRequire python-setuptools-
devel will need to be updated to Require: python-setuptools instead.
== Detailed description ==
In November of 2009, in time for Fedora 13, we solved a packaging issue in the
main python package that allowed us to remove a split in our python-setuptools
package. Instead of needing a separate python-setuptools-devel subpackage for
easy_install the python-setuptools package could now contain all of the
functionality of python-setuptools. To ease with package migration we added an
Obsoletes and Provides tag to the python-setuptools package at that time so
that packages, kickstarts, etc which required python-setuptools-devel would
not break.
Fast forward to the present day:
It's December of 2013. Rawhide is Fedora 21. I'd like to drop the backwards
compatibility Provides (and Obsoletes) from the python-setuptools package.
However, there are currently 151 packages BuildRequire'ing python-setuptools-
devel. This Change exists to make people aware that they need to update their
packages.
== Scope ==
* Proposal owners: Remove the Provides: and Obsoletes: python-setuptools-devel
in the python-setuptools package and rebuild. This will take approximately 30
minutes.
* Other developers: Owners of packagers that BuildRequire: python-setuptools-
devel need to change to BuildRequire: python-setuptools and rebuild.
Individually, this takes approximately 30 minutes per package (but largely
waiting on builds to finish successfully). There are approximately 151 packages
in the
* Release engineering: No action needed by rel-eng. Until other developers
update their BuildRequires, their packages would fail to rebuild in a mass
rebuild.
* Policies and guidelines: No action needed. The packaging guidelines have
already been changed to use BuildRequires: python-setuptools rather than
python-setuptools-devel.
9 years, 3 months
PRDs/Tech Specs to formal Change Proposals and Change submission deadline
by Jaroslav Reznik
Hi,
at yesterday's FESCo meeting, it was agreed on setting deadlines
for Change submission for Fedora 21 [1] and to process PRDs into
Change proposals.
"AGREED: Fedora Changes Process submission deadline for system-wide
changes is April 7th. Deadline for true standalone changes will be
sometime later than that. Changes to how fedora is produced for
fedora.next are still due on March 3rd. (+7,0,0) (nirik, 18:29:42)"
Current deadlines:
* March 3rd: Technical Specifications for products & and changes needed
for products and deliverables --- very soon!
* April 7th: System Wide Changes submission deadline
Working Groups teams, please, try to "transform" required changes for
your products from PRDs/Technical Specifications into standalone
Change proposals (between March 3rd and April 7th). It will help
us to scope the release. Also all changes would be trackable the
standard way we do it and it's going to help transparency (as
Change announcements are being to be part of the process).
Self Contained Changes submission deadline will be set later,
after the System Wide deadline. If you expect your proposed Self
Contained Change will be on the edge and could be escalated to the
System Wide, please try to submit it as early as possible too.
As some Fedora.next details will be clarified later in the process,
System Wide Changes submitted after the deadline will be approved
case by case, even after submission deadline.
For the details about the Change process, see my previous email
to the devel announce list [2].
Thank you for your help with Change process and let me know in
case of any questions.
Jaroslav
[1] https://fedorahosted.org/fesco/ticket/1178
[2] https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/00...
9 years, 3 months
Fedora 21 Change Planning Process
by Jaroslav Reznik
Hi!
As FESCo agreed on the last meeting to continue with current Change
process as is for Fedora 21 [1] and work on "final" schedule is ongoing
(see Stephan Gallagher's mail earlier), please participate and
submit your Change proposals as soon as possible.
With Fedora.next in mind, I'd like to ask even non development teams
to participate in the process. So the progress can be tracked and also
we need better transparency and coordination. Initially, the submission
deadline has not yet been set as we can expect many interdependencies
between Changes and many Changes could be proposed once we will have
more answers from Working Groups and other teams.
Empty template with comments how to fill it properly is available at
https://fedoraproject.org/wiki/Changes/EmptyTemplate
And the process itself is described at
https://fedoraproject.org/wiki/Changes/Policy
I'm going to restart processing Fedora 21 Change proposals asap,
expect pings from me to clarify bits, adjust proposals etc. ;-).
Approved Change Proposals would be available on the Change Set
Page: https://fedoraproject.org/wiki/Releases/21/ChangeSet
Don't hesitate to ask any question, I'll be more than happy to
answer it and help you!
Your Change Wrangler,
Jaroslav
[1] https://fedorahosted.org/fesco/ticket/1236
9 years, 3 months
Help Wanted: Fedora.next schedule estimation
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
tl;dr: FESCo needs to know what is going to need extra time to deliver
Fedora.next in the Fedora 21 cycle.
Now that the Fedora.next product PRDs have been approved, the next
phase is to plan our execution. First of all, this will mean planning
out how to deliver Fedora 21.
In order to accurately scope the Fedora 21 effort, FESCo needs input
from the working groups and the community at large to identify the
major efforts that we will need to account for during this cycle. We
would like to operate under the expectation that we can deliver at
least a first pass at all three of these Products in the Fedora 21
timeframe.
In the previous round of discussion, we agreed that we would have a
F21 release no sooner than August, to guarantee at least that amount
of time for QA and Rel Eng projects. Now it's time to fill in the
details and make the timeline specific.
The goal here is for us to prepare a list of significant material
changes to existing Fedora Project processes in order to deliver this
first pass of Fedora.next products. (If you shouted "Bingo!" while
reading that sentence, I don't blame you). To define this more
clearly, we need to identify what portions of the Fedora community
will need more time than usual to build out tooling or simply execute
more manual steps in order to deliver on three products as opposed to
our more traditional methods. We're not just looking for "we will need
moar testing time!" here. We want specific information and ideally
novel ways to minimize such additional efforts.
For example, if someone told us that QA would have to spend three
times as much effort to validate three Products, we would also want to
hear statements about how much of that work is duplicated and
theoretically automateable. Then we would also want to know how much
additional time would be needed to do that automation in this cycle
(thereby saving much more time in future cycles). FESCo is amenable to
extending the Fedora 21 schedule (within reason) to simplify life in
the future.
As a non-exhaustive list of example things we expect will need
attention and would like input (particularly time-estimates) on:
* Quality Assurance: Coverage increases and automation such as
Task-o-Tron[1]
* Release Engineering: Re-tooling and automation.
* Documentation Team: Impact on creating documentation for three
products.
* Ambassadors: How do we market these new products and do we need to
account for time to deliver marketing materials?
* Websites Team: What sort of redesign work will we need to go through?
* Working Groups: How long to deliver new technologies?
* Marketing: What to distribute to folks at conferences, how to convey
fedora.next to our users.
* Translators: Need to be kept in the loop on any new stuff added that
requires translations.
* Infrastructure: applications changes to meet fedora.next needs or new
applications development to help do so. (bodhi changes, etc)
* Design: consider logos and other needs of products and what it might
take to make them happen.
These are just a few examples. We expect there to be plenty of other
cases that need to be addressed, which is why we would like to hear
them as soon as possible. FESCo will be attempting to determine a
Fedora 21 schedule in the near future and would prefer not to make
this decision in ignorance.
We do not have a formal process in place for organizing such planning
efforts, but as a provisional one, we'd like to take the following steps:
1. Product working groups report on changes they want
2. Other groups also note similar changes they want to see
3. Discussion about what can realistically be done this time around
with various stakeholders (including the list above)
4. Negotiation of how that will affect the product release plans for
f21
5. FESCo will create and publish the schedule
PRDs, Discussion Lists and Freenode IRC Channels:
Fedora Cloud:
https://fedoraproject.org/wiki/Cloud_PRD
cloud(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/cloud
#fedora-cloud
Fedora Server:
https://fedoraproject.org/wiki/Server/Product_Requirements_Document
server(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/server
#fedora-server
Fedora Workstation:
https://fedoraproject.org/wiki/Workstation/Workstation_PRD
desktop(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/desktop
#fedora-workstation
[1] https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMLhRkACgkQeiVVYja6o6OkMgCeJ674UNPKoS542bfN8eGzErS/
EFgAnA4K4/nmGezRbhQFIqFNpBmGz56U
=Bqdm
-----END PGP SIGNATURE-----
9 years, 3 months
Fedora.next update + panel discussion video from DevConf
by Matthew Miller
Video from my presentation about Fedora.next (where it comes from, what it
means to address, why it's important, what we're doing, what you can do,
etc.) and the follow-up panel discussion moderated by Stephen Gallagher and
featuring FESCo WG liaisons (Stephen, Josh Boyer, Marcela Mašláňov, Phil
Knirsch, me):
<http://www.youtube.com/playlist?list=PLzd8cXxlZ8KOcJrNpkZx3trBjaStGIB0s>
I'm working on an article-style summary of this for Fedora Magazine, which
I'll also post to Fedora mailing lists for easier inline discussion, not to
mention faster skimming. But here's the video for now.
There are also a number of other incredibly-relevant and interesting
recordings from the conference at
<http://www.youtube.com/user/RedHatCzech/videos>, many about Fedora
directly, and others about interesting related open source software.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
9 years, 3 months
libicu soname bump in rawhide
by Eike Rathke
Hi,
As pre-announced on devel@ I'm updating libicu to 52.1
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
9 years, 3 months
