So everything in Rawhide must be compiled with -fPIC?

[Till Maas]

On Fri, Feb 20, 2015 at 07:28:50PM +0000, Peter Robinson wrote:
> On Fri, Feb 20, 2015 at 6:55 PM, Till Maas <opensource at till.name> wrote:
> > On Fri, Feb 20, 2015 at 05:21:59PM +0000, Peter Robinson wrote:

> How is a PDF with a binary payload any different? Sounds like we need
> to be running pdf readers in a selinux container?

I am not sure what you mean with binary payload. But being able to
easily confine applications as a user is something that I welcome. But I
am not sure if selinux is the right tool for this, maybe a limited
policy with layered selinux restrictions. E.g. the system policy
restricts systemd daemons from accessing the home directory and a
simpler user policy adds additional restrictions to user processes.

> >> More over in the Change request [1] I don't see any evidence with
> >> examples, links to research papers etc on how this makes things more
> >> secure.... all I see is basically "because SECURITY man!!!" . The
> >> feature says "our users less likely become victims of attacks" but
> >> which sort of attacks, how does it improve security. I understand why
> >
> > There were a lot of details given in several tickets and discussions,
> > since this is nothing new. As with other Changes there was a public
> > discussion on this list and the FESCo discussions were public as well.
> 
> It would be useful to provide those details in the Change for easy
> reference to those reading it :-)

There is a link to the FESCo ticket, that contains a link to the latest
discussion on the devel list, and it contains a linkt to another FESCo
ticket with a lot of links. So if you want to read it all, it is all
there.

> And if you think about it Fedora is already widely different to the
> world of Windows. I'm well aware of the packaging criteria and the
> would of network communications, security and even windows.

I do not see much difference when I open a PDF document in Fedora or
Windows, if there is a vulnerability in the used PDF library. It might
even better on Windows, because ASLR is enabled for at least one PDF
reader:
http://blogs.adobe.com/security/2012/10/new-security-capabilities-in-adobe-reader-and-acrobat-xi-now-available.html

> >> than the technical change to implement it, there's no mention that it
> >> will have an impact on performance, with numbers to back it up, across
> >> the three primary architectures.
> >
> > So how much performance impact is acceptable?
> 
> Well you've not documented any of the impact so how can we discuss
> that? We have no idea if the impact is going to be 0.1% 1% or 10% so
> how can the discussion happen without numbers? Numbers speak?

How will you do a fair decision if the criteria are not clear? If you
just look at the numbers and just decide based on a feeling whether the
number feels ok or not, why do you need hard numbers at all?

> In an uber secure environment if it was going to be 10% they'd likely
> just throw more money at it, but 10% in Fedora even people on the
> highest spec of hardware would probably complain. I know it's not
> going to be that but you as the feature owner haven't presented
>- anything as yet.

Event 100% might not bother anyone if you do not notice it, because it
is too fast to recognise. Therefore if you like to have a test, propose
a valid testcase and criteria that you are interested it. But I do not
have the resources to produce a lot of arbitrary numbers just to have a
gut feeling decide whether or not they are good.


> No, you won't be doing the mass rebuild for example. But you do need
> to do enough to back up your proposal. Just like the people proposing
> gcc5 did a mass rebuild test with details.

The gcc5 change was already basically accepted for Fedora 23 before
there was a mass rebuild. Also since I got the Change accepted, so as
far as I can see I did enough. However I have no problem with just
rebuilding all affected packages in Rawhide just now, but I do not have
the resources to do this one my systems. I am all for using the full
Fedora 23 development cycle to test this instead of waiting for a later
mass rebuild. I would have done the change in the macros file right
after branching, to have even a few more days.

Also I do not see the extra value in rebuilding it several times on
different machines, because if something does not rebuild due to the
change, it can just be rebuilt without the change, if this is a hard
blocker. If there are problems with certain archs, they can be address
similarly if they occur.

> Other Changes or Features don't impact every single package. Those

Other system wide changes do (this is why they are called this way).
However even my Change does not affect most of all RPMs, since noarch
packages are not affected and also not every arch package.

> The difference here I have mentioned above, it's not a feature you can
> easily turn off with a command line option. It affects everyone and
> everything in the distro, like gcc5, and they did massive amount of
> work with their own mass rebuild to prove the impact.

In opposite to the gcc5 change, this can be easily reverted on a
per-package basis with a rebuild, but it is not possible to just build
packages with gcc4 and some with gcc5.

> distro or done a minor rebuild of core bits across all architectures
> we support (both primary and secondary) and the upstream person that
> developed the functionality had expressed concerns with what you are
> doing. Those reason alone are why I have concern.

A minor rebuild of core bits is not necessary, because there are already
key components that are not changed by this, because it is already
happening for them:
https://fedoraproject.org/wiki/Hardened_Packages

And I already use it for several of my own packages.

> And another mass rebuild? Most major changes have done some impact
> testing. Do we even know what percentage of packages will even
> actually build when the mass rebuild happens? Nope!

We do not know this already for a mass rebuild with no changes.

> > I know, I bought myself hardware that I cannot use because Fedora ceases
> > to support it.
> 
> What hardware would that be? You're not going to name it?

I did not assume it to matter. I bought several kirkwood ARM devices.
And if it is interesting for you, I am using a nine year old thinkpad
X41 and AMD 4850e CPU on my desktop system. So I am one of the users you
are talking about.

Btw. what is your goal with this discussion? Do you want FESCo to revoke
its decision?

Regards
Till