[Privoxy-devel] PCRE2 for privoxy on windows

Fabian Keil fk at fabiankeil.de
Wed Jul 26 08:55:00 CEST 2023


Lee <ler762 at protonmail.com> wrote on 2023-07-26 at 05:59:12:

> On Monday, July 24th, 2023 at 4:19 AM, Fabian Keil <fk at fabiankeil.de>
> wrote:
> 
> > Lee ler762 at protonmail.com wrote on 2023-07-22 at 22:22:38:
> > 
> > > Hi all,
> > 
> > 
> > Hi Lee,
> > 
> > it's good to hear from you again.
> > 
> > I noticed you're using a protonmail.com email address now
> > so I hope this messages is accepted.
> 
> Yes, it made it thru :)
> 
> > I'm CC'ing you anyway as I'm not sure whether or not you're
> > subscribed to the list yet.
> 
> Yes - I'm subscribed to -user and -devel.

Great.

If you haven't already, you may want to resubscribe to privoxy-team@
as well.

I intend to ask for additional funds in the near future and you
may want to approve or veto the request.

> > > The only crashes I had were using OpenSSL for +https-inspection
> > > I do not understand what's going on there, but adding a
> > > #include <openssl/applink.c>
> > > in openssl.c fixes the problem. ... or at least I haven't had any
> > > more crashes.
> > 
> > 
> > Did you get a backtrace you could post to the list?
> 
> No.  All I get is a popup window with
>   OpenSSL: FATAL
>   OPENSSL_Uplink(008A7C34,08): no OPENSSL_Applink
> where the number inside () changes.

I grepped the OpenSSL source code and found:

fk at t520 ~/git/openssl $git grep -A 3 -B 10 -n 'no OPENSSL_Applink'
ms/uplink.c-69-        }
ms/uplink.c-70-        if ((h = apphandle) == (HMODULE) - 1) /* revalidate */
ms/uplink.c-71-            break;
ms/uplink.c-72-
ms/uplink.c-73-        if (applinktable == NULL) {
ms/uplink.c-74-            void **(*applink) ();
ms/uplink.c-75-
ms/uplink.c-76-            applink = (void **(*)())GetProcAddress(h, "OPENSSL_Applink");
ms/uplink.c-77-            if (applink == NULL) {
ms/uplink.c-78-                apphandle = (HMODULE) - 1;
ms/uplink.c:79:                _tcscpy(msg + len, _T("no OPENSSL_Applink"));
ms/uplink.c-80-                break;
ms/uplink.c-81-            }
ms/uplink.c-82-            p = (*applink) ();

According to Microsoft [0], GetProcAddress "[r]etrieves the address
of an exported function (also known as a procedure) or variable from
the specified dynamic-link library (DLL).".

The OPENSSL_Applink() function seems to be located in ms/applink.c
and if I understand it correctly it sets a bunch of function pointers.

> > Did you use OpenSSL 3.x or an older release?
> 
> cygcheck -srv reports it as
>   mingw64-i686-openssl 3.0.9-0.1
> 
> > In general adding a header seems acceptable to me
> > but I'd like to understand why it helps.
> 
> I can't help you there :(  All the info I found on the web talks about
> calling .DLLS and I don't have any .. well I have the normal windows
> stuff but no cygwin or mingw DLLS in the privoxy directory or on the
> path, so I don't see how this can be a 'DLL linking problem' with
> openssl DLLs.
> 
> Privoxy works just fine until enabling +https-inspection.  Then I think
> the most it went was ~40 minutes before crashing. I've been running
> Privoxy for a few days now with no crashes and the only difference is
> adding the include of applink.c

It's interesting that it works for a while.
 
> This is my msg to the cygwin mailing list
>   https://cygwin.com/pipermail/cygwin/2023-July/253991.html
> no response yet, public or private :(

Maybe there's an OpenSSL-specific mailing list you could
try if you have the time and interest.

> > > Running the regression test gets me
> > > 2023-07-22 17:55:52: Executed 752 regression tests. Skipped 66. 752
> > > successes, 0 failures.
> > > 
> > > so that looks promising :)
> > 
> > 
> > Please try with the --forks option. On my ElectroBSD system
> > "--forks 1" was already sufficient to reliable trigger the
> > crashes.
> 
> No crashes, with "--forks 1" or "--forks 4"

Interesting. I've removed the #warning for now.

> But I'm on windows and not using posix threads.  If you recall this bit
> in w32svrapi.c #ifndef FEATURE_PTHREAD
>    /* NOTE: a cygwin cross-compiler build for --host=i686-w64-mingw32
> must disable POSIX threading - eg
>     *         ./configure --host=i686-w64-mingw32 --disable-pthread
>     */
>    child_id = _beginthread(w32_service_listen_loop, 0, NULL);
>    if (child_id > 0)
> #else
> #error "FIXME: Do pthread stuff here!"
> #endif
> 
> so maybe that has something to do with it?

I assume that's conceivable. Unfortunately I did not have the time
to properly investigate the crashes and using the native pcre2 API
seemed preferable to the POSIX interface anyway.

> > > See attached for my changes
> > 
> > 
> > I'd be interested to review you're changes in "git format-patch"
> > format. Can you send them to the list using a new thread for
> > each patch (set)?
> 
> Sure thing, but
> 1. what exactly is the command?  I made a new PCRE2 branch in git and
> haven't done any commits yet.  Maybe that's why "git format-patch"
> doesn't print anything?

Assuming your PCRE2 branch is based on master you should be
able to a patch for each commit with:

git format-patch master..

> 2. I don't do nice change sets.  I make changes to whatever seems to
> need changing and then do commits when
> a) I think I'm done
> b) I'm forced to so I can switch back to master and do a git pull

When I'm testing stuff I don't always create nice chance sets either
but I usually use interactive git rebase to clean up the commits before
I push the to git master.

> In other words, it'll take a day or two to make nice, neat change sets
> from the mess that I have.

Take your time, I can wait.

Fabian

[0] <https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20230726/4c8cc3e1/attachment.bin>


More information about the Privoxy-devel mailing list