Le 20. 07. 13 15:17, Daniel Silverstone a écrit :
On Sat, Jul 20, 2013 at 15:01:28 +0200, Louis Bettens wrote:
Le 20. 07. 13 12:07, Daniel Silverstone a écrit :
Would it not make sense at that point to simply patch ghc to always add the
flag to the link (unless told not to) ?
Umm... I am not sure. This would mean changing the default behavior
of ghc, which is intrusive. This doesn't seem a good move to me.
I'm not saying it's necessarily a good move, just raising it as an option.
Yes, I thought so and I commented on the option.
(Please contradict me) Would you do that to gcc?
Debian already did mess with gcc -- remember the --as-needed debacle? (which
mucks up loadable module linking massively)
I had never heard of that, but this looks like a good example case of
why you don't do that. Besides you end up altering compilations done
outside of Debian's build system by the user, unless you patch ghc only
on some computers, which is much more complicated than a tiny -optL usage...
But perhaps I have already gone too far with my patching dyre idea.
Let's look closer at the reasoning. the starting point is that
Debian wants to ship only relro'd executables in its packages. Now,
I point out that the executables shipped by xmonad, yi, taffybar and
so on are just stubs to boot another binary, therefore if we want to
protect these applications by default, we should care about the
other binaries.
xmonad and taffybar are both default functional programs without *needing* to
be recompiled.
Yes, you're right, they aren't just stubs. But static configuration with
a personal .hs file is still an important feature because many users
like to customize their desktop, so this is still an issue. Could there
be any downsides to relro ?
--
To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ea9715.70...@bettens.info
