On Wednesday, September 6, 2023 11:49 PM, Damien Miller wrote: >On Wed, 6 Sep 2023, rsbecker@xxxxxxxxxxxxx wrote: > >> On Thursday, May 19, 2022 5:21 PM, Scott Neugroschl wrote: >> >Isn't that a consequence of the limits on the nonstop READX call? >> >> Yes it is an OS limit. I have been able to partially get this to work >> as >> follows: >> >> @@ -281,6 +281,10 @@ sshbuf_read(int fd, struct sshbuf *buf, size_t >> maxlen, size_t *rlen) >> >> if (rlen != NULL) >> *rlen = 0; >> +#if defined (__TANDEM) >> + if (maxlen > SSIZE_MAX) >> + maxlen = SSIZE_MAX; // About 56Kb from limits.h #endif >> >> But I cannot figure out the best way to deal with the writes or the >> most acceptable way to the OpenSSH team. Any suggestions? > >Is this true for all read() calls or just particular ones? If it's for all read() calls, then >maybe wrapping/replacing the read() function more generally would be needed. > >channels.c isn't the only place in OpenSSH that might do a large read... This is only for sshbuf_read at the moment, which got through most issues. I could attempt the following that another project did: What the git project did was create a compatibility layer with procs xread and xwrite, with the same arguments as read/write, that allowed platform handling to be tweaked. Not a small change, though. It would be easier if there were defines that would be in place to guard this. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
