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
