Updating hdf5 to 1.8.16 in rawhide soon
by Orion Poplawski
I'll be updating hdf5 to 1.8.16 in rawhide in the next few days. This
includes a soname bump for the C++ wrapper libs, but as usual I'll be
rebuilding all deps due to run-time version checking by the library.
bes-3.14.0-7.fc24.src.rpm
CBFlib-0.9.5.4-1.fc23.src.rpm
cgnslib-3.2.1-5.fc23.src.rpm
engrid-2.0.0-0.8.gitbaef0ce.fc24.src.rpm
Field3D-1.6.1-8.fc24.src.rpm
gdal-2.0.1-2.fc24.src.rpm
gdl-0.9.5-10.fc24.src.rpm
gpaw-0.11.0.13004-16.fc24.src.rpm
grads-2.0.2-13.fc23.src.rpm
gtatool-2.1.0-9.fc24.src.rpm
h5py-2.5.0-5.fc24.src.rpm
InsightToolkit-4.8.2-1.fc24.src.rpm
jhdf5-2.11.0-3.fc23.src.rpm
kst-2.0.8-4.fc23.src.rpm
libASL-0.1.6-1.fc24.src.rpm
mathgl-2.3-11.fc24.src.rpm
matio-1.5.2-7.fc23.src.rpm
med-3.0.8-4.fc23.src.rpm
mrpt-1.3.0-2.fc24.src.rpm
ncl-6.3.0-6.fc24.src.rpm
netcdf-4.3.3.1-7.fc24.src.rpm
octave-4.0.0-7.fc24.src.rpm
octave-communications-1.2.1-1.fc23.src.rpm
OpenImageIO-1.5.20-2.fc24.src.rpm
paraview-4.4.0-2.fc24.src.rpm
python-tables-3.2.2-2.fc24.src.rpm
R-Rsolid-0.9.31-16.fc23.src.rpm
scilab-6.0.0-0.2.alpha1.fc24.src.rpm
shogun-4.0.1-0.1.git20150808.779c3ad.fc24.src.rpm
vigra-1.10.0-15.fc24.src.rpm
vips-8.1.1-2.fc24.src.rpm
ViTables-2.1-12.fc23.src.rpm
vtk-6.3.0-2.fc24.src.rpm
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
8 years, 2 months
Testing chrony seccomp support
by Miroslav Lichvar
In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.
If you would like to help with the testing:
1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running
If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.
For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/
Thanks,
--
Miroslav Lichvar
8 years, 3 months
Supporting Python 3 in EPEL 7
by Randy Barlow
Hello!
I recently added the package python-rpdb to F22/23/rawhide. The build
failed in Koji due to having a BuildRequires on python3-devel. It seems
that it is called python34-devel in EL 7. This leads me to wonder on a
few things:
0) Should I call my package python34-rpdb in EL 7 for consistency? There
don't seem to be very many Python 3 packages for EL 7 at all (yum search
only found a handful) but it seemed that there are a few doing this.
Alternatively, I could just build the python2 package.
1) What is the recommended strategy for handling my spec file if I
attempt to do different things in EL 7 than I do in F22+? I had
considered just making this change to the spec file in that branch, but
since this would require raising the release it could make upgrade from
EL 7 to EL 8 tricky if the package version doesn't change upstream. Is
it better to use if statements in the spec file? I like the idea of very
clean spec files that work on one specific release, but on the other
hand I do see the potential for upgrading to be disrupted. I found this
snippet:
https://fedoraproject.org/wiki/Package_maintenance_guide?rd=Using_git_FAQ...
Is that saying that it is OK for me to avoid the if statements and just
make the epel7 branch's spec file provide and require the 34 packages
and the .1 will make the upgrade path OK?
I'm new to Fedora packaging, so apologies if I've missed the answer to
this question in an obvious place.
--
Randy Barlow
xmpp: bowlofeggs(a)electronsweatshop.com
irc: bowlofeggs on Freenode
8 years, 3 months
F24 System Wide Change: Default Local DNS Resolver
by Jan Kurik
= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s):
* P J P <pjp AT fedoraproject DOT org>
* Pavel Šimerda <pavlix AT pavlix DOT net>
* Tomas Hozza <thozza AT redhat DOT com>
* Petr Špaček <pspacek AT redhat DOT com>
Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). A client can never be sure that there
is no man-in-the-middle, if it does not do the DNSSEC validation
locally.
We want to have Unbound server installed and running on localhost by
default on Fedora systems. Where necessary, have also dnssec-trigger
installed and running by default. Unbound and dnssec-trigger will be
properly integrated with the default network configuration manager
(e.g. NetworkManager for Fedora Server and Workstation) and with the
graphical user interface (especially GNOME). The localhost address
will be the only record in /etc/resolv.conf and no other software
except dnssec-trigger will be allowed to change its content.
== Detailed Description ==
Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). DNSSEC is a DNS extension which
enabled the client to verify the DNS query response and make sure
there is no attacker to spoof some records. A user connected to
network usually receives a set of resolvers from DHCP, which should be
used for name resolution. These resolvers may also do the DNSSEC
validation. However a client can never be sure that there is no
man-in-the-middle, if it does not do the DNSSEC validation locally.
Purpose of this Fedora change is to have a validating DNS resolver
installed on Fedora systems by default. This includes necessary
discussions, coordination and integration with other components
installed on Fedora by default.
There are growing instances of discussions and debates about the need
for a trusted local validating DNS resolver. There are multiple
reasons for having such a resolver, most importantly security and
usability. Security and protection of user's privacy becomes paramount
with the backdrop of the increasingly snooping governments and service
providers world wide.
People use Fedora on portable/mobile devices which are connected to
diverse networks as and when required. The automatic DNS
configurations provided by these networks are never trustworthy for
DNSSEC validation, as currently there is no way to establish such
trust.
Apart from trust, these name servers are often known to be flaky and
unreliable which only adds to the overall bad and at times even
frustrating user experience. In such a situation, having a trusted
local validating DNS resolver not only makes sense but is, in fact,
badly needed. It has become a need of the hour. (See: [1], [2], [3])
All DNS literature strongly recommends it and amongst all discussions
and debates about the issues involved in establishing such trust, it
is unanimously agreed upon and accepted that having a trusted local
DNS resolver is the best solution possible. It will simplify and
facilitate a lot of other design decisions and application development
in the future. (See: [1], [2], [3])
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files.
* properly document how to test and configure the new default setup
* persuade and coordinate with the other package owners to incorporate
new changes/workflow in their applications.
* discuss with WGs in which products the change makes sense and what
are the expectations of WGs for different Fedora products
* resolve interoperability issues for Docker and other containers use-cases
Other developers: (especially NetworkManager and the likes)
* NetworkManager has to implement notifications on connectivity state changes
* Gnome Shell has to use the connection provided resolvers (fetched
directly from NM) for Hot-Spot login purposes
* Ideally other developers and user should test their software and
application in this setup and verify that it is working as expected
Release engineering:
* Make sure that the necessary packages (dnssec-trigger, unbound) are
part of the composes for the appropriate Fedora Products.
* Add services needed for the setup into the default presets
(dnssec-triggerd.service)
Policies and guidelines:
* Any software, including NetworkManager, will have to be configured
to not tamper with the content of '/etc/resolv.conf' by default. The
connection-provided resolver entries should be stored in a separate
configuration file or in memory and accessible via some API.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedorapro...
8 years, 4 months
Can Koji handle a soname change and a self-dependency?
by Björn Persson
Is there a way to deal with the following situation in Koji?
· Build tool B has a build-time dependency on itself.
· B is linked to library L version 1.
· L gets upgraded to version 2, which changes its soname.
B needs to be rebuilt to link to libL.so.2, but building B requires a
working B, which requires libL.so.1 because it hasn't been rebuilt yet.
As I understand it, when the L-2 package goes into the buildroot it
immediately replaces L-1. Is there a way to keep L-1 available until B
has been rebuilt?
Is the answer to link B statically?
Björn Persson
8 years, 4 months
