On Friday, 22 February 2019 11:28:33 CET Juan Isoza wrote: > Hello, > I want create for one of my application a Linux binary which run on all > current linux system running x86_64 processor. > > by example, I uses -static-libgcc -static-libstdc++ when I link my app , > because I'm not sure found recent version of this lib > I also use -lrt to prevent search some tims function added on recent GLIBC > > With openssl 1.1.0, I had no problem related to openssl > > With openssl 1.1.1, there is somes modern function searched at compile on > recent library > > So, I just run these command > sed -i -e 's/__ELF__/__ELF_and_sure_modern__/g' ./crypto/rand/rand_unix.c > sed -i -e 's/__GLIBC_PREREQ/__GLIBC__not_use_PREREQ/g' > ./crypto/rand/rand_unix.c > sed -i -e 's/__GLIBC_PREREQ/__GLIBC__not_use_PREREQ/g' ./crypto/getenv.c > sed -i -e 's/__GLIBC_PREREQ/__GLIBC__not_use_PREREQ/g' ./crypto/crypto.c > sed -i -e 's/__GLIBC_PREREQ/__GLIBC__not_use_PREREQ/g' ./crypto/uid.c > > with this modification, I'm sure that checking of modern API fail, and I > use previous api (like if I compile on oldest linux). > > I suggest offering an option to not trying using these modern GLICBC_PREREQ > , or pehaps uses dl (when openssl is compiled to uses dl) compile it on oldest system that you wish to target glibc is backwards compatible so new versions of it will work with binaries compiled with old versions forward compatibility (compiling with new glibc and running with old library) is not supported, and even if it may appear to work initially, it's not something that is generally supported and in practice very hard to support and may lead to hard to detect vulnerabilities. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Attachment:
signature.asc
Description: This is a digitally signed message part.
