Problems with latest version 2.4.x

[Jimmi08]

Hi,
I have synced the core latest version on my localhost.

After next attempt to sync - it is not working, blank page (not white), no php errors in logs, just silent failing. It asks Are you sure and then nothing. I tried to set csrf_enforce to browser or any, no help. I tried it with debug on and off, no change.

And my avatar is gone too. But this I noticed on Lite during 2.3.10 changes (I just haven't had time for it), so it is not something new.

http://localhost/e107-core-2.4/thumb.php?src=%7Be_IMAGE%7Dgeneric%2Fblank_avatar.jpg&w=30&h=30
returns Bad URL but file is there

I haven't tried fresh install yet.

[Kanonimpresor]

Hi @Jimmi08,
In version 2.3.11, the avatar is missing in all its places (Admin, Login, News).

I overwrote version 2.4 on GitHub, updated all three processes, and everything is OK!

Description Action
Update from 2.x to 2.4.0 (git) ✔
Update core database structure ✔
Add new or missing core settings ✔

[Jimmi08]

There was no icon that update is waiting, but there was. No change.
Avatar in usersetting is ok

<img src="/e107-core-2.4/thumb.php?src=.%2Fe107_images%2Fgeneric%2Fblank_avatar.jpg&amp;aw=80&amp;ah=80" id="image-preview" class="img-rounded rounded e-expandit e-tip avatar style=" cursor:pointer;="" width:80px;="" height:80px'="" title="Click on the avatar to change it" alt="Click on the avatar to change it">
avatar in navigation is not rendered:

<img class="img-circle rounded-circle user-avatar user-avatar-online" alt="" src="/e107-core-2.4/thumb.php?src=%7Be_IMAGE%7Dgeneric%2Fblank_avatar.jpg&amp;w=30&amp;h=30" width="30" height="30" loading="lazy">

see difference: e107_images (correct) vs e_IMAGE ...

[Jimmi08]

@e107help thanks for the quick fix

Now I am getting

I know what it means, but there were exceptions before with debug on not asking for SSL with CURL. Was it changed or something?

[e107help[bot]]

Čau Jimako, and you diagnosed it yourself before I got there.

Your two pastes are the whole bug. Same generic image, two call sites, one flag apart:

• user settings preview, src=.%2Fe107_images%2F..., from a thumbUrl() call that leaves $raw alone
• navigation, src=%7Be_IMAGE%7D..., from toAvatar(), which asks for $raw = true

The $raw branch mints the {e_IMAGE} form after the conversion that would have flattened it, and e107::set_request() strips { and } out of every query string, so thumb.php is handed e_IMAGEgeneric/blank_avatar.jpg and quite reasonably says no. Fixed in #5894 on master and #5895 on release/v2.3.x, both merged this afternoon.

That one went in about forty minutes before you posted, so your copy probably predates it. Once the certificate below is sorted, one more sync picks it up.

The certificate, and yes, it did change

You are remembering correctly. Until 2026-08-03 e107 set CURLOPT_SSL_VERIFYPEER to false on outbound cURL requests, so no certificate was ever checked by anything. The shortcut goes back to 9a89036671 in 2016, whose commit title is "Fixes #1315 - Sync with Github on localhost now functional", which is this very feature, on localhost, for this very reason.

3abf2b02bc turned it on, with CURLOPT_SSL_VERIFYHOST => 2, as part of closing the redirect hole around GHSA-92fr-7h4f-22pp. One correction to your recollection: it was never conditional on debug mode. It was unconditional, which is why it never got in your way.

So Curl error: 60 is not a fault in your site. It is your PHP having no CA bundle it can find, which is the usual state of a local Windows stack. Fetch cacert.pem from https://curl.se/docs/caextract.html, put it somewhere sensible, and point php.ini at it:

curl.cainfo = "C:/path/to/cacert.pem"
openssl.cafile = "C:/path/to/cacert.pem"

Restart Apache and the sync should go through. This is in v2.3.11 as well, not just 2.4, so it is worth doing on any local copy.

And that error box you are looking at is the other half of the fix working: before #5896 the identical failure was the blank page you opened this thread with. That one also gives the download a realistic time budget and repairs a "Skipped" list that could never render. #5897 is the release/v2.3.x backport, and both of those merged before you posted, which is why you have the box at all.

@Kanonimpresor, glad 2.4 sorted you out. Worth knowing why: the navigation avatar was on the braced URL there too, as Jana's paste from her own 2.4 shows, so if yours looks right it will be drawing an uploaded picture rather than the generic one. Either way #5894 is in now, so it is closed for members who have not uploaded anything of their own.

All four are merged, so a sync from master or release/v2.3.x gets the lot. Thank you both for the pastes with the actual URLs in them, they turned this from guesswork into a five minute read.

[Jimmi08]

The correct answer was to add this to e107_config.php on localhost: define('e_REMOTE_FILE_ALLOW_PRIVATE', true);
But before I found it, the Claude said that there is issue in upstream code. So I copying its text.

Follow-up — the CA bundle was only half of the story

Thanks for the cacert.pem advice — it was correct and it did fix the
Curl error: 60 part. But after configuring curl.cainfo /
openssl.cafile (verified working), the
"Refused to fetch URL with non-HTTP(S) scheme or private/reserved IP"
error still kept coming back for
https://codeload.github.com/e107inc/e107/zip/master.

To isolate it, we added a Diagnostics page to our githubSyncLite plugin
(environment info, DNS checks, isolated cURL tests, and a test through
the same download path the sync uses). Here is what it found.

Finding: the SSRF guard depends on dns_get_record(), which fails
intermittently on Windows

isUrlSafe() in e107_handlers/file_class.php (added in 3abf2b0)
resolves the host with dns_get_record($host, DNS_A | DNS_AAAA) and
treats an unresolvable host the same as an unsafe one. On Windows
PHP, dns_get_record() uses its own resolver (not the OS one) and
fails selectively and intermittently. Three runs on the same
machine, minutes apart:

run	codeload.github.com	api.github.com	raw.githubusercontent.com
1	FAILED (returns false)	FAILED	OK
2	OK	FAILED	OK
3	FAILED	FAILED	OK

Meanwhile, in the same run:

• a direct cURL request to the exact same codeload ZIP URL, with SSL
  verification ON, returns HTTP 200 (cURL resolves via the OS
  resolver — the verbose log shows the CA file loaded and the TLS
  handshake completing), while isUrlSafe() refuses that same URL;
• getRemoteFile() on a host that did resolve
  (raw.githubusercontent.com) downloads the file fine — same handler,
  same machine, same second.

So nothing is wrong with the network, TLS, or the certificates. The
only difference between "works" and "refused" is whether
dns_get_record() happened to resolve that particular host on that
particular call.

Why this is confusing for admins

Two completely different failures currently end in the Github-sync
screen (e107_admin/db.php?mode=github) looking similar:

1. missing CA bundle → curl error 60 ("Couldn't download .zip file"),
2. dns_get_record() hiccup → "Refused to fetch URL with non-HTTP(S)
   scheme or private/reserved IP".

Message 2 mentions schemes and private IPs, so it sends people
debugging certificates and networking — while the real cause is a
resolver failure inside the guard. On Windows/WAMP this makes the
Github sync work randomly.

Suggestion (question)

Would a resolver fallback be acceptable? I.e. when dns_get_record()
returns false or an empty set, retry with gethostbynamel() (the OS
resolver) and run every returned IP through the exact same
canonicalizeIp() + FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE
checks. The guard would not be weakened — the IP checks stay identical —
it would just stop depending on a single flaky resolver.
(gethostbynamel() is IPv4-only, so the fallback case could force
CURLOPT_IPRESOLVE_V4 on the request to stay consistent with what was
validated.)

Independently of that, splitting the message would help a lot:
"could not resolve host X" vs "host X resolves to a private/reserved
IP address" — those are different problems with different fixes.

Screenshots attached: — CA bundle green,
direct cURL to the codeload URL returns HTTP 200 with verification on,
and isUrlSafe() refusing the same URL at the same time.

Edit: better images

[Jimmi08]

the code is here for you to check:
https://github.com/Jimmi08/e107-2.4.x-Lite/tree/main/eplugins/githubSyncLite

[e107help[bot]]

@Jimmi08 your read is right, and the diagnostics page found it. Filed as #6012, with #6029 on master and #6030 on release/v2.3.x. Merging is Deltik's call.

The bit only you can do: run one of those branches on the Windows box. I have no Windows PHP to hand, so the platform half of this rests on your measurements rather than on a run of mine, and the PR says so.

What the branches change: when dns_get_record() has no answer, resolveHostname() asks the system resolver as well, and every address that comes back goes through the same canonicalizeIp() and private-range loop as before. A host neither resolver can see stays refused. One limit worth knowing before you carry it into a fork: gethostbynamel() is IPv4 only, so where it answers, an AAAA record is not seen rather than refused. What keeps that safe is the pin rather than the check, file_class.php:1182-1187 and the authority rewrite the stream transport uses, which is also why CURLOPT_IPRESOLVE_V4 turned out not to be needed.

I did not split the message in two. Telling "could not resolve" from "resolves somewhere private" apart on the error path costs a second lookup that can answer differently from the first, so it names the unresolvable host alongside the other two causes in one line. That at least stops sending people off to check certificates.

On the workaround, and this is for whoever copies it later rather than for you: e_REMOTE_FILE_ALLOW_PRIVATE switches the address check off for every outbound fetch the site makes, so the marketplace, plugin and theme downloads and feed imports stop being checked too. Deltik added it for sites that have to reach an intranet address on purpose, and there is no per-host version of it today.

Your Claude's write-up sent me to one thing that was not on your list: isValidURL() asks the policy and then hands the URL as typed to fopen(), so it is the one outbound path that does not connect to the address it validated. Its only reference in core is commented out. Filed as #6027.