Hi All, Any inputs on this issue?
-- Shedi On Wed, Feb 21, 2024 at 5:12 PM Shreenidhi Shedi < shreenidhi.sh...@broadcom.com> wrote: > 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