Hello @ports Damien, Stuart and Theo.

I'm attaching Forgejo 13.0.1 port, which was released two days ago.

This works Ok on OpenBSD 7.8 -current amd64.

I fixed the following issue:
  >>> ld: error: undefined symbol:
code.gitea.io/sdk/gitea.(*Client).getParsedResponse

The root cause of the build issue in Forgejo 13.x.x lies in a "hack"
introduced since version 11.0.0 to resolve a visibility limitation 
within the
Gitea SDK. The function essential for low-level request execution and API
response parsing (getParsedResponse) is defined as non-exported (private)
within the SDK package.

To allow the migration code to access this function, Forgejo developers
created the workaround gitea_sdk_hack.go, which utilized the //go:linkname
directive. This directive is a bypass tool that attempts to force linkage to
private symbols. This practice is insecure and broke the building 
process. It
failed catastrophically under OpenBSD, preventing binary generation.

I strongly advise against modifying the SDK to make the getParsedResponse
function public for the following security reasons:

PoLP Violation: Exposing this low-level primitive for request execution
compromises security encapsulation. The responsibility for authentication
(tokens, headers) must reside within the SDK's Client object, not in the
consuming module.

Increased Attack Surface: Making this function public would introduce a new
vector for attack that could be exploited by external code. It would weaken
control over authenticated request execution, increasing the risk of API
manipulation.

To eliminate the //go:linkname "hack", I implemented the doRawAPIRequest
function within the migrations package.

The Forgejo 13.0.1 binary compiles successfully for now, but it requires 
extensive testing.

Purple Rain

On 10/18/25 10:44 AM, Stuart Henderson wrote:
> On 2025/10/18 05:27, Theo Buehler wrote:
>> On Fri, Oct 17, 2025 at 08:23:26PM +0000, Purple Rain wrote:
>>> Hello ports@ and Damien
>>>
>>> Here is a updated port www/forgejo 7.0.16
>>>
>>> This works OK on SecBSD and OpenBSD-7.8-current amd64.
>> Is there a reason to stick with 7, which is EOL since July 2025?
>> I would have expected a port to target 13, or at least 11.
> Looking at https://forgejo.org/docs/latest/admin/release-schedule/
> I wonder if LTS (currently 11) might align better with our schedule.
>
> The patches to default config seem excessive and easily result in
> conflicts for updates.
>
> For starters most of the overridden paths seem to have sane defaults
> relative to AppWorkPath so perhaps set that via --work-path in
> daemon_flags and use the default paths or relative paths? (if you can
> avoid needing SUBST_CMD for patched files, that will also simplify
> updating patches). That also avoids missed patches if an update addds a
> new configurable path.
>
> I'd tend to avoid patching the .ini for personal preferences and
> restrict it to just changes needed for the port, unless really
> important. Again to reduce conflicts for updates.

• forgejo.tgz (15K)