Peter Pentchev wrote:
> So I just took a more careful look at /usr/share/GNUstep/debian/config.mk
> and "optim" seems to be conditionally defined there.
Yes, I moved this snippet into config.mk in order not to repeat it in
every GNUstep package. Hence the explicit B-D on the gnustep-make
version that has it.
> Would you like me to upload the package now and sort out the
> hardened functions later, if it is even possible to handle with
> ObjC?
Yes, please upload, this issue needs further investigation. I don't
think it has anything to do with Objective-C. The hardening flags for
ObjC are the same as C, as it should be. I believe the problem is
due to hardening-check reporting no protected functions:
$ hardening-check --verbose FTP.app/FTP
FTP.app/FTP:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
unprotected: recv
unprotected: fread
unprotected: memmove
Read-only relocations: yes
Immediate binding: yes
That's why lintian is complaining. OTOH, I just tried a simple C test
program that uses fread and fprintf. Without hardening flags the
output is:
Fortify Source functions: no, only unprotected functions found!
unprotected: fread
unprotected: fprintf
With CPPFLAGS=-D_FORTIFY_SOURCE=2:
Fortify Source functions: yes (some protected functions found)
unprotected: fread
protected: fprintf
IOW, if ftp.app used fprintf there would be no lintian warning. Why
fprintf is protected while fread is not is something that has to be
investigated. Perhaps someone on -mentors already knows the answer?
