Tuesday, October 29, 2019

SourceForge download issues (and Github issues issues)

There are two high-priority problems currently affecting TenFourFox's download and development infrastructure. Please don't open any more Tenderapp tickets on these: I am painfully aware of them and am currently trying to devise workarounds, and the more tickets get opened the more time I spend redirecting people instead of actually working on fixes.

The first one is that the hack we use to relax JavaScript syntax to get Github working (somewhat) is now causing the browser to go into an infinite error loop on Github issue reports and certain other Github pages, presumably due to changes in code on their end. Unfortunately we use Github heavily for the wiki and issues tracker, so this is a major problem. The temporary workaround is, of course, a hack to relax JavaScript syntax even further. This hack is disgusting and breaks a lot of tests but is simple and does seem to work, so if I can't come up with something better it will be in FPR17. Most regular users won't be affected by this.

However, the one that is now starting to bite people is that SourceForge has upgraded its cipher suite to require a new cipher variant TenFourFox doesn't support. Unfortunately all that happens is links to download TenFourFox don't work; there is no error message, no warning and no explanation. That is a bug in and of itself but this leaves people dead in the water being pinged to install an update they can't access directly.

Naturally you can download the browser on another computer but this doesn't help users who only have a Power Mac. Fortunately, the good old TenFourFox Downloader works fine. As a temporary measure I have started offering the Downloader to all users from the TenFourFox main page, or you can get it from this Tenderapp issue. I will be restricting it to only Power Mac users regardless of browser very soon because it's not small and serves no purpose on Intel Macs (we don't support them) or other current browsers (they don't need it), but I want to test that the download gate works properly first and I'm not at my G5 right this second, so this will at least unblock people for the time being.

For regression and stability reasons I don't want to do a full NSPR/NSS update but I think I can hack this cipher in as we did with another one earlier. I will be speeding up my timetable for FPR17 so that people can test the changes (including some other site compatibility updates), but beta users are forewarned that you will need to use another computer to download the beta. Sorry about that.

8 comments:

  1. [ChrisT.] Beta testers using 10.5 can use Leopard Webkit (presuming they've already installed it) to download from SourceForge.

    ReplyDelete
  2. Thanks for all your work on maintaining a web browser for old Macs. I somehow ended up with two PowerMac G5s randomly this year; a Dual 1.8Ghz, and a dual 2.5ghz, and TenFourFox has made them usable. Keep squeezing features, speed, and fun out of TenFourFox for us. =)

    ReplyDelete
  3. In about:config I toggled

    "network.http.spdy.enforce-tls-profile"

    to false and was able to get the sourceforge page to load. I was able to download one of the smaller addons, so downloads seem to work as well.

    I don't know what changing this pref does to security in general, though, so maybe it would best only to change it when you need to download something, and then change it back.

    ReplyDelete
    Replies
    1. Nice find! This pref simply allows TLS < 1.2 on an HTTP/2 connection. While this is not the actual problem, it does narrow it down, though it still looks like a cipher issue (it enforces TLS 1.2, adequate key security such as DH 2048bit or ECDH 224, and an AEAD cipher). I'll need to do more debugging to see what is actually failing the check but this is a helpful discovery. What made you think of trying it?

      Delete
    2. Essentially, my lack of any expertise made me try it. I looked at any pref that listed tls or ssl and tried a few. Also (and I say this with humor, but without ridicule) I was inspired by our friend Tobias: having read this blog and seen TFF in development for these many years, his methods seem to include a reasonably large dose of "I wonder what happens when you press this button?" as a strategy. Or, as Woody Harrelson says in Zombieland "Tell me, is it better to be smart - or lucky?"

      Now, in relation to the Github problem, I also tried randomly toggling a few prefs related to javascript and found nothing that helped, at least in the current build of TFF. However, I do have a developer build that someone (probably on MacRumors) did from June of last year - so probably from the FPR7 or FPR8 era. It let the issue reports load just fine, with no pref changes required, though Github does complain about using an unsupported browser with that version.

      My question to you (and Tobias, and any other knowledgeable developer) is: if the javascript syntax used by TFF was not as "relaxed" at that point (FPR7 or 8), would Github be more or less functional using that previous level of strictness? Or does returning to a more rigorous javascript cause more problems than it solves?

      Anyway, thank you and your contributors for keeping these Macs viable for this long. We're lucky you're all smart enough to do the seemingly impossible.

      Delete
  4. So, somewhat randomly playing with prefs again,

    "javascript.options.asyncfuncs" set to false

    allows issues to load on the github wiki using FPR 16.1.


    The browser console shows "SyntaxError: async functions are not enabled in the parser", but the page loads. I suppose this refers back to the async/await issue that tries the soul of man? Interestingly, I also noticed that this pref doesn't exist in the older version of the browser I was testing with before.

    ReplyDelete
  5. Sorry about the repeated comments, but looking at the about:buildconfig for the old version of TFF I had, it turns out that was a G3 build, so I downloaded the current G3, and it behaves differently than the current G5 build.

    * In the G3 build, github issues pages load fine with FPR 16.1, regardless of whether "javascript.options.asyncfuncs" is set to true or false.

    * In the G5 build, the issues only load when that pref is set to false.

    * In the G3 build the drop-down links on the top of the github page don't display, and the site complains that github "no longer supports old versions."

    * In the G5 build, the drop-down links do display, and github doesn't call out TFF as an old browser.

    On a happier note, the sourceforge page now loads without needing to change enforce-tls-profile (in either build of the browser), so I guess sourceforge fixed the error on their end.

    ReplyDelete
  6. Two addons that have really helped me are a button to disable CSS when needed and another that with a click of the button and page-refresh, shuts off javascript. Might well be worth permanently add a feature like these to the browser either as buttons on the Menubar or under the top-menu. Have to link to the addons on dropbox if anyone else wants them.

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.