Bug#898534: RFS: ftp.app/0.6-2 [RC]

[Yavor Doganov <yavor@gnu.org>]

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?