From: Dirkjan Bussink <email@example.com> To: Eric Wong <firstname.lastname@example.org> Cc: John Crepezzi <email@example.com>, Kevin Sawicki <firstname.lastname@example.org>, email@example.com Subject: Re: Potential Unicorn vulnerability Date: Fri, 12 Mar 2021 12:14:37 +0100 [thread overview] Message-ID: <382B893C-A07C-4705-950E-6D1CA766D998@github.com> (raw) In-Reply-To: <20210312094129.GA14538@dcvr> Hi Eric, > On 12 Mar 2021, at 10:41, Eric Wong <firstname.lastname@example.org> 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. > 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? > 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. Cheers, Dirkjan
next prev parent reply other threads:[~2021-03-12 11:14 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 ` Eric Wong 2021-03-12 11:14 ` Dirkjan Bussink [this message] 2021-03-12 12:00 ` Eric Wong 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
Reply instructions: 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=382B893C-A07C-4705-950E-6D1CA766D998@github.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Potential Unicorn vulnerability' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: ../../unicorn.git 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).