rsync-ssl buffering problem - gnutls-cli issue being fixed with "--blocking-io"

RolandK via rsync <[email protected]> Sun, 26 Apr 2026 13:04:39 +0200
Newsgroups	gmane.network.rsync.general
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--===============9217758196265764056==
Content-Type: multipart/alternative;
 boundary="------------JwriL4TMWQcJ6ewRAxdEIbk0"

This is a multi-part message in MIME format.
--------------JwriL4TMWQcJ6ewRAxdEIbk0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello,

rsync-ssl currently suffers from an issue with recent changes in openssl.

gnutls-cli (other option for transport besides stunnel) also has an issue.

from the manpage:

 =C2=A0 =C2=A0 =C2=A0 =C2=A0This script also supports a --type=3Dgnutls op=
tion, but at the=20
time of this release the gnutls-cli command was dropping output, making=20
it unusable.=C2=A0 If that bug has been fixed
 =C2=A0 =C2=A0 =C2=A0 =C2=A0in your version, feel free to put gnutls into =
an exported=20
RSYNC_SSL_TYPE environment variable to make its use the default.

i have found that for gnutls-cli, the problem goes away when adding=20
"--blocking-io" to rsync.

anyhow, with gnutls-cli transfer is dead slow.

i'm currently working on support for socat and ncat as ssl transport=C2=A0=
=20
options in rsync-ssl, and while ncat works on linux, i hit a similar=20
issue when using rsync-ssl on macos. that on also getting fixed with=20
"--blocking-io".

i'm curious if we should see "--blocking-io"=C2=A0 as a solution to this=
=20
problem , or if there better should be put work into ssl transport=20
programs , so they be able to switch to unbuffered output, when binary=20
data being sent to stdout.

regards
Roland


gnutls issue:
https://gitlab.com/gnutls/gnutls/-/work_items/1037

openssl issue:
https://github.com/RsyncProject/rsync/issues/869

--------------JwriL4TMWQcJ6ewRAxdEIbk0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-=
8">
  </head>
  <body>
    <p>Hello,=C2=A0<br>
      <br>
      rsync-ssl currently suffers from an issue with recent changes in
      openssl.=C2=A0=C2=A0<br>
      <br>
      gnutls-cli (other option for transport besides stunnel) also has
      an issue.<br>
      <br>
      from the manpage:<br>
      <br>
      =C2=A0 =C2=A0 =C2=A0 =C2=A0This script also supports a --type=3Dgnut=
ls option, but at
      the time of this release the gnutls-cli command was dropping
      output, making it unusable.=C2=A0 If that bug has been fixed<br>
      =C2=A0 =C2=A0 =C2=A0 =C2=A0in your version, feel free to put gnutls =
into an exported
      RSYNC_SSL_TYPE environment variable to make its use the default.<br>
      <br>
      i have found that for gnutls-cli, the problem goes away when
      adding "--blocking-io" to rsync.=C2=A0<br>
      <br>
      anyhow, with gnutls-cli transfer is dead slow.<br>
      <br>
      i'm currently working on support for socat and ncat as ssl
      transport=C2=A0 options in rsync-ssl, and while ncat works on linux,=
 i
      hit a similar issue when using rsync-ssl on macos. that on also
      getting fixed with "--blocking-io".=C2=A0<br>
      <br>
      i'm curious if we should see "--blocking-io"=C2=A0 as a solution to
      this problem , or if there better should be put work into ssl
      transport programs , so they be able to switch to unbuffered
      output, when binary data being sent to stdout.=C2=A0<br>
      <br>
      regards<br>
      Roland<br>
      <br>
      <br>
      gnutls issue:<br>
      <a class=3D"moz-txt-link-freetext" href=3D"https://gitlab.com/gnutls=
/gnutls/-/work_items/1037">https://gitlab.com/gnutls/gnutls/-/work_items/1=
037</a><br>
      <br>
      openssl issue:<br>
      <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/RsyncP=
roject/rsync/issues/869">https://github.com/RsyncProject/rsync/issues/869<=
/a></p>
  </body>
</html>

--------------JwriL4TMWQcJ6ewRAxdEIbk0--


--===============9217758196265764056==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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

--===============9217758196265764056==--