After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794830 - openssl: issues with git
openssl: issues with git
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: cerbero
git master
Other Linux
: Normal blocker
: 1.14.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-30 07:02 UTC by Edward Hervey
Modified: 2018-05-04 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
source: Fix LD_LIBRARY_PATH when handling git commands (2.17 KB, patch)
2018-05-04 14:55 UTC, Edward Hervey
committed Details | Review

Description Edward Hervey 2018-03-30 07:02:13 UTC
Once openssl is built in cerbero, it causes issues with (system-wide) git on some distributions (in my case fedora).

Steps to reproduce (on a clean checkout with no prefetched sources):
./cerbero-uninstalled bootstrap
./cerbero-uninstalled build openssl
./cerbero-uninstalled build libvpx

Building the following recipes: libvpx
[(1/1) libvpx -> fetch ]
Running command 'mkdir -p /home/bilboed/work/devel/1.0/cerbero/build/sources/local/libvpx'
Running command 'git init'
Initialized empty Git repository in /home/bilboed/work/devel/1.0/cerbero/build/sources/local/libvpx/.git/
Running command 'git config user.email'
bilboed@bilboed.com
Running command 'git config user.name'
Edward Hervey
Running command 'git remote add origin https://github.com/webmproject/libvpx.git'
Running command 'git fetch --all'
Fetching origin
fatal: unable to access 'https://github.com/webmproject/libvpx.git/': failed setting cipher list: PROFILE=SYSTEM
error: Could not fetch origin
Running command 'git reset --hard v1.6.0'
fatal: ambiguous argument 'v1.6.0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

The issue is "fatal: unable to access 'https://github.com/webmproject/libvpx.git/': failed setting cipher list: PROFILE=SYSTEM"
Comment 1 Edward Hervey 2018-03-30 07:04:24 UTC
Note : this *might* be related to fedora's policy system (which is why it doesn't fail on debian) : https://fedoraproject.org/wiki/Changes/CryptoPolicy
Comment 2 Nicolas Dufresne (ndufresne) 2018-03-30 12:33:31 UTC
But that means we run git in the same env we build, so git ends up linked against what we just built. That's not ideal ... I bet this is only an issue for non-cross-compiling cases ?
Comment 3 Nirbheek Chauhan 2018-04-17 12:53:11 UTC
I thought I already fixed this. If not, we can enable more algos/ciphers.

commit 24b0f9c21fa752fcbf0fe550859961155a6a8781
Author: Nirbheek Chauhan <nirbheek@centricular.com>
Date:   Fri Mar 9 01:41:18 2018 +0530

    openssl.recipe: Enable more crypto algos on Linux
    
    These are not used by us, but the system version of Sphinx used by
    gst-validate ends up trying to use libssl built by this recipe, and
    fails due to undefined symbols:
    
    Could not import extension sphinx.builders.linkcheck (exception:
    /usr/lib64/python3.6/lib-dynload/_ssl.cpython-36m-x86_64-linux-gnu.so:
    symbol SSLv3_method, version OPENSSL_1_1_0 not defined in file
    libssl.so.1.1 with link time reference)
    
    Similar problem with librpmio.so.8, which is used during package
    generation on Fedora:
    
    rpmbuild: relocation error: /lib64/librpmio.so.8: symbol EVP_md2,
    version OPENSSL_1_1_0 not defined in file libcrypto.so.1.1 with link
    time reference
    
    It's harmless to enable these and we're effectively matching distro
    build settings for openssl, so should not be an issue.
Comment 4 Edward Hervey 2018-05-04 12:49:54 UTC
That part is fixed. The remaining cerbero fedora issue is related to rpm debugsrc packages.

Thanks !
Comment 5 Edward Hervey 2018-05-04 13:52:33 UTC
reopening, still exists :(

the issue is that the git https helper ends up picking up the openssl libraries we just built. They shouldn't they should be run with no LD_LIBRARY_PATH set.
Comment 6 Edward Hervey 2018-05-04 14:36:50 UTC
Actually *any* host commands should not be using the cerbero LD_LIBRARY_PATH, it's ... wrong. I hate this world.
Comment 7 Edward Hervey 2018-05-04 14:55:50 UTC
Created attachment 371675 [details] [review]
source: Fix LD_LIBRARY_PATH when handling git commands

For non-cross-compilation use-cases, we might end up building libraries
in cerbero that should *not* be used by host commands.

The case in point was the host "git" command picking up a mix of system
libraries and of libraries that we built in cerbero.

To avoid that, before running git commands switch to an environment
which uses the "host" LD_LIBRARY_PATH environment
Comment 8 Olivier Crête 2018-05-04 15:08:05 UTC
Review of attachment 371675 [details] [review]:

Merge it already!