[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