@kas1e

BTW, I know it was only test code, but you should never put data in .text, even if it is read-only. Otherwise, the LTE is likely to bite you and mangle it (I found this out the hard way in OpenSSL).

I don't think anything dumps all sections into a single segment does it? What does "objdump -ph" say?

AFAIK, it has always been the case that, at least from 2005 or so, that compilers will generate two segments. That's what happens with GCC 4.x, 11 and VBCC, at least. The first segment contains .text and .rodata (physically marked as read only when loaded - anything that writes to this segment will cause a GR) and the second contains all the other data sections (.data, .bss, .sdata, .sbss, .ctors, .dtors, etc). If there are other versions of GCC that do dump all code and data into a single segment, then that would be an incorrect thing to do.

Regarding IElf->CopyDataSegment(), as the name suggests, it copies the entire data segment (not only .data and .bss). How does it know which segment is the data segment? The original elf.library used the segment containing the .data section, whereas the latest elf.library additionally looks for .bss, .sdata and .sbss too (in case there is no .data section). I use IElf->CopyDataSegment() with both -mbaserel and -msdata.

I've not tried it, but if there were truly only a single segment containing both code and data, probably IElf->CopyDataSegment() might still work. However, it would obviously be suboptimal unnecessarily copying all the code too each time.

A little OT, but I almost forgot, AmiSSL is also restricted to GCC 4.x because it heavily relies on -mcheck68kfuncptr, which I think Stefan Burstroem added, but it never made it into newer releases. This is required for 68k programs to be able to use AmiSSL PPC because OpenSSL uses many function pointers which are user definable. The -mcheck68kfuncptr feature caused function pointers to be checked if they were 68k or PPC code, automatically running it via emulation if 68k.

I'm a little late to this thread, but thankfully @joerg has explained most things. He and I are probably only two of a handful of developers who used -mbaserel - IIRC, both OWB and Timberwolf use it. IBrowse 2.5 used to use it, but I switched to using -msdata instead...

One of the good things about -mbaserel is that the compiler allowed developers to easily restore r2 for library interface functions, for example, like __saveds did on OS3. There is no such thing for restoring r13, so you have to do the r13 save/restoring manually using asm instead.

AmiSSL is likely to always use -mbaserel because although the data size that OpenSSL uses is not yet 64K, its getting close and will no doubt go over that limit in the future. It is not feasible to patch OpenSSL to use less data.

GCC 4.0.4 (available as native and cross-compiler) was the last version to fully support -mbaserel and generate the correct code, hence why we are stuck with it for AmiSSL. IIRC, the linker and binutils from 4.2.4 did also handle baserel correctly, but the compiler itself created broken baserel code.

Libraries and startup code use the elf library CopyDataSegment() function to copy and relocate the data segment (segment, not section) and FreeDataSegmentCopy() when done with it. These functions were slightly buggy until I fixed them in V53.35.

Not to bore you with the technical details, but AmiSSL needs to maintain a file lock on the libraries with the elf.library 53.34 or older. The installer tries to expunge the libraries from memory, but this can only happen once all applications have closed it.

When the latest elf.library finally gets a public release, this shouldn't be a problem any longer, as AmiSSL no longer needs to maintain locks on the libraries in that case.

Would be interesting to find out which application is causing trouble. If you use something like Scout, you could at least see how many applications have the libraries open currently. It could indicate that an application is maybe failing to close AmiSSL properly on exit.

It is all very well trying to fix the JS to make the Cloudflare check code work in Odyssey, but IMHO it is more important to figure out why Cloudflare is serving this page to Odyssey in the first place. It is likely to have absolutely nothing to do with JS, but will be related to the HTTP headers that Odyssey is sending and the HTTP connection mode. Obviously, Cloudflare is flagging these as suspicious for Odyssey, but not for IBrowse.

It is completely safe to use Cloudflare to serve Amiga related sites, since it is highly configurable. These bot blocking checks could be switched off via a rule for Odyssey, and other Amiga browsers, for example. Obviously, non-Amiga sites are not going to want to do this.

@walkero

One of those limitations is Gemini support - it is disabled in the demo version of IBrowse.

@msteed

Those features can be switched off or adjusted globally, and also via page rules (where, for example, you could disable them using a user agent match). That said, I don't think I've ever stumbled on one of Cloudflare's captcha pages using IBrowse.

However, with Cloudflare I'd be more concerned about how much bandwidth OS4Depot uses. Cloudflare could reduce the bandwidth uses at the hosting provider, but sometimes object to sites serving a lot of large static files and cancel accounts because of it (even paid subscriptions).

Most hosting providers offer Let's Encrypt certificates free of charge - it is a feature built into cPanel, for example. So, that would be the easiest solution. Cloudflare takes a fair bit of learning to get the best out of it.

@msteed

Quote:
Um, check the IBrowse website's certificate - it has been behind Cloudflare for some time. Needless to say, it works fine in IBrowse, otherwise we wouldn't use Cloudflare.

Shouldn't cost anything at all if using Let's Encrypt.

@white

Not going to work, I'm afraid. It appears to rely unnecessarily heavily on JavaScript, failing even at the first hurdle. If you check the source code in IBrowse it attempts to redirect the page by setting window.onload, which IBrowse doesn't yet support. It could be done using meta refresh instead, or by setting the onload attribute in <body> (which was the "classic" way of using onload).

That said, even with that working in IBrowse, I fear it may then display the site, but nothing much else would work due to the heavy JavaScript usage required (for example, to read user input).

So, for now, not much that can be done. Perhaps there are other solutions out there. Privoxy is the only one that I remember from days gone by.

No need to wait: https://amissl.org/download/5.6

@walkero

That's for certain, but as SimpleMail 0.45 was compiled to use AmiSSL v4, that should be fine too as AmiSSL 4.12 supports TLS 1.3. Just need to make sure AmiSSL 4.12 is installed, obviously, before installing AmiSSL v5.

@eliyahu

Quote:
My stupidity? . The history log entry in question is "Fixed major bug in the updated lock relative i/o code".

Basically, I changed this code to directly support the new vector port filesystems. At the same time, I made some optimisations to the old code and changed a memcpy to a CopyMem without changing the argument order - ooops! The first crash would happen when trying to load the download log, with CopyMem writing to read-only memory.

Since I recently upgraded my A1XE with a SSD, with most partitions using NGFS, my system was not affected, so I didn't notice. Those using FFS2 or SFS would get the crash. It also didn't crash on my A1200, but the bug was there too and caused things to not function correctly (crashing is better to be honest!).

@broadblues

Quote:
Not directly - as you might expect with OpenSSL, things are a bit more low-level than Curl. However, you are free to add any outgoing HTTP headers as you wish, which includes adding a cookie header. See https://github.com/jens-maus/amissl/blob/master/test/httpget.c for a general example.

Retrieving a "Set-Cookie" header from the response might be more problematic. I've not played to see how or if this is possible, but it seems not. I've opened a feature request at https://github.com/openssl/openssl/issues/19609.

@amigakit

Quote:
May I ask why AmiSphereServer (and therefore Updater) doesn't itself use AmiSSL and instead uses an outdated, obsolete, statically linked OpenSSL 1.0.2o? It should be easy to make the switch and it'll make AmiSphereServer much smaller too! Please support AmiSSL, rather than waste time messing with OpenSSL directly.

As the OpenSSL team itself says: "All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used."

It appears to be using libcurl too - the latest libcurl has built-in AmiSSL v5 support, but you may not even need to use libcurl at all either. OpenSSL 3.0 has its own simple built-in HTTP(S) client.

Quote:
AmiSSL 5.5 is now available - be sure to always use AmiUpdate to grab the latest release. I'm still a bit confused why they pulled OpenSSL 3.0.6. The regression issues were relatively minor, especially when compared to the high severity buffer overflow bugs which are also fixed in 3.0.7 and were present in all OpenSSL 3.0 versions (and therefore all AmiSSL v5 releases).

@afxgroup

IIRC, the whole reason clib2 and clib2-ts co-existed in the first place was so that single threaded applications did not have all the extra overhead (both in terms of speed and size) imposed on them unnecessarily.

@trgswe

This would require the compiler suites to be changed. IMHO, it makes more sense to keep the original clib2 and name this new one clib2-ts instead, replacing the old clib2-ts which probably not many people use or have installed. The bonus being that the compilers (even going back to GCC 4), support -mcrt=clib2-ts already. That said, there may be an issue in that clib2 and clib2-ts share the same headers (but have different link libs).

@afxgroup

Having looked into this more closely, it appears GCC itself sets __CLIB2__, __THREAD_SAFE and __NEWLIB__, before any include files.

#if defined(__NEWLIB__)
#error crt=newlib
#elif defined(__CLIB2__) && defined(__THREAD_SAFE)
#error crt=clib2-ts
#elif defined(__CLIB2__)
#error crt=clib2
#else
#error unknown
#endif

With this in mind, would it not make more sense for your clib2 libs to belong in SDK:clib2/lib.threadsafe opposed to SDK:clib2/lib? And then -mcrt=clib-ts would be used to use your library and that also means __THREAD_SAFE will be defined by the compiler. I've checked and -mcrt=clib2-ts still works and links fine with GCC 11. I mean your library is technically replacement for the old clib2-ts (I still have it installed!), not clib2, IYSWIM.

@afxgroup

But, how can code conditionally detect that your clib2 is in use and not the original? For example:

#if defined(__NEWLIB__) || defined(__THREAD SAFE)
// Newlib or clib-ts
#define MALLOC_IS_THREADSAFE
#emdof

Is there some other preprocessor symbol that can be checked?

I wouldn't worry if it was for my own code as I know what I'm using, but it is for open source code that needs to be compilable on multiple configurations.