[pkg-sec] Help with CFLAGS/LDFLAGS on t50

[Lukas Schwaighofer]

Hi Marcos,

On Tue, 20 Jun 2017 23:57:21 +0200
Marcos Fouces <mfouces at yahoo.es> wrote:

> Hello Samuel and team,
> 
> i suggest not to patch configure.ac. Upstream considered the patch we 
> created for earlier versions of t50 and improved the configure
> scripts.
> 
> Lintian does not complaint about missing flags so (AFAIK) one can
> safely suppose that all pertinent hardening flags are applied and
> there is no need to patch sources anymore in order to inject more
> flags.
> 
> This is the reason that lead me to drop the previous patch and i
> suggest that you should upload without it.


* without Samuel's patch CFLAGS are completely ignored (and lintian
  will complain)
* unless you drop "-s" you will notice that there is no -dbgsym
  package
* I don't think lintian can detect the stack protector hardening
  (it's not as easy as reading something from the ELF header…)

So currently uploading without a patch is currently an option.  If
upstream has updated their build system based on our feedback
previously, we may be able to fix that in the future though :) .

Regards
Lukas

> BTW, i was wondering if we could remove "Architecture: linux-any"
> field from control file. Perhaps the package builds also on Hurd and
> KFreebsd. I decided not to do it because i cannot test the result.
> 
> Greeting,
> 
> Marcos
> 
> 
> El 20/06/17 a las 19:23, Lukas Schwaighofer escribió:
> > Hi Samuel,
> >
> > I agree with Gianfranco regarding PIE.  However, looking at the
> > compile flags, I found that the configure script adds the following
> > to the CFLAGS (with your gcc_flags.patch applied):
> >
> >      CFLAGS+=" -s -DNDEBUG -fno-stack-protector"
> >
> > These options come after the "-g" and "-fstack-protector-strong"
> > added by dpkg-buildflags and disable both of them.
> >
> > You should definitely remove "-s" (for the dbgsym package, the
> > symbols will be stripped from the binary package automatically).
> >
> > You probably should also remove "-fno-stack-protector" (although
> > there may be a reason why this was added by upstream…).
> >
> > Regards
> > Lukas
> >
> >  
>