[RFC] Replace glibc's libcrypt with libxcrypt for Fedora 29/30
by Björn 'besser82' Esser
Hello everyone,
since there has been some discussion in the last time about removing
libcrypt from glibc in some time [1,2,3,4] and splitting it out into a
separate project which can evolve quicker, I'd like to hear your
oppinion about replacing glibc's libcrypt with libxcrypt [5] for Fedora
29 (or 30).
libxcrypt will be fully binary compatible with software linked against
glibc's libcrypt and does not require any rebuilds. However, the
converse is not true: programs linked against libxcrypt will not work
with glibc's libcrypt. It comes with a set of extended interfaces
pioneered by Openwall Linux, crypt_rn, crypt_ra, crypt_gensalt,
crypt_gensalt_rn, and crypt_gensalt_ra. Also, programs that use
certain legacy APIs supplied by glibc's libcrypt (encrypt, encrypt_r,
setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.
The crypt and gensalt functions are supporting all (except for Crypt16,
which was used on Ultrix and Tru64, only) widely used password hashing
algorithms [6], which before were specific to just some operating
system's implementations of libcrypt [7].
There are preperations to add password hashing with PBKDF2 using HMAC-
SHA3-512 to libxcrypt as well.
Anyways, before this can happen, there is still some work to be done
with libxcrypt, like adding a FIPS mode or FIPS compliance in a
different way.
Cheers,
Björn
[1] https://sourceware.org/ml/libc-alpha/2017-06/msg00055.html
[2] https://sourceware.org/ml/libc-alpha/2017-06/msg00079.html
[3] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
[4] https://sourceware.org/ml/libc-alpha/2017-08/msg01408.html
[5] https://github.com/besser82/libxcrypt
[6] https://en.wikipedia.org/wiki/Crypt_(C)#Key_derivation_functions_s
upported_by_crypt
[7] https://en.wikipedia.org/wiki/Crypt_(C)#Support_in_operating_syste
ms
6 years
Orphaning ofono
by Rex Dieter
I will be orphaning the ofono package today. I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.
Recently updated to latest 1.22 release which fixed a long-standing FTBFS
issue, so at least it is in good shape for anyone interested in picking it
up.
-- Rex
6 years
COPR src.fp.o auto-rebuilds
by Michal Novotny
Hello,
you can now very easily setup auto-rebuilds for your src.fp.o package:
1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork
(please, use the https:// cloning option)
2) make sure "Webhook Rebuild" checkbox is checked when you are creating
the package
3) Go to settings for your package at src.fp.o and almost at the bottom in
Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update"
button.
If your package is a main package (not a fork), then you can omit step 3.
See https://pagure.io/copr/copr/issue/142 for more info.
COPR team
6 years, 1 month
[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
by Igor Gnatenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.
Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies
The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.
If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.
Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).
List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-----END PGP SIGNATURE-----
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
6 years, 1 month
Unannounced soname bump (Rawhide): qpdf (libqpdf.so.18 ->
libqpdf.so.21)
by Adam Williamson
qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26.
This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 .
This soname bump was not announced, as it is supposed to be, and
dependent packages were not rebuilt.
cups-filters depends on qpdf, so anything that includes cups-filters is
now broken. This includes at least the Astronomy_KDE live image, per
https://pagure.io/dusty/failed-composes/issue/24#comment-496381 .
Once again, folks, *please* announce your soname bumps, and co-ordinate
rebuilds. (In fact it looks like Zdenek is the maintainer of both
packages and could have rebuilt cups-filters, but just forgot to).
I will attempt a rebuild of cups-filters using provenpackager
privileges.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years, 1 month
New "tests" namespace to share test code
by Petr Splichal
Hi!
While working on adding CI tests [0] using the Standard Test
Interface a need arose to have a shared git repository where tests
could be stored:
* A large number of test files makes a dist-git repository more
difficult to maintain
* Tests might follow a different branching pattern than the
dist-git repo, leading to code duplication
* Shared maintenance for tests sometimes benefits from different
access levels than the release dist-git repository
The plan is to create a new “tests” namespace in Fedora git/pagure
dedicated to storing the shared test code. To enable execution of
these tests by the CI pipeline, tests.yml file in dist-git will be
used to link the tests in the standard way as defined by the
Standard Test Interface [1].
This approach should help to efficiently maintain tests & minimize
test code duplication. Using a dedicated git repo for test code
also means to keep dist-git more as a place for storing metadata
only: Build metadata (spec file = how to build the package) and
test metadata (tests.yml = how to test the package) rather than
mixing spec files with test code itself.
Please note that this does not mean that all tests should now go
into this new namespace. You can still link tests directly from
upstream (like GitHub) or any other source. Also, for unit tests
it makes more sense to be kept directly with the project source
and executed there. Shared tests namespace in Fedora will be
suitable especially for functional and integration testing which
should help to continuously ensure the OS works as a whole.
For more detailed motivation and real-life examples see the Share
Test Code proposal on the Fedora CI list [2]. If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:
https://pagure.io/fedora-infrastructure/issue/6478
Thanks.
psss...
[0] https://fedoraproject.org/wiki/CI
[1] https://fedoraproject.org/wiki/Changes/InvokingTests
[2] https://lists.fedoraproject.org/archives/list/ci@lists.fedoraproject.org/...
6 years, 1 month
F29 System Wide Change: Enable dbus-broker
by Jan Kurik
Proposed System Wide Change: Enable dbus-broker
https://fedoraproject.org/wiki/Changes/EnableDbusBroker
Owner(s):
* David Herrmann <dh dot herrmann at gmail dot com>
* Tom Gundersen <teg at jklm dot no>
Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.
== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial
[https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
announcement] of dbus-broker. An excerpt:
* [https://github.com/bus1/dbus-broker/wiki/Accounting Accounting]:
dbus-broker maintains per-user accounting, including inter-user
quotas. This guarantees that no single user can cause irregularly high
memory consumption in the daemon. Unlike dbus-broker, dbus-daemon
accounts memory in a multi-tier system, based on plain resource
counters on users, connections, and other resources. The multi-tier
system suffers from resource-chaining-exhaustion, where clients
effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The [https://github.com/bus1/dbus-broker/wiki/Accounting
single-tier accounting] scheme of dbus-broker avoids this, while at
the same time adding inter-user quotas to prevent misuse even across
clients.
* [https://github.com/bus1/dbus-broker/wiki/Reliability Reliability]:
While D-Bus is used on reliable transports, dbus-daemon might still
silently drop messages and given circumstances. This is the only
possible solution dbus-daemon has, given several of its runtime
guarantees. The dbus-broker project changed the architecture of the
bus daemon to a degree, that it can provide many
[https://github.com/bus1/dbus-broker/wiki/Reliability guarantees],
including that no message will be silently, or unexpectedly, dropped.
* [https://github.com/bus1/dbus-broker/wiki/Scalability Scalability]:
The message bus broker is a crucial infrastructure on modern linux
system, which is a hot-path for almost all IPC going on. Hence, the
broker should perform fast and be scalable to its users. dbus-daemon
has several **global** data-structures that affect the overall
scalability of independent message transactions. dbus-broker does not
employ any global data-structures (unless required by the spec), as
such any message transaction is only affected by the data provided by
the involved peers. Moreover, even for spec-defined global behavior,
dbus-broker avoids global data-structures, unless clients actually
make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.
* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.
== Scope ==
* Proposal owners:
** Fix regressions.
** Enabledbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.
* Other developers:
** Watch for regressions
* Release engineering:
[https://pagure.io/releng/issues/7262 #7262]
** List of deliverables:
N/A
* Policies and guidelines:
No changes needed.
* Trademark approval:
No changes needed.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
by Jan Kurik
= System Wide Change: Replace glibc's libcrypt with libxcrypt =
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Change owner(s):
* Björn Esser <besser82 AT fedoraproject DOT org,>
* Florian Weimer <fweimer AT redhat DOT com>
There are plans to remove libcrypt from glibc, so we should have a replacement.
== Detailed Description ==
Since there has been some discussion in the last time about removing
libcrypt from glibc in some time and splitting it out into a separate
project which can evolve quicker, Zack Weinberg and I put some work
into libxcrypt to make it a basically suitable replacement.
It comes with a set of extended interfaces pioneered by Openwall
Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and
crypt_gensalt_ra.
The crypt and gensalt functions are supporting all (except for
Crypt16, which was used on Ultrix and Tru64, only) widely used
password hashing algorithms, which before were specific to just some
operating system's implementations of libcrypt.
== Scope ==
* Proposal owners:
- Apply needed packaging changes to glibc
- Review, import and build libxcrypt for Fedora 28
* Other developers:
Test their applications using one of the following interfaces for
unexpected changes in functionality:
- crypt()
- crypt_r()
- encrypt()
- encrypt_r()
- fcrypt()
- setkey()
- setkey_r()
Release engineering:
#7160 https://pagure.io/releng/issue/7160
none expected
* Policies and guidelines:
N/A (not needed for this Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month