From: Eric Wong <firstname.lastname@example.org>
To: Dirkjan Bussink <email@example.com>
Cc: John Crepezzi <firstname.lastname@example.org>,
Kevin Sawicki <email@example.com>,
Subject: Re: Potential Unicorn vulnerability
Date: Fri, 12 Mar 2021 12:00:07 +0000 [thread overview]
Message-ID: <20210312120007.GA24539@dcvr> (raw)
Dirkjan Bussink <firstname.lastname@example.org> wrote:
> Hi Eric,
> > On 12 Mar 2021, at 10:41, Eric Wong <email@example.com> wrote:
> > I'm not in favor of new options since they add support costs
> > and increase the learning/maintenance curve.
> > What I've been thinking about is bumping the major version to 6.0
> > Although our internals are technically not supported stable API,
> > there may be odd stuff out there similar to OobGC that uses
> > instance_variable_get or similar things to reach into internals.
> > Added with the fact our internals haven't changed in many years;
> > I'm inclined to believe there are other OobGC-like things out
> > there that can break.
> > Also, with 6.0; users who completely avoid Threads can keep
> > using 5.x, while others can use 6.x
> That sounds like a good plan then. Once there’s a new version we can
> bump that on our side to remove the manual patch then.
OK. I think it's safe to wait a few days for more comments
before releasing in case there's more last-minute revelations
(see below :x)
> > Btw, did you consider replacing the @request HttpRequest object
> > entirely instead of the env and buf elements?
> > I suppose that's more allocations, still; but could've
> > been a smaller change.
> Ah, that’s a very good point. I think that would also have been a valid
> approach but it does indeed add more allocations. If that approach would
> be preferred, I think it can also be changed to that?
> I don’t really have a strong preference on which approach to take here,
> do you?
I was going to say I didn't have a preference and the
current approach was fine...
However, I just now realized now that clobbering+replacing all
of @request is required.
That's because env['rack.input'] is (Stream|Tee)Input,
and that is lazily consumed and those objects keep state in
@request (as the historically-named @parser)
If we're to make env safe to be shipped off to another thread,
then @request still needs to stick around to maintain state
of env['rack.input'] until it's all consumed.
It probably doesn't affect most apps out there that just decode
forms via HTTP POST; but the streamed rack.input is something
that's critical for projects that feed unicorn with PUTs via
> > Oops, was that the integration tests in t/* ?
> Nope, looks like some platform behavior changes (tried on MacOS first).
> I was able to get the tests running and working on Debian Buster this
> morning before I sent a new version of the patch and they are all passing
> there for me locally.
Ah, no idea about MacOS or any proprietary OS; I've never
considered them supported. But yeah, it should work on any
GNU/Linux and Free-as-in-speech *BSDs
next prev parent reply other threads:[~2021-03-12 12:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <F6712BF3-A4DD-41EE-8252-B9799B35E618@github.com>
[not found] ` <20210311030250.GA1266@dcvr>
[not found] ` <7F6FD017-7802-4871-88A3-1E03D26D967C@github.com>
2021-03-12 9:41 ` Potential Unicorn vulnerability Eric Wong
2021-03-12 11:14 ` Dirkjan Bussink
2021-03-12 12:00 ` Eric Wong [this message]
2021-03-12 12:24 ` Dirkjan Bussink
2021-03-13 2:26 ` Eric Wong
2021-03-13 2:31 ` [PATCH] http_request: drop unnecessary #clear call Eric Wong
2021-03-16 10:15 ` Potential Unicorn vulnerability Dirkjan Bussink
2021-03-16 10:31 ` Eric Wong
2021-03-17 8:03 ` Dirkjan Bussink
2021-03-17 8:47 ` Eric Wong
2021-03-19 13:55 ` Dirkjan Bussink
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://yhbt.net/unicorn/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).