https://bugzilla.redhat.com/show_bug.cgi?id=1591910 --- Comment #11 from Antonio Trande <anto.trande@xxxxxxxxx> --- (In reply to Dave Love from comment #10) > (In reply to Antonio Trande from comment #9) > > (In reply to Dave Love from comment #8) > > > (In reply to Antonio Trande from comment #7) > > > > > > > - libblas* libraries are not hardened: > > > > > > > > $ checksec --file libblas.so.3 > > > > RELRO STACK CANARY NX PIE RPATH > > > > RUNPATH FORTIFY Fortified Fortifiable FILE > > > > Partial RELRO No canary found NX enabled DSO No RPATH > > > > No RUNPATH No 0 0 libblas.so.3 > > > > > > Do you know how to change that? Linking with %build_ldflags doesn't affect > > > that result. I assume it doesn't make any real difference for the shims. > > > > It depends by these commands: > > > > + cc -shared -Wl,-soname=libblas.so.3 ... > > > > Add %__global_ldflags as options. > > __global_ldflags is defined as %build_ldflags. Have you actually made it > work? I guess the only reason to worry about it at all is so it doesn't show > up. Those libraries are as close as possible to an alias of libblis etc., so > I doubt there's much scope for compromising them anyhow. Setting ldflags in 'cc' commands does make libraries 'Full Relro'. I don't know if it's a real improvement in these cases. > > > > > > > > - These packages provide same blas* libraries: > > > > > > > > $ repoquery --whatprovides libblas.so.* > > > > Last metadata expiration check: 2:17:11 ago on sab 22 set 2018 12:57:31 CEST. > > > > blas-0:3.8.0-8.fc28.i686 > > > > blas-0:3.8.0-8.fc28.x86_64 > > > > blas-0:3.8.0-9.fc28.i686 > > > > blas-0:3.8.0-9.fc28.x86_64 > > > > > > > > Must be filtered, i guess. > > > > > > Sorry, I don't know what that's getting at. Could you explain? (It's > > > arguable clear how the libblas shims should be handled, especially as either > > > openblas of blis might win in different circumstances.) > > > > This package provides libblas.so.* libraries (inside a private directory): > > > > blis: > > blis > > blis(x86-64) > > config(blis) > > libblas.so.3()(64bit) > > libblis.so.1()(64bit) > > > > like 'blas': https://koji.fedoraproject.org/koji/rpminfo?rpmID=14724212 > > > > libblas from 'blis' and libblas from 'blas' have same name. > > Probably, you'll need to filter libblas from 'blis' and set rpath links from > > libblis* to %_libdir/blisblas/libblas* . > > > > Please, ask in devel mailing list if this is right approach. > > No, the idea is that you should be able to swap BLAS implementations at run > time via LD_LIBRARY_PATH/ld.so.conf; perhaps README.Fedora needs a better > explanation. (See also > https://loveshack.fedorapeople.org/blas-subversion.html for what I've run in > anger with OpenBLAS.) Fedora does need a useful linear algebra policy, but > that's been rejected in committee. Can you see a real problem in practice > with this approach? What i wish prevent is conflict among BLAS packages. Do you think it's out discussion with BLIS? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
