macOS workflow artifact: https.request returns code 0

[Endaris]

Note: This is conjecture. I do not own a Mac but I have invested a lot of work over the past couple days and I have very strong indications that the compiled library in the workflow artifacts is faulty.
This is a problem because I'm not aware of any alternative compile instructions besides the workflow.

Repro:
main.lua:

local https = require("https")
assert(https)

function love.load(args)
  local url = "https://api.github.com/repos/love2d/love/releases?per_page=10&page=1"
  local status, body, headers = https.request(url, {method = "GET", headers = { ["user-agent"] = love.filesystem.getIdentity()}})
  result = "https request returned with status " .. status .. " and body length " .. (body and body:len() or "none")
  print(result)
end

function love.draw()
  if result then
    love.graphics.print(result, 0, 0)
  end
end

Use love 11.5 and the respective https library from the latest workflow. On linux and windows it just works being placed next to main.lua, on mac you apparently have to get creative, I have no idea how to make it find the lib.
On Windows/Linux this will yield status 200 with a body length of 263484.
On Mac it immediately returns status code 0 and supposedly no / an empty body.

[slime73]

On linux and windows it just works being placed next to main.lua

This works on all platforms – but only if main.lua is in a folder rather than a .love file, because no operating system can directly run a dynamic library from inside a zip. You can copy it to your save directory, or mount another folder that has it, or use package.path, or rely on OS-specific loading paths.

On Windows/Linux this will yield status 200 with a body length of 263484.
On Mac it immediately returns status code 0 and supposedly no / an empty body.

I can't reproduce this with love 12.0 or with love 11.5 with the library successfully loaded, it prints this: "https request returned with status 200 and body length 263484"

However when I first downloaded the library from Github Actions here, I had to override some security setting because macOS refused to load it and showed a popup saying it "can’t be opened because Apple cannot check it for malicious software."

That happened during the require call rather than after though.

I do not own a Mac

Which Mac (OS and architecture in particular) are you testing with?

[erinmaus]

Just wanted to add I ran LOVE 11.5 under Rosetta with x86_64 architecture, jit.arch returned x64 and everything works as expected. Running macOS 14.3.

[Endaris]

Hey, sorry for taking so long to get back to this.
My general process was trying to create a love 11.5 release with https using love-build.
The person who tested for me (end user, not a dev) was using a Mac mini (M1, 2020) with OS 13.6.6 Ventura, so I gave them packaged versions that kept not working when the same code functioned on Linux/Windows.

Originally I thought I may have an issue with threading in my code so I created the following repro for them as a distributed app:
love_mac_https_thread_repro-macos.zip
Using this precise release, after unzip -> install, he sent me the following result screenshot.

Based on the troubleshooting that ellraiser did for me regarding the packaging for Mac, I was assuming that the packaging is not the issue, which, given the fairly basic code of that repro - I assume you know how to unpack to get the lua code - , made me assume that something is likely wrong with the package itself. Because it runs fine for me in the distributed linux version (or windows under wine) and the only difference in code is adding that extra location to the cpath so it can be found. And it is being found so I had no better explanation than the Mac library somehow not working.

I honestly expected that there would be obvious issues trying to run it directly through love as well so I'm not sure what the difference is and if this is a packaging issue at the end of the day.

Here is some extra fluff leading to my conjecture, shouldn't really be too relevant though, just another indicator for my guess:
This is the original project I made that repro for.
I added a bunch of logging to troubleshoot the issue and that yielded that https.request returned within a millisecond only on Mac.
Distributed Mac version on the same system mentioned earlier: updater.log
Distributed Linux version on my machine: updater.log

[slime73]

Apple disallows insecure (non-https) connections by default it seems, which yours is in your actual project. There's a way to allow it in the app's info.plist (e.g. the NSAppTransportSecurity section here https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40016240/) – I'll see about improving the error message in that situation.