On Wed, 2015-03-18 at 11:37 -0700, Moez Roy wrote:
FULL RELRO
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html
If that's all we got I suggest to remove this flag or (better) provide a
way for applications that use modules to compile themselves, without
removing
On 19.3.2015 08:16, Nikos Mavrogiannopoulos wrote:
On Wed, 2015-03-18 at 11:37 -0700, Moez Roy wrote:
FULL RELRO
http://tk-blog.blogspot.co.at/2009/02/relro-not-so-well-known-memory.html
If that's all we got I suggest to remove this flag or (better) provide a
way for applications that use
Here are 2 solutions:
-
Solution 1: Keeps -z now (Full RELRO) but removes guile:
I changed the first 2 lines in the spec file to:
%global without dane
%global without guile
and the latest version builds successfully:
https://koji.fedoraproject.org/koji/taskinfo?taskID=9276305
On Thu, 2015-03-12 at 10:41 -0400, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is a bit more than
maybe was expected.
I've reopened the ticket and added a patch:
On Mon, 2015-03-16 at 10:57 +0100, Nikos Mavrogiannopoulos wrote:
Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
What was the rationale of adding -z now to the hardening flags? Looking
its description doesn't reveal any hardening features, and the gnutls
guile module failure
On Wed, Mar 18, 2015 at 6:54 AM, Nikos Mavrogiannopoulos
n...@redhat.com wrote:
On Mon, 2015-03-16 at 10:57 +0100, Nikos Mavrogiannopoulos wrote:
Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
What was the rationale of adding -z now to the hardening flags? Looking
its
On Wed, Mar 18, 2015 at 7:21 AM, Moez Roy moez@gmail.com wrote:
On Wed, Mar 18, 2015 at 6:54 AM, Nikos Mavrogiannopoulos
n...@redhat.com wrote:
On Mon, 2015-03-16 at 10:57 +0100, Nikos Mavrogiannopoulos wrote:
Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
What was the
Am 18.03.2015 um 19:37 schrieb Moez Roy:
I was not successful with -Wl,-z -Wl,nonow
FULL RELO: -Wl,-z,now
YOU: -Wl,-z -Wl,nonow
TRY: -Wl,-z,nonow
what you did was change semantics for unknown reasons
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
On 03/18/2015 02:54 PM, Nikos Mavrogiannopoulos wrote:
Any advise from the change owners? How should applications that use
modules with undefined systems should handle that?
What semantics do you expect from the undefined symbol?
--
Florian Weimer / Red Hat Product Security
--
devel mailing
On 03/18/2015 03:21 PM, Moez Roy wrote:
I was doing some research last night but not tested it yet:
nonow
That's not a thing. The opposite of “-z now” is “-z lazy”:
else if (strcmp (optarg, now) == 0)
{
link_info.flags |= (bfd_vma) DF_BIND_NOW;
On Mon, 2015-03-16 at 18:31 +0100, Jakub Jelinek wrote:
On Mon, Mar 16, 2015 at 01:24:19PM -0400, Adam Jackson wrote:
On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
PIE does alter symbol resolution, though not in a particularly big way.
In a normal executable, taking the address
On Mon, 2015-03-16 at 10:19 +0100, Reindl Harald wrote:
Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
What was the rationale of adding -z now to the hardening flags? Looking
its description doesn't reveal any hardening features, and the gnutls
guile module failure to build seems
On Mon, Mar 16, 2015 at 01:24:19PM -0400, Adam Jackson wrote:
On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
On 03/12/2015 03:41 PM, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is
On Fri, 2015-03-13 at 12:14 +0100, Florian Weimer wrote:
On 03/12/2015 03:41 PM, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is a bit more than
maybe was expected.
People tell conflicting
On Thu, 2015-03-12 at 10:41 -0400, Adam Jackson wrote:
On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote:
On 2015-03-12, Nikos Mavrogiannopoulos n...@redhat.com wrote:
In rawhide building the gnutls guile bindings fails, and that's related
to the new hardening flags being enabled with
Am 16.03.2015 um 09:47 schrieb Nikos Mavrogiannopoulos:
What was the rationale of adding -z now to the hardening flags? Looking
its description doesn't reveal any hardening features, and the gnutls
guile module failure to build seems to be directly related to that flag:
On Fri, 13 Mar 2015 19:24:58 +0100
Ralf Corsepius rc040...@freenet.de wrote:
My conclusion is that gcc5 is at least sometimes using a lot more
memory than older versions.
I haven't noticed a significant increase in memory usage in my local
mock builds, but I haven't tried to investigate.
On 03/13/2015 01:58 PM, Kevin Fenzi wrote:
On Fri, 13 Mar 2015 07:46:04 +0100
Ralf Corsepius rc040...@freenet.de wrote:
On 03/12/2015 05:06 PM, Ralf Corsepius wrote:
Well, all I can say, building rawhide packages (esp. C++) seems to
have evolved into a lottery and rendered working one Fedora
On 03/12/2015 05:06 PM, Ralf Corsepius wrote:
Well, all I can say, building rawhide packages (esp. C++) seems to have
evolved into a lottery and rendered working one Fedora packages into an
adventure.
E.g. I am facing packages which one day build, but fail to build the
other day. Today, I have
On Thu, 2015-03-12 at 18:49 +0100, Till Maas wrote:
On Thu, Mar 12, 2015 at 10:41:49AM -0400, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is a bit more than
maybe was expected.
Yes, if it is
On Fri, Mar 13, 2015 at 12:34 AM, Nikos Mavrogiannopoulos
n...@redhat.com wrote:
I think it is important to document what a hardened build means, in the
change request as well as provide a pointer from the packaging
guidelines. It's no much point mentioning hardened builds but no-one can
find
On 03/13/2015 10:14 AM, Moez Roy wrote:
I added the above information to the wiki as requested:
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code#Detailed_Harden_Flags_Description
I think people who can read GCC specs file syntax will not have to
consult
On 03/12/2015 03:41 PM, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is a bit more than
maybe was expected.
People tell conflicting things about PIE. I have asked essentially the
same thing, and I
On Fri, 13 Mar 2015 07:46:04 +0100
Ralf Corsepius rc040...@freenet.de wrote:
On 03/12/2015 05:06 PM, Ralf Corsepius wrote:
Well, all I can say, building rawhide packages (esp. C++) seems to
have evolved into a lottery and rendered working one Fedora
packages into an adventure.
E.g. I
In rawhide building the gnutls guile bindings fails, and that's related
to the new hardening flags being enabled with [0]. The failure is quite
peculiar since the loading of a dynamic module fails [1] which already
is position independent. Could someone explain what do the new flags in
rawhide do
On 12/03/15 14:41, Adam Jackson wrote:
On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote:
However I can add my recent story: After hardening perl, loading a DSO
by perl failed. I believe the reason was the DSO had an undefined symbol
which was not defined in any SO_NEEDed libraries. But
On 2015-03-12, Nikos Mavrogiannopoulos n...@redhat.com wrote:
In rawhide building the gnutls guile bindings fails, and that's related
to the new hardening flags being enabled with [0]. The failure is quite
peculiar since the loading of a dynamic module fails [1] which already
is position
On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote:
On 2015-03-12, Nikos Mavrogiannopoulos n...@redhat.com wrote:
In rawhide building the gnutls guile bindings fails, and that's related
to the new hardening flags being enabled with [0]. The failure is quite
peculiar since the loading of a
On 03/12/2015 04:39 PM, Moez Roy wrote:
On Thu, Mar 12, 2015 at 7:49 AM, Tom Hughes t...@compton.nu wrote:
On 12/03/15 14:41, Adam Jackson wrote:
We may want to revisit this, honestly.
+1
I believe most of the issues should get resolved on its own after the
mass rebuild of all the
On Thu, Mar 12, 2015 at 7:49 AM, Tom Hughes t...@compton.nu wrote:
On 12/03/15 14:41, Adam Jackson wrote:
On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote:
However I can add my recent story: After hardening perl, loading a DSO
by perl failed. I believe the reason was the DSO had an
On Thu, Mar 12, 2015 at 05:26:43PM +, Tom Hughes wrote:
Well I haven't figured out how to fix libdwarf (see message this morning)
nor do I have any idea what I should do next to try and figure it out.
So unless I ignore the rawhide first rule it seems I can't update that for
F22 until
On Thu, Mar 12, 2015 at 10:41:49AM -0400, Adam Jackson wrote:
We may want to revisit this, honestly. The actual proposal was just to
build executables as PIE, right? Forcing -z now is a bit more than
maybe was expected.
Yes, if it is causing problems in a majority of packages, I agree that
On 12/03/15 17:14, Till Maas wrote:
On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote:
On top of which there seems, despite a number of questions posted here since
the change went live, very little assistance from the proposal owners with
fixing packages that have been broken by it.
On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote:
On top of which there seems, despite a number of questions posted here since
the change went live, very little assistance from the proposal owners with
fixing packages that have been broken by it.
I do not see much value in repeating
On 12/03/15 17:48, Till Maas wrote:
On Thu, Mar 12, 2015 at 05:26:43PM +, Tom Hughes wrote:
Well I haven't figured out how to fix libdwarf (see message this morning)
nor do I have any idea what I should do next to try and figure it out.
So unless I ignore the rawhide first rule it seems I
On 03/12/2015 06:14 PM, Till Maas wrote:
On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote:
On top of which there seems, despite a number of questions posted here since
the change went live, very little assistance from the proposal owners with
fixing packages that have been broken by
36 matches
Mail list logo
