[MPlayer-users] Unable to Compile Mplayer Revision 34652

Carl Eugen Hoyos cehoyos at ag.or.at
Tue Feb 14 16:50:07 CET 2012


Vladimir Mosgalin <mosgalin <at> VM10124.spb.edu> writes:

> > >      --extra-cflags="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> > > -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 
> > > -mtune=generic" \
> > 
> > There are two possibilities:
> > Either this is useful, then this should be added to our default
> > flags, so please send benchmarks etc. in this case, or it has 
> > no benefits, then please remove it.
> 
> These are "Red Hat recommended" hardening options

-g -pipe are hardening options?
The point is that I suspect -O2 -mtune-generic makes the MPlayer 
binary slower without adding any additional security.
-m64 is default where it makes sense.
The way I understand the gcc manual, -fexceptions does not make 
much sense for MPlayer compilation (this may be wrong, please 
correct me in that case).

All that said, while I am certainly not a security expert, I 
wonder if people who add above as "hardening options" are 
really more qualified than I am.

(And my gcc manual does not explain -fstack-protector, I 
thought I remember having read somewhere it *may* fix some 
security issues but that memory could also be wrong.)

Seriously: Security issues should be fixed, if they cannot 
be easily fixed (for whatever reason), work-arounds (like above) 
may absolutely be acceptable, but that is not the case here.
Note that FFmpeg has fixed hundreds of potential issues in 
the last year (one of them was a real issue), the responsible 
Debian admins told me (on a public mailing list) that they 
"don't care" about such issues, I suspect this explains why 
they add above compilation options...

[...]

> -D_FORTIFY_SOURCE=2 seems to be interesting as it's compile-time 
> only check and should have no effect on mplayer performance, 
> only on compilation time.

Please send a patch!

Carl Eugen



More information about the MPlayer-users mailing list