Re: [Klara FreeBSD #2159] Second bug in our web server: mod_perl2 Apache2::Upload upload method silently dies

	Why is effort being put into patching libapreq2 v2.17 when simply 
compiling v2.18 from source already solves the problems?

> We now know how to fix this problem. The installation I have for testing=
 mixes
> packages from poudriere and ports installed from /usr/ports, which is no=
t best
> practice. The question is how to apply a fix in production in the "right=
" way?
> 
> A) make a poudriere based on an older snapshot of the ports tree that in=
cludes
> libapreq2 version 2.16. I am 85% sure that the bug was introduced in 2.1=
7.
> Build only the libapreq2 package (which unfortunately has a lot of
> dependencies, including Apache itself), then have a repo pointing to tha=
t with
> priority higher than FreeBSD default "Latest" as well as higher than our=
 own
> current "Latest" poudriere. The problem with this approach is we will en=
d up
> with an older version of Apache and a lot of other important packages.
> 
> B) Klara convinces [email protected] (mailto:[email protected]) to put=
 out an
> official upgrade in the ports tree version 2.17_1 with the patch that Xa=
vier
> created
> 
> C) We create a poudriere with Xavier's patch applied to libapreq2, or ra=
ther
> apply the patch to our existing "default" poudriere. I don't know how to=
 do
> that, but it seems like a use case poudriere must have been designed for=
.
> 
> D) I use my existing mix of ports & packages in prod, perhaps with some =
pkg
> lock, on the grounds that we know it works and we can roll forward to a =
better
> solution when one comes out soon. I have done worse things in the past.
> 
> I hope this makes sense.
> 
> - Alex
> 
> 
> On 7/18/25 19:31, Alex Aminoff wrote:
> 
>   I did this, and I believe it has fixed the problem!
> 
>   You can test this here
> 
>   http://backdev.nber.org/uploadtest
> 
>   What I did was apply your patch in /usr/ports on our diskless root
>   FreeBSD-14.2-root-202507, after running make extract in www/libapreq2.=
 Then
>   I had to re-compile in ports mod_perl and p5-libapreq2 and some other
>   stuff, and install those from ports.
> 
>   root@bsdalt:/usr/ports/www/p5-libapreq2 # pkg info | grep apreq
>   libapreq2-2.17_1 Generic Apache2 Request Library
>   p5-libapreq2-2.17 Perl binding for the Generic Apache2 Request Library
> 
>   Now the next question is what is the best way to have this "in product=
ion".
>   Can we apply your patch in some sensible way on poudriere? Or will you
>   contact the libapreq2 maintainers and try to get it accepted there?
> 
>   Also, there is now a weird problem where /usr/local/etc/rc.d/apache24
>   always takes a really long time to run, like a minute. I need to track=
 down
>   what is slowing it down.
> 
>   - Alex
> 
> 
>   On 7/18/25 02:22, Xavier Beaudouin wrote:
> 
>     Hello Alex,
>     I made a try to integrate the 3 commits into current port.
>     Can you have a try on your side, with the following patch (from curr=
ent
>     port tree)?
>     Kind regards,/Xavier
> 
>       Le 18 juil. 2025 =E0 03:06, Alex Aminoff
>       <[email protected]> (mailto:support.freebsd@klarasy=
stems.com)
>       a =E9crit :
>       Ticket URL:
>       https://support.klarasystems.com/Ticket/Display.html?id=3D2159 (ht=
tps://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> 
>       I did a bit of googling and found this unfortunately rather
>       vitriolic thread
> 
>       https://lists.apache.org/[email protected]:2024-2:apreq
> 
>       I could not quite follow which of those people if any are the
>       nominal maintainers of apreq. Patches to the current version might
>       be a way forward. OTOH maybe the maintainers of the FreeBSD port
>       know some of those people or are some of those people and are awar=
e
>       of or involved in the politics?
> 
>       - Alex
> 
> 
>       On 7/17/25 15:58, Allan Jude wrote:
> 
>         There only appear to be 3 changes since 2.17, all from 2023.
> 
>         The first one talks specifically about a regression in 2.17,
>         and restoring the behaviour from 2.16
> 
>         Might be the one
> 
> 
>         Allan Jude
>         --
>         Principal Solutions Architect @ Klara Inc.
>         W: klarasystems.com (https://klarasystems.com/)
>         M: +1 289-260-5944
> 
> 
>         On 2025-07-17 3:54 p.m., Kyle Evans wrote:
> 
>           Ticket URL:
>           https://support.klarasystems.com/Ticket/Display.html?id=3D2159=
 (https://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> 
>           Hi,
> 
>           If we knew which commits from libareq2 fix it, we could try
>           to convince the port maintainer to accept them as patches
>           to the current version if they don't want to hop to a
>           snapshot of a development version -- assuming the patches
>           aren't incredibly invasive.
> 
>           Thanks,
> 
>           Kyle Evans
> 
>           On 7/17/25 14:52, Alex Aminoff wrote:
> 
>             Ticket URL:
>             https://support.klarasystems.com/Ticket/Display.html?id=3D21=
59 (https://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> 
>             On 7/17/25 15:23, Alex Aminoff wrote:
>             >
>             > Meanwhile I will try wrapping upload() in an eval.
>             >
>             I tried this, and it is successful in that it returns contro=
l to the 
>             perl code, but the result of the upload call is undef. As I =
demonstrated 
>             in my initial post, if there are multiple file fields, any o=
f them being 
>             un-filled triggers the bug, so I can not get the info for th=
e file the 
>             user actually uploaded.
>             
>             Therefore one possible way forward will indeed be to downloa=
d the 
>             bleeding edge libapreq2 from source and compile and install =
it. I can do 
>             that, or you could. But please if you can do some more inves=
tigation first.
>             
>              =A0- Alex
>             
>           
> 
>           -- 
>           Kyle Evans
>           FreeBSD Engineering Manager, Klara Inc.        
> 
> 
>     Xavier Beaudouin-System Engineer @ Klara Inc.W: klarasystems.com (ht=
tp://klarasystems.com)
> 
> 


Randolf Richardson, CNA - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
https://www.inter-corporate.com/