(In reply to Till Maas from comment #0)
> This is a tracker bug to collect build failures in packages becaise if the
> harden all packages with posistion-independent code chante:
> https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-
> independent_code

Is this just "build to fail"? What about "builds fine, but actually segfaults" on runtime? (for now I added bug 955147)

( For cutter, actually it "builds" in that %prep, %build, %install is successful, but %check fails)

Also see postgresql issue (bug 947022 , bug 952946 )

(In reply to Mamoru TASAKA from comment #1)

> Is this just "build to fail"? What about "builds fine, but actually
> segfaults" on runtime? (for now I added bug 955147)

Good questions, this is for any issue that needs to be resolved to successfully build and use packages built with the hardening flags.

Hardened flag Feature submitter, as feature submitter would you react and examine the current status of this,

https://lists.fedoraproject.org/pipermail/devel/2015-March/209015.html

and decide what you should do?

libdwarf is failing to build on x86 (bug 1201077)

*** Bug 1215939 has been marked as a duplicate of this bug. ***

From bug 1215939:

(In reply to Moez Roy from comment #7)
> (In reply to Christian Stadelmann from comment #3)
> > This Fedora 23 change has not been applied to all packages. On my system I
> > count >300 executables in /usr/bin failing the specified output of checksec.
> > _Many_ libraries in /usr/lib and /usr/lib64 fail too.
> > Are there any plans how to continue with this change to harden all
> > (remaining) packages?
> > Are there any "whitelists" of packages allowed to contain non-hardened
> > executables?
> 
> (In reply to Harald Reindl from comment #4)
> > @Christian Stadelmann make sure that are *really* binaries and not scripts!
> 
> (In reply to Christian Stadelmann from comment #5)
> > @Harald Reindl: checksec seems to understand that:
> > 
> > $ checksec --file /usr/bin/firefox
> > Error: Not an ELF file: /usr/bin/firefox: Bourne-Again shell script, ASCII
> > text executable
> 
> (In reply to Harald Reindl from comment #6)
> > is there somewhere a list with approved exceptions?
> > 
> > perl as example is one of them (i wrote a bugreport and questioned that at
> > least it could be Full RELRO when PIE currently is not possible for
> > technical reasons)
> > 
> > in other words: i wrote some bugreports, openjdk is in work, thunerbird was
> > fixed but they where about output from "checksec --proc-all"
> > 
> > recently gave karma for a update of "whois" which works fine *but* not
> > hardened and it's terrible to verify all by hand - checksec is too stupid to
> > follow symlinks at all (while it even says it's one with the destination)
> > 
> > normally it should have been the job of QA *before* release to verify the
> > distribution and list exceptions at
> > https://fedoraproject.org/wiki/Releases/23/ChangeSet?rd=Releases/
> > 23#Harden_All_Packages
> > 
> > "You can compare the security by running the following as root: checksec
> > --proc-all" is pure nonsense because not all things are long-running and
> > they real change of the policy is that now not only long-running and/or
> > network-aware binaries needs to be hardened as the policy before F23 statet
> > 
> > (wget short ago as example got a updat eto fix that)
> > ___________________
> > 
> > [root@srv-rhsoft:~]$ cat /usr/local/bin/hardening-check
> > #!/usr/bin/bash
> > /usr/bin/hardening-check --color $1
> > echo ""
> > /usr/bin/checksec --file $1
> > ___________________
> > 
> > [root@srv-rhsoft:~]$ hardening-check /usr/bin/whois
> > /usr/bin/whois:
> >  Position Independent Executable: no, normal executable!
> >  Stack protected: yes
> >  Fortify Source functions: yes (some protected functions found)
> >  Read-only relocations: yes
> >  Immediate binding: no, not found!
> > 
> > Error: Not an ELF file: /usr/bin/whois: symbolic link to
> > /etc/alternatives/whois
> 
> Better to move the discussion to the tracking bug which more people are
> following: Bug 199775
> 
> *** This bug has been marked as a duplicate of bug 1199775 ***

*** Bug 1272539 has been marked as a duplicate of this bug. ***

Are there any plans on how to handle packages that don't comply to using hardened flags? For example git is still compiled without hardening flags on anything but rawhide [1] and it is quite at risk as recent security issues have shown.

I still see many packages not yet hardened on my system:

$ checksec --dir /usr/bin | grep "No canary found" | wc -l
151

$ checksec --dir /usr/bin | grep "No PIE" | wc -l
149

$ checksec --dir /usr/bin | grep "Partial RELRO" | wc -l
150

and on a Fedora 24 Alpha 7 Build ISO live workstation:
No canary: 99
No PIE: 92
Partial RELRO: 93

Many packages ship executables to other directories, including /usr/sbin, /usr/libexec/, …. How about these? Are there any plans to add tests to make building the package fail if it is not hardened? This should probably be something scheduled for the next mass rebuild.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1289728

(In reply to Christian Stadelmann from comment #10)
> Are there any plans on how to handle packages that don't comply to using
> hardened flags? 

I am not aware of any such plans.

If someone is interested in getting more packages hardened then they would probably need to follow the below steps:

1. File a bug against that package stating it needs to be hardened. 

2. Wait 1 week. If you don't get a response from the package maintainer set the need info flags. Ping them again in the comment. If you have a patch for the spec file to make it hardened attach it.

3. Ask a proven packager to commit your changes or file a ticket with Fesco.