> On 24 Feb 2020, at 16:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>>> On 24 Feb 2020, at 13:12, PG Bug reporting form <noreply@postgresql.org> wrote:
>>> On running the md5 command in the pgsql/lib/ folder using the following
>>> command,
>>> ind . -name "*.dylib" -exec md5 {} \; | sort -g -k 4
>>> I am getting this as the output
>>> MD5 (./libcrypto.1.1.dylib) = ebb2ebe266a6453b0cbd8b44a7fb64c5
>>> MD5 (./libcrypto.dylib) = f2a42014ed6737d117c4732afffa783c
>>> MD5 (./libecpg.6.11.dylib) = eda61536e715b3d1465f1a607def4004
>>> MD5 (./libecpg.6.dylib) = eda61536e715b3d1465f1a607def4004
>>> MD5 (./libecpg.dylib) = eda61536e715b3d1465f1a607def4004
>
>> If you inspect the directory I think you will find that these are links to a
>> single file. Use "find -type f" instead to deduplicate your file check.
>
> Indeed. The more interesting question is why libcrypto.1.1.dylib and
> libcrypto.dylib appear *not* to be duplicates. The latter should be
> a symlink to the former, but seemingly it is not.
As was revealed in the thread now, the files stem from an EDB installer archive
and upon inspecting the archive I can confirm both that the symlinks are indeed
files as well as the differences in the libcrypto dylibs.
libssl.dylib and libss.1.1.dylib are also different, with both linking against
libcrypto.1.1.dylib The symbol tables are equal, but a binary diff does reveal
a set of differences between the files (as the md5 had already indicated).
I wonder if this could be artifact of how the produced binaries are built
against OpenSSL? Not sure what would cause that though, but it's worrying to
see unexplained differences in shipped crypto libs.
cheers ./daniel