@MickJT

The download link should be working again now (server bot check clashing with Cloudflare, which had cached the bot check!)

Also, if you don't already have DuckDuckGo in your search bar, you can easily add it by selecting the "Add..." option and then choosing DuckDuckGo from the page on the IBrowse website (I just now updated this to use their HTML interface)

@kikems

Living on borried time, I guess - it's probably a regional role-out, but it seems Google is dumping HTML. By default, IBrowse spoofs as an old MSIE version, which you can change in the URL Prefs settings, to access the nice looking plainer HTML version of Google. These old spoof strings are now being completely blocked.

So, switching to a newer spoof string gets us over that hurdle, but unless you are logged in to Google, you're then prompted to accept cookies, etc, which appears to be implemented entirely in JavaScript and does not appear or work in IBrowse.

Fortunately, I can still login to my Google Workspace account using IBrowse, using the JS bypass hack, and after doing so Google search does then work, but it obviously looks terrible compared to before.

I've mentioned the JS login hack before - I have


as a URL entry in my Macros menu, which I select on the page before the error page that usually pops up during attempted logins. But, I'm not sure if this still works on regular Google accounts.

@LiveForIt

Care to elaborate? Each opener gets their own unique library base and interface, so even if something does use SetMethod() or SetFunction(), it will only affect that application itself. This is obviously less useful than if the interface and library are shared between applications, as it would have been easy for something to patch all applications using AmiSSL, but this is not the case.

@kas1e

Usually, AmiSSL is updated and released the same day OpenSSL is updated, particularly for patch updates. Complications sometimes come with more major updates, but usually it only takes me a few days to sort out. AmiSSL has been regularly updated since v4 was released some years ago now.

You don't get all the PowerPC and AltiVec optimised code with a standard OpenSSL build, but as I say, AmiSSL is as optimised as possible for AmigaOS.

For something simple like wget, you can probably even rely on using only the supplied autoinit code. You just need to ensure you pass the native socket to SSL_set_fd() and not the clib socket wrapper.

The main thing missing from AmiSSL is the stdio functions that take a FILE * argument, simply because a shared library cannot know what clib an application used, but that isn't a big problem as not many things need those functions and you can usually use the BIO functions instead anyway.

@kas1e

Quote:
I really don't understand this - developers should not need to use OpenSSL directly and should be using AmiSSL instead. It has been an official component of OS4 since day one. Any application that uses AmiSSL gets automatic OpenSSL upgrades without needing to be rebuilt.

AmiSSL is not a heavily modified version of OpenSSL. It "is" OpenSSL optimised for AmigaOS and essentially AmigaOS native, completely independent from any C runtime. It is also fully multi-threaded, amongst other things, allowing multiple processes to share and use the code concurrently, which cannot be said of a vanilla OpenSSL.

@TiredOfLife

The lack of context didn't help your post

I don't know why your messages ended up in spam, as my email is Gmail based, which is normally ultra reliable - DKIM, SPF and DMARC all passed too. I don't normally check the spam on the IBrowse account as it rarely gets any.

The fact that there was a 5+ year gap in you originally placing the upgrade order and completing it was a little unusual - well done on keeping the email with the payment link on for so long. Perhaps I should be expiring those links after a few weeks!

There are issues with the Enhancer software. Also, never mix Enhancer and AmigaOS versions of C:AddDataTypes and LIBS:datatypes.library together, as Enhancer is not necessarily AmigaOS compatible.

What was the setting in WarpDTPrefs that was causing an issue with WebP?

@walkero

I wouldn't quite go that far. The timer issue certainly looks like a mistake was made in code, but ultimately essentially a no-op on AmigaOS. On the A600GS it triggers a stability issue due to something specific to that system. It should be fixed in the main repo, but before a fix can be confirmed, it needs to be understood when and why it broke. Having had a quick look at the diffs, it looks like Jens changed something, which was fine, but then Thore moved things around and somehow merged only some of Jens' changes, which is when it broke. I'd be more inclined to revert Thore's mistake, which is a different way to fix it. Additionally, everywhere that uses the new timer code needs to be checked to make sure no mistakes were made in any other instances.

The more recent fix related to MUIM_GoActive is not a bug in YAM. It is doing nothing wrong and other MUI applications do the same thing. It's a bug in Zune and that should be fixed instead.

IMHO, these fixes are workarounds purely to get YAM running on the A600GS, when in the fact the root cause of the stability issues is actually outside of YAM and has not been addressed.

@amigakit

Quote:
That is not how things work - it should have been fed back via a pull request instead. That is how anybody can openly contribute to open source projects on GitHub and be fully credited for their work too.

The timer bug is completely harmless, but happens to trigger a bug in the A600GS VBLANK timer (number overflow, if I were to guess). It involves birthday reminders, which are getting set too far in the future, so will never be shown. It is as such an extremely minor bug in terms of AmigaOS, but I have yet to look through the commit logs to acertain if the fix is correct or not (it depends on if there is a record of something changing which broke this, assuming it worked once upon a time).

The more recent bug reported today is actually a bug in Zune, not YAM, so it should be fixed in the correct place because it will cause trouble with other MUI applications too - not only YAM.

@kas1e

No, AmigaKit has nothing whatsoever to do with AmiSSL - only Hyperion have made a contribution to the development... Way back when AmiSSL was closed-source, some sort of deal was done with Hyperion to make AmiSSL (v3) a integral component of AmigaOS 4.0, hence why the libs are installed in LIBS: and the cmd in C:, for example (they go in AmiSSL: on other systems). It is still a key component of AmigaOS 4.x, of course, and AmiUpdate also uses it to support HTTPS downloads.

I have full control of the releases to GitHub, AmiUpdate and Aminet, hence those are the only official release channels. AmiUpdate gets AmiSSL from GitHub and I hope Updater does the same, if only for the download counters there ;). We make it available on Aminet to make it easy to download using plain HTTP.

As always, I am keen to encourage all developers to make use of AmiSSL. It means users get the latest OpenSSL fixes and CA certs. Developers also gain this feature without have to rebuild their software, which they would have to do if statically linking with OpenSSL (which also heavily bloats their software and memory requirements). The last thing we need is a competing SSL solution - no need to reinvent the wheel (like the MorphOS team decided to do in thier infinite wisdom), with everyone benefitting from one solution instead.

So, with this in mind, I have nothing against it being distributed on Updater too, just as long as AmiSSL is never misrepresented as being an AmigaKit/A-EON product (or indeed a Hyperion product!). Now being open-source, the AmiSSL license does not prevent this, obviously. To be honest, the only weird thing is this thread - surely when users run Updater (or AmiUpdate), they will see there is an update for AmiSSL, or any other software, so really no need to announce it here too!

As far as A600GS is concerned, I am still looking for somebody to work on 68K asm optimised code in AmiSSL. It currently only has very limited optimisations, compared to PowerPC. AmiSSL could greatly benefit from the increased performance that 68K optimised AES and SHA would bring, for example.

I found a thread elsewhere where it was said the issue happens with the OEM IBrowse 2.4 supplied with OS4 - can you confirm that too?

If this is the case, the persistent connections setting shouldn't be a factor. It got me wondering what happens if you set the thread priorities to 0 in the IBrowse network settings? By default, they range from -1 to -3, IIRC. Perhaps this could be causing a race condition with the network device driver.

You could try switching off persistent connections in the IBrowse network settings. Not an ideal solution, but if this helps, it probably points to a bug in the device driver for your network card. There were a couple of reports like this for OS3, but so far nobody has pinned it down to anything.

@Isense

Which version of IBrowse? Does it happen with both 2.5.9 and 3.0a? If you still have the original IBrowse 3.0, be sure to update to 3.0a.

I guess I should have left it running longer. I was cloning to the ram disk, but mine stops at around 6% with this error:

libgit error (12): SSL error: received early EOF(64490/1267719)

Seems like Github is terminating the connection for some reason, which may or may not have something to do with the old OpenSSL version that sgit uses.

@Raziel

AFAIK, sgit doesn't use AmiSSL, so it is irrelevant looking at that. At least, the version I have is directly linked against the 7 year old OpenSSL 1.0.1u.

For me, the github clone command still works fine, but it could be that I get connected to a different location (to a server that has not been updated yet).

@LiveForIt

"avail flush" doesn't expunge libraries anymore. If you overwrite or rename it, an expunge attempt will be triggered.

The AmiSSL libraries need to maintain an open ElfHandle so that a copy of the data segment can be made for each opener of AmiSSL. With elf.library before 53.35, this meant a file lock too.

@klesterjr

You'll be waiting a long time - there is no typo

It is different on OS3 - you can just overwrite libs even if they are loaded into memory and in use. Due to some very boring details, when the AmiSSL libraries are in memory on OS4, the libraries have file locks on them, so the installer can't simply copy the new versions over them (object in use error). So, the installer does some tricks to flush the libraries from memory, so it can then copy the libraries over. But, if something is still actually using AmiSSL, this can't happen, hence the error.

This is/was a limitatation of elf.library and I have rewritten the code there to fix this, but this hasn't been publically released yet, although has been supported in AmiSSL since v5.6.

@eliyahu

Yes, sorry, the installer doesn't yet take care of any custom images you may have specifying in your settings :(. It is quite tricky to deal with, but I should have at least mentioned it in the installer, so users like you know that they will need to copy them to your 3.0 drawer manually.

No issues have been raised regarding AmiSSL - it sounds like an installation issue. @jabirulo listed the correct libraries, if you have v3, v4 and v5 all installed. It is critical that amisslmaster.library is v5.12.

@daveyw

Quote:
Yes, I did ponder heavily over what to do in cases like this - I should probably have mentioned in the installer that you'll need to copy over any custom images manually, just as you installed them originally.

The thinking was that some users may either not have installed any custom images or may have a load of junk in there. Those who upgraded their installs from a 2.3 or earlier install, this will be especially true - they might even have the old pre-2.4 imageset installed still (it bugs me when I see people posting screenshots with those old images, which we already changed 17 years ago!).

If this is the worst thing to go wrong with the 3.0 release, I'll be very happy . Certainly, this is something I can revisit for 3.1, to see if I can come up with a better solution, although obviously it is too late for those who already upgraded.