rsync segfaults when openssl fips is enabled

Hi All,

Copying the content from the GH issue as is.
Need your inputs on the same.
FWIW, the coredump files generated in linux have xattr values which are >
32 bytes.

https://github.com/WayneD/rsync/issues/569

Hi All,

System details:

root@ph3dev [ ~ ]# rsync --version
rsync  version 3.2.4  protocol version 31
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
    hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, no ACLs,
    xattrs, optional protect-args, iconv, prealloc, stop-at, no
crtimesOptimizations:
    SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
    xxh128 xxh3 xxh64 (xxhash) md5 md4 none
Compress list:
    zstd lz4 zlibx zlib none

OS:
Photon OS 3.0 with openssl fips enabled

I'm using rsync like below:

rsync -arXHpvxog <src> <dest>

While doing so, if any file in src or dest location has a xattr value
which is more than 32 bytes long, rsync segfaults.

root@ph3dev [ ~ ]# getfattr -d -m '' -- /opt/x
getfattr: Removing leading '/' from absolute path names
# file: opt/x
user.bla1="1234567890abcdef1234567890abcdef1" --------> 33 bytes long

After examining the coredump file, this happens at;

rsync/xattrs.c
Line 277 in 2f9b963

sum_init(xattr_sum_nni, checksum_seed);

Here md5 is used by default and md5 usage is prohibited in fips mode.

Is there any way to workaround this problem? Also, why not use xxhash
for this operation like it's used by default during --checksum option.

-- 
Shedi

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html