From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id BAF101F9FE for ; Fri, 12 Mar 2021 11:14:42 +0000 (UTC) Received: by mail-ej1-x62e.google.com with SMTP id bm21so52603670ejb.4 for ; Fri, 12 Mar 2021 03:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VozzzRTmzhwFROgps8FX8XaNy8HCLViXQxGAGUk6kFo=; b=R+dS0q6qAdjAqDI0+AOmVMpsBvxcO9SVO5NQNM4flhEMsH6az8JcecpPOam9VUnHWd BH6erUrEXhK5WdpkseNlp4vwtZ39emekdB6wKtAA+8PpNxghpDdv1clqig6os2Ic0wnJ qCmXES077xIRp5d6Bc9WDyrkbtGUu4Gb2J35ckFSIv6htlRRpVQDcoJKPPWBDDh2pw4Z j6wY5k02AqqyQK8NQ2BcX1z+ReYpPtx/nOCy13sWE6ptT7D9o0NB3DJe0NCFTctOYazo Fk/6IAAt9sX4OdQ2LzhhOA454pOf5B1syXGsgDYn5MOmOBSYtsjXpF74i3zG2QfnxE0t BfWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VozzzRTmzhwFROgps8FX8XaNy8HCLViXQxGAGUk6kFo=; b=MQ7keihau9atoG6TC5ymjTwehbiVHoYeuQ2VXJ5LKC3n76SumWaNfMVgEpkE4H3BRt HC+df7l+ZWMLMxFTzVlWoolnGcbyelG4OtmETgSUBD0Kg6H795Gnhoy8qgvEGT5BtFg/ EzjZ1G+DGy8m8BtMLxVbMhdE37HuluEw+YbLvUSzsoN8XKWy47GyTOFPXFhR5xVQnFVk rG20rncKSBYq0xzJUjF/9Y7sryks/rEsnrxolGEJobeDrBOrJkXLkjgZf4F1Puuu61vo CX2SmXsflcZOmm8F3J7OjDCatMizTMuwqjEEZlB6773bWObENDltkMNknQklVZm6HBzW grrQ== X-Gm-Message-State: AOAM533ebK0EZZt6za/rdCY56WZpp6Dfnc/ZuzVHY2dj7+vO/iKldr24 MNoakqwoYqR1cDsmO9WiAumETg== X-Google-Smtp-Source: ABdhPJxTjHgAvUEFIdqW7I7VVaUJocRI8849K2cE0V9SYMwTPVKSghgS3cN8EVnJbPO6U6VrwE+h5w== X-Received: by 2002:a17:906:82c5:: with SMTP id a5mr8244617ejy.232.1615547679149; Fri, 12 Mar 2021 03:14:39 -0800 (PST) Received: from dbussink.archimedes.bussink.me (178-85-12-131.dynamic.upc.nl. [178.85.12.131]) by smtp.gmail.com with ESMTPSA id gt37sm2535726ejc.12.2021.03.12.03.14.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Mar 2021 03:14:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Potential Unicorn vulnerability From: Dirkjan Bussink In-Reply-To: <20210312094129.GA14538@dcvr> Date: Fri, 12 Mar 2021 12:14:37 +0100 Cc: John Crepezzi , Kevin Sawicki , unicorn-public@yhbt.net Content-Transfer-Encoding: quoted-printable Message-Id: <382B893C-A07C-4705-950E-6D1CA766D998@github.com> References: <20210311030250.GA1266@dcvr> <7F6FD017-7802-4871-88A3-1E03D26D967C@github.com> <20210312094129.GA14538@dcvr> To: Eric Wong X-Mailer: Apple Mail (2.3608.120.23.2.4) List-Id: Hi Eric, > On 12 Mar 2021, at 10:41, Eric Wong wrote: >=20 > I'm not in favor of new options since they add support costs > and increase the learning/maintenance curve. >=20 > What I've been thinking about is bumping the major version to 6.0 >=20 > 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. >=20 > 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=E2=80=99s 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=E2=80=99s 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=E2=80=99t really have a strong preference on which approach to = take here, do you?=20 > 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=