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

Reply via email to