devel-announce February 2014

devel-announce@lists.fedoraproject.org

8 participants
13 discussions

libgcrypt soname bump in rawhide
by Tomas Mraz 28 Feb '14

28 Feb '14

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.)

1 0

F21 System Wide Change: System-wide crypto policy
by Jaroslav Reznik 27 Feb '14

27 Feb '14

= 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.

1 0

F21 System Wide Change: Ruby 2.1
by Jaroslav Reznik 27 Feb '14

27 Feb '14

= 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.

1 0

F21 System Wide Change: Access control in PCSC
by Jaroslav Reznik 27 Feb '14

27 Feb '14

= 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)

1 0

F21 System Wide Change: Remove python-setuptools-devel
by Jaroslav Reznik 27 Feb '14

27 Feb '14

= 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.

1 0

PRDs/Tech Specs to formal Change Proposals and Change submission deadline
by Jaroslav Reznik 27 Feb '14

27 Feb '14

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/0013…

1 0

Fedora 21 Change Planning Process
by Jaroslav Reznik 25 Feb '14

25 Feb '14

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

1 0

Help Wanted: Fedora.next schedule estimation
by Stephen Gallagher 24 Feb '14

24 Feb '14

-----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-----

1 0

Fedora.next update + panel discussion video from DevConf
by Matthew Miller 22 Feb '14

22 Feb '14

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>

1 0

libicu soname bump in rawhide
by Eike Rathke 11 Feb '14

11 Feb '14

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce February 2014