On Sun, Mar 1, 2015 at 5:16 PM, David Airlie <airlied(a)redhat.com> wrote:
> So the rebuild to use hardened builds by default in rawhide, broke X.org.
> Thanks guys, my system is more secure, but I can't run any apps.
> Anyways enough snark from me, the problem seems to be that hardening
> makes bind now override RTLD_LAZY options, and the X server relies
> on the RTLD_LAZY on its drivers being lazy.
> So should I
> a) turn off hardened builds for all Xorg server/driver packages?
> b) or is there a way to get partial relro back?
> devel mailing list
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
In RHEL 7.1 beta I see in the changelog:
2014-09-17 Adam Jackson <ajax(a)redhat.com> 1.15.0-27
- Link Xorg as a PIE
2014-02-25 Adam Jackson <ajax(a)redhat.com> 1.15.0-6
- Fix dist tag
- Link Xorg with -z now
>From the src.rpm I found this patch:
>From 58f5196a02b2fea360a35e2ea7046a320aca2b4e Mon Sep 17 00:00:00 2001
From: Adam Jackson <ajax(a)redhat.com>
Date: Mon, 27 Jun 2011 11:21:23 -0400
Subject: [PATCH 01/15] link with -z now
Signed-off-by: Adam Jackson <ajax(a)redhat.com>
hw/xfree86/Makefile.am | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
index c3899b5..9e422f2 100644
@@ -67,7 +67,7 @@ Xorg_LDADD = \
Xorg_DEPENDENCIES = $(LOCAL_LIBS)
-Xorg_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)
+Xorg_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG) -Wl,-z,now -pie
BUILT_SOURCES = xorg.conf.example
DISTCLEANFILES = xorg.conf.example
-----BEGIN PGP SIGNED MESSAGE-----
Could someone please review a package I submitted today?
I would, of course, be willing to do a review in exchange.
GPG key: 00E8658D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
When I try to push to stable:
This update has not yet met the minimum testing requirements defined in
the Package Update Acceptance Criteria
Something is out of sync in bodhi it seems.
-------- Forwarded Message --------
Subject: [Fedora Update] [comment] x2goserver-126.96.36.199-1.fc22
Date: Sun, 01 Mar 2015 21:56:14 +0000
The following comment has been added to the x2goserver-188.8.131.52-1.fc22
bodhi - 2015-03-01 21:56:14 (karma: 0)
This update has reached 3 days in testing and can be pushed to stable
now if the maintainer wishes
To reply to this comment, please visit the URL at the bottom of this mail
Update ID: FEDORA-2015-2636
Release: Fedora 22
Notes: Update to 184.108.40.206: - cross-user X2Go Desktop Sharing
: again - handle Active Directory usernames correctly
: when using SQLite - new man page for x2gogetapps with
: disclaimer suggested by Stefan Baur - a lot of bug
Submitted: 2015-02-25 17:44:57
Comments: bodhi - 2015-02-25 17:44:59 (karma 0)
This update has been submitted for testing by orion.
taskotron - 2015-02-25 17:52:39 (karma 0)
Taskotron: depcheck test PASSED on i386. Result log: h
(results are informative only)
taskotron - 2015-02-25 17:53:11 (karma 0)
Taskotron: depcheck test PASSED on x86_64. Result log:
(results are informative only)
bodhi - 2015-02-26 17:06:22 (karma 0)
This update is currently being pushed to the Fedora 22
testing updates repository.
bodhi - 2015-02-26 17:41:48 (karma 0)
This update has been pushed to testing
bodhi - 2015-03-01 21:56:14 (karma 0)
This update has reached 3 days in testing and can be
pushed to stable now if the maintainer wishes
= Proposed System Wide Change: Legacy implementations of the Java platform in
Change owner(s): Jiri Vanek <jvanek(a)redhat.com>
Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
and from time to time one future JDK as a tech preview. This change should be
set of rules, which will enable community to maintain legacy JDKs. Please
note, people are bugging main JDK maintainers pretty often with this, and to
allow them to maintain legacy JDKs is a step in right direction.
* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *
== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules,
which will allow community maintainers to pack any legacy jdk and will be
ensuring that this JDKs will not conflict by any other JDK and will smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.
=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''
==== option one - introducing new packages - preferred ====
1. main jdk is proclaimed as dead as it was until now. The new jdk is derived
as new package prviousName-legacy
1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)...
(protection against random pull by as dependence)
1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5)
then main jdk (protection against winning in alternatives after update)
1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084
4. at least one of the main-jdk's members '''must''' be set as comaintainer
(to watch the commits and save the world if necessary)
5. new package '''should''' to follow both original jdk (ideally not change
at all (except source updates and necessary)) and current main jdk as close as
1. here it requires some common sense and a lot of testing if integration
with system is as expected
6. as it is generally not new package, the review process '''should''' be only
formal - to know maintainer and to create cvs repo
1. this is quite important, otherwise the new maintainer can become really
frustrated, and we are forcing the "dead" package over"orpahned" so the full
review (especially in alignment with rule 5) really should not be forced.
2. on the contrary, rules agreed here '''must''' be checked. (even the
7. all depending packages '''must''' keep requiring java-headless or java (and
BuildRequires java-devel). Requirements on any exact jdk - or even worse on
any exact legacy jdk are forbidden and needs FESCO exception.
This option is forcing maintainers to fight with the name x current setup of
alternatives. However, the work should be minimal. But it makes the update
path pretty clear and it keeps users well protected against legacy jdk.
==== option two - orphaning legacy jdks and ensure update path ====
1. main JDK is only orphaned when new main JDK landed
1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same
This is making life of legacy JDK maintainers a bit simpler. But I don't know,
how to ensure proper "obsolete" implementation in this case.
== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs
in Fedora guidelines" pages
devel-announce mailing list