git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] imap-send: increase command size limit

From
Jeff King <peff@peff.net>
Date
Apr 17, 2024, 00:24 UTC
Message-ID
<20240417002454.GA2305596@coredump.intra.peff.net>
In-Reply-To
<85047e64-044f-4bf8-8de9-33b082255f3e@web.de>
On Tue, Apr 16, 2024 at 06:08:05PM +0200, René Scharfe wrote:
> > Shouldn't socket_write() just use size_t / ssize_t?
> 
> Probably size_t.
Yes, but you need ssize_t to handle the negative return values.
Show 6 quoted lines
> > In particular, this made me wonder what we would do for larger items.
> > Like, say, the actual message to be uploaded. And indeed, we use a
> > strbuf to read in the messages and pass the whole buffer for each to
> > socket_write(). So we'd possibly quietly truncate such a message.
> 
> Hmm, perhaps we should at least sprinkle in some more overflow checks?
Perhaps, but...
Show 9 quoted lines
> > Fixing it is a little more complicated than switching to size_t, because
> > the underlying SSL_write() uses an int. So we'd probably need some
> > looping, similar to xwrite().
> 
> Or SSL_write_ex(), which takes and returns size_t.  It was added in
> OpenSSL 1.1.1, which reached its end of life half a year ago.
> 
> https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

You'd think that when I ran "man SSL_write" while writing the other email I would have noticed that SSL_write_ex() is mentioned right there in the synopsis. But somehow I didn't.

I don't think we document a required version for ssl. That version is "only" 5.5 years old, but I think it would be OK here (especially given that imap-send is an optional component with a build-time knob).

In which case I think fixing socket_write() would fix this problem, and then building your other patch on top, it doesn't need to worry about INT_MAX at all.

Looking at the conversion, I think there's a slight gotcha with retaining the "0" return value from SSL_write_ex() to pass to socket_perror() in the error path. Which makes me wonder about that error path at all; it closes descriptors but doesn't handle SSL at all. Should it be using socket_shutdown()? And should that function set sock->ssl to NULL and the descriptors to -1? The rabbit hole of imap-send is infinite.

Show 8 quoted lines
> > In practice I doubt this is ever an issue. 2GB emails are not likely to
> > be usable in general.
> 
> Tough.  Who likes to get multi-GB patches in their inbox?  Heard of
> people exchanging CD images by email decades ago, though, so I
> wouldn't rule this out totally.  Perhaps that's the last puzzle piece
> to convert game studios to perform email reviews of asset-heavy
> binary diffs? ;-)
OK, I laughed out loud at this. Perhaps a sign of too much Git.
-Peff
Previous: René Scharfe
Message 8 of 8 in “imap-send: increase command size limit”
  1. imap-send: increase command size limitRené Scharfe, Apr 14, 2024
  2. brian m. carlsonApr 14, 2024
  3. Junio C HamanoApr 15, 2024
  4. Jeff KingApr 15, 2024
  5. René ScharfeApr 16, 2024
  6. Jeff KingApr 15, 2024
  7. René ScharfeApr 16, 2024
  8. Jeff KingApr 17, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.