-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lifting the gotosocial amd64 restriction #143
Comments
I've followed that discussion, but didn't see that there's a go build-tag for that now. |
@daenney is the restriction limited to 64bits still, or what's the limitation now? |
The tag is now turned on as an option by default in the pkgsrc package, can be turned off in custom builds. |
It should be fine on 32-bit and 64-bit platforms currently. The wazero WASM runtime should be fine, and afaik there shouldn't be any issues with the SQLite driver either. So I would expect netbsd/386, netbsd/amd64, netbsd/arm and netbsd/arm64 to work. However, I don't think anyone's tested 32-bit GtS on anything other than Linux. It's the only platform we ship 32-bits builds for as well, and only on ARM. |
for more architecture support. # - wasmsqlite3: uses SQLite through WASM instead of the C-to-Go transpilation (experimental) #143: There was initially an issue with that driver on the BSD family but that was resolved in the driver before we cut this release. It's safe to use and expected to perform just fine. We're currently keeping it behind a go build tag, wasmsqlite3, and we do consider it slightly experimental. However, the plan is to switch to this Soon™ and a number of people including two of the maintainers run this build on their own instances without any issues.
This is a point release intended to clear up a couple of CVEs and apply point fixes that have been accumulating since 5.2.1 There are a few unresolved (but minor) memory leaks related to design issues in the API that still need to be resolved. Expect those fixes in the next release. Code Fixes ---------- * Fixes for CVE-2023-48161, CVE-2022-28506, * Address SF issue #138 Documentation for obsolete utilities still installed * Address SF issue #139: Typo in "LZW image data" page ("110_2 = 4_10") * Address SF issue #140: Typo in "LZW image data" page ("LWZ") * Address SF issue #141: Typo in "Bits and bytes" page ("filed") * Note as already fixed SF issue #143: cannot compile under mingw * Address SF issue #144: giflib-5.2.1 cannot be build on windows and other platforms using c89 * Address SF issue #145: Remove manual pages installation for binaries that are not installed too * Address SF issue #146: [PATCH] Limit installed man pages to binaries, move giflib to section 7 * Address SF issue #147 [PATCH] Fixes to doc/whatsinagif/ content * Address SF issue #148: heap Out of Bound Read in gif2rgb.c:298 DumpScreen2RGB * Declared no-info on SF issue #150: There is a denial of service vulnerability in GIFLIB 5.2.1 * Declared Won't-fix on SF issue 149: Out of source builds no longer possible * Address SF issue #151: A heap-buffer-overflow in gif2rgb.c:294:45 * Address SF issue #152: Fix some typos on the html documentation and man pages * Address SF issue #153: Fix segmentation faults due to non correct checking for args * Address SF issue #154: Recover the giffilter manual page * Address SF issue #155: Add gifsponge docs * Address SF issue #157: An OutofMemory-Exception or Memory Leak in gif2rgb * Address SF issue #158: There is a null pointer problem in gif2rgb * Address SF issue #159 A heap-buffer-overflow in GIFLIB5.2.1 DumpScreen2RGB() in gif2rgb.c:298:45 * Address SF issue #163: detected memory leaks in openbsd_reallocarray giflib/openbsd-reallocarray.c * Address SF issue #164: detected memory leaks in GifMakeMapObject giflib/gifalloc.c * Address SF issue #166: a read zero page leads segment fault in getarg.c and memory leaks in gif2rgb.c and gifmalloc.c * Address SF issue #167: Heap-Buffer Overflow during Image Saving in DumpScreen2RGB Function at Line 321 of gif2rgb.c
1.8.2 (2024-09-24) What's Changed * Drop commented-out line by @olleolleolle in #108 * Add Ruby 3.1 & 3.2 to CI matrix by @tricknotes in #109 * Fix/redos by @ooooooo-q in #114 * Raise HTTPStatus::BadRequest for requests with invalid/duplicate content-length headers by @jeremyevans in #120 * Bump actions/checkout from 3 to 4 by @dependabot in #121 * Improve CI by @hsbt in #123 * Fix WEBrick::TestFileHandler#test_short_filename test not working on mswin by @KJTsanaktsidis in #128 * Fix bug chunk extension detection by @jeremyevans in #125 * Fix CI. by @ioquatix in #131 * Merge multiple cookie headers, preserving semantic correctness. by @ioquatix in #130 * Test on macos-latest by @byroot in #132 * Require CRLF line endings in request line and headers by @jeremyevans in #138 * Prefer squigly heredocs. by @ioquatix in #143 * Only strip space and horizontal tab in headers by @jeremyevans in #141 * Treat missing CRLF separator after headers as an EOFError by @jeremyevans in #142 * Return 400 response for chunked requests with unexpected data after chunk by @jeremyevans in #136 * Fix reference to URI::REGEXP::PATTERN::HOST by @casperisfine in #144 * Prevent request smuggling by @jeremyevans in #146 New Contributors * @tricknotes made their first contribution in #109 * @ooooooo-q made their first contribution in #114 * @KJTsanaktsidis made their first contribution in #128 * @byroot made their first contribution in #132 * @casperisfine made their first contribution in #144
Since GtS 0.16.0 there is a way to build with a SQLite driver that we access through WASM, which would lift the amd64 restriction currently in place as a consequence of using the modernc transpiled driver:
pkgsrc/www/gotosocial/Makefile
Lines 69 to 78 in eaf7753
There was initially an issue with that driver on the BSD family but that was resolved in the driver before we cut this release. It's safe to use and expected to perform just fine.
We're currently keeping it behind a go build tag,
wasmsqlite3
, and we do consider it slightly experimental. However, the plan is to switch to this Soon™ and a number of people including two of the maintainers run this build on their own instances without any issues.I'm not familiar enough with how pkgsrc works, but if there's some kind of way to give people the option to try it out if they want to run on aarch64, this could be a way of achieving that already before the next release.
Getting any feedback on whether this build works out well for folks running it on NetBSD would also be very helpful.
// cc @nikkicoon
The text was updated successfully, but these errors were encountered: