VistaLover

... Many thanks for this new set of updated UXP browser builds ; but... https://github.com/roytam1/UXP/commits/master appears to have been synced with official upstream prior to compilation of updated builds (e.g. 9843f04 pushes code identical to upstream 315ffd5 ), however the custom branch that you mention in your post, https://github.com/roytam1/UXP/commits/custom doesn't reflect the changes present in the master branch and hasn't been updated to contain the "May 24, 2019" code ; is this a simple omission on your part or something else ? Yes, this is c72afc3...315ffd5 ; but, as you said, this is only the official UXP changelog; it was your habit to include in the end of your post your personal/custom changes on top of the official changelog; I suspect the latest builds do include custom changes, especially because you announced so in another thread: and, if I'm not mistaken, part of these custom changes should be the ones included in: https://github.com/roytam1/UXP/commit/11ce2e0 ... but you haven't made any mention of those (?); please be kind enough and explain how things stand (?) ; and excuse me for being pedantic , but I (usually) do study GitHub changelogs and do compare the official one to your custom one; I probably belong to a very small (and, dare I say, "perverse") minority, but I can't help it... As always, huge thanks to you

... And while you were at it, you could have also used a slightly modified id string for Tab Tally 1.3.0 (or 1.2.0 etc.) for it to install in either Serpent 55.0.0 or Serpent 52.9.0: }, "applications": { "gecko": { "id": "@tab-tally-st" } } St55 still contacts AMO to check for WE add-on updates, so, based on your settings, you'll be either upgraded automatically to v1.4.0 or be prompted to do so manually... St52 currently doesn't check AMO for WE updates (due to MCP implemented changes), but this can be partially or fully restored (search one of my previous posts in this thread for how-to-do it ). Installing Tab Tally with a different to the default extension id means you won't ever be offered any additional updates from AMO (and this is a known hack if one wants to stay at a specific version of an extension without having to disable extension updates in the browser)... ... and that is why you can also remove the whole META-INF directory!

Good morning! Is "PM27's XPIProvider and friends" what is referred to as TychoAM in the UXP GitHub repo? Was that change implemented early on in UXP development (I was under the impression WebExtAM was only removed towards the end of 2018/start of 2019, when WE support in Bk52 was obliterated )? From a comment by Moonchild himself exactly a year ago: https://forum.palemoon.org/viewtopic.php?p=141539#p141539 https://forum.palemoon.org/viewtopic.php?p=141641#p141641 Best regards

... I spent the better part of last hour researching and reading on this ; the ability to install id-less extensions from AMO into Basilisk was lost (what is called a regression) when the MCP devs decided to remove the internal platform mechanism that effectuated extension signature verification; this happened early on during Basilisk's development, when the (experimental at the time) application was "baking" on top of the (now deprecated) Moebius platform... Put very simply, id-less extensions acquire first a temporary (internal) id and then a permanent one, whose strings are derived from their verified signature hash; you need to have a working internal mechanism to process the add-on's signature and then generate valid id strings for the installation to succeed; but the devs in Moebius wanted to remove that mechanism altogether and not just allow the installation of unsigned extensions, because then unsigned installed extensions would produce warnings inside about:addons (Add-ons Manager, AOM); this is indeed what happens when you install unsigned extensions in FxESR 52 with the pref xpinstall.signatures.required set to false (NB that, as I have posted in another thread, extension signature verification - in FxESR 52 - is still performed in the background for already installed signed extensions and will also be triggered when a new signed extension is about to be installed!). There wasn't uniform agreement between the dev team which features inherited from Mozilla should be kept and what regressed functionality should be restored; Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! ). If you've got spare time to spend, some Moebius era GitHub issues and pull requests are linked below: Addons - Can't install some addons: https://github.com/MoonchildProductions/moebius/issues/238 Add ID from a signature if it isn't included in manifest.json: https://github.com/MoonchildProductions/moebius/pull/251 Fix signed extension checks: https://github.com/MoonchildProductions/moebius/issues/277 (emphasis should be put on Moonchild's comment below: https://github.com/MoonchildProductions/moebius/issues/277#issuecomment-356231470 ) Get IDs for ID-less WebExtensions without breaking normal libJAR signature checking: https://github.com/MoonchildProductions/moebius/pull/279 Then the Moebius platform was left to rot... When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced: https://github.com/MoonchildProductions/UXP/issues/373 but Moonchild decreed: and he "WON'TFIX"-ed that issue... ; moot point now in the case of official Basilisk, still an issue with the Serpent 52 fork... =============================================== Disclaimer: Had a rough day today , so I might have not grasped 100% correctly what was contained inside the devs' exchanges in the linked issues/PRs; I have the sense the "general idea" is there, but anyone is free to correct any misunderstandings on my part...

... Let us just revisit Tab Tally, shall we? https://addons.mozilla.org/en-US/firefox/addon/tab-tally/versions/ All versions currently listed on AMO are, of course, of the WE format; version 1.0.0 is advertised as being compatible with Firefox 49.0+, versions 1.1.0 through to 1.3.0 advertised as being compatible with Firefox 48.0+; I was particularly interested in one of those older WE versions, because they duplicate the functionality of the XUL ("legacy") version 0.1.1, now removed from AMO (but is recoverable via the CAA extension). All (WE) Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...); of course, the latest version 1.4.0 also installs there, but with a slightly degraded (IMHO) functionality... But trying to install any one of Tab Tally versions 1.0.0 to 1.3.0 in Serpent 52.9.0, you'll be met by a failure to install in the form of message: That's because v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API). In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file: "applications": { "gecko": { "id": "@tab-tally" } } and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0) and, probably unbeknownst to him, also restored St52 compatibility; 1.4.0, as discussed previously in this thread, would install fine in St52 (but not v1.0.0-1.3.0, which do install and work fine under Firefox ESR 52.9.0... )

seems possible, will have a look later. This is most excellent news! Once again, really grateful for such stupendous support Addendum: Relevant GitHub commit: https://github.com/roytam1/UXP/commit/f4af0a7

A simple forum search could have easily taken you there :

Doesn't seem to matter though. I never claimed (or implied) that staying at NSS 3.44 Beta (instead or reverting to 3.43 Stable) would have allowed for the UXP browsers to successfully connect to the linked test server, i.e. https://tls13.1d.pw As I was already talking about the NSS library, I simply found an opportunity to mention the version downgrade I had observed; just that ... Today I borrowed briefly sister's Windows 7 SP1 64-bit laptop, where I updated stable Firefox (Quantum) to latest release 67.0 and Firefox ESR (Quantum) to latest release 60.7.0; to my great astonishment, both these Firefox versions connect successfully to the TLS 1.3 test server being discussed in this very thread; I dug around and found v60.7.0 comes with NSS 3.36.7, while v67.0 comes with NSS 3.43, the same one to be found inside the latest UXP forks released by Roy; so, despite my initial assessment, the "bug" observed here ("SSL_ERROR_RX_MALFORMED_SERVER_HELLO" error code when trying to connect to test server with latest New Moon 28/Serpent 52.9.0) doesn't appear to be only dependent on used NSS version and has been already fixed in latest Firefox Quantum releases! I persevered with my searches and, in the end, I stumbled upon a similar issue that was also affecting the Waterfox fork: https://github.com/MrAlex94/Waterfox/issues/783#issuecomment-458907249 So it looks as though the proper fix for this issue lies inside Bugzilla bug #1430268 fixed in mercurial commit: https://hg.mozilla.org/mozilla-central/rev/fafb731 @roytam1: Do you think you can somehow backport bug #1430268 to the UXP platform and thus apply it to both NM28/St52? Is a test-build even possible? If yes, then the OP (@Bersaglio) won't have to use a Chinese browser to connect with... OT: I don't mistrust myself the Chinese browsers any more than I do American ones like Google Chrome or Russian ones like Yandex Browser; all government security agencies are pretty much the same in my eyes... ; in this day and age, there's no such thing as privacy if you decide to connect to the live web...

... This doesn't add up; the New Moon 27 64-bit crash was first reported by @mockingbird in the following post: The crash was indeed due to module nss3.dll, but the reporter specifically mentioned package: https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190427-a09f31062-xpmod.7z as the one the crash occurs with... As you said, that build is the one where the NSS lib downgrade took place, https://github.com/roytam1/palemoon27/commit/a09a17de63be6e059e60559e15cca3448d362428 but still that 64-bit build would crash for the reporter... Furthermore, @roytam1's fix for that crash was announced here: soon after the 2019-05-10 New Moon 27.9.6 builds were announced; @mockingbird verified the fix: ... But looking at the posted changelog for these builds, I don't see a change in the NSS lib version, which I assume still remained at 3.43 (final), the same one inside the crashing build of 2019-04-27 ; am I missing something obvious here?

Well, the title of this thread (in the form of a question) is a tad misleading ; if the real question was Can you establish TLS 1.3 connections under Windows XP? then the answer, of course, is YES . Both UXP browsers (New Moon 28, Serpent 52.9.0), the Moebius fork (Serpent 55.0.0), the Tycho fork (New Moon 27) and probably other @roytam1's forks all support the final TLS 1.3 draft (RFC8446), as well as all three cipher suites associated with TLS 1.3: TLS_AES_128_GCM_SHA256 (0x1301) TLS_AES_256_GCM_SHA384 (0x1302) TLS_CHACHA20_POLY1305_SHA256 (0x1303) ; you can test TLS 1.3 support of these browsers with https://tls13.pinterjann.is/ https://swifttls.org/ https://cert-test.sandbox.google.com/ (and a few other test URLs...). BTW, the NSS library in these browsers was recently downgraded from v3.44 Beta to v3.43 stable release; perhaps @roytam1 could share a word (or two ...) why that was necessary ... Additionally, I was recently informed that the excellent project ProxHTTPSProxy by @heinoganda has indeed achieved TLS 1.3 support under XP for the type of browsers (IE8, Google Chrome 49 and, possibly, earlier) that don't come with their own TLS support but rely upon system libraries for secure connections; so TLS 1.3 in itself shouldn't be an issue... But what is indeed specific is the configuration of linked test server, https://tls13.1d.pw/ It is no coincidence that a Russian member of this forum brought this up, because, it turns out that, the administrator of said test server is a Russian guy, Александр Венедюхин ! In fact, he maintains a blog where he documents this project and the TLS 1.3 test configuration of the server; original articles can be found at: https://dxdt.ru/2018/08/05/8597/ https://dxdt.ru/2019/01/26/8672/ As I'm not at all fluent in Russian (), I had to enlist the help of (evil ) Google, but what the heck... : https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ I don't consider myself proficient in the field of cryptography and/or secure connections, but what I gathered from the translated text was that the server is configured to send a special HelloRetryRequest response to force a renegotiation of connection parameters; the implementation of Encrypted Server Name Indication (ESNI) along with non-ECDH manifested a bug in Mozilla's NSS library, so that is probably why the Firefox forks won't connect currently to that specific test server! (they yield a SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code ). Hopefully, the reported bug will be fixed in a future NSS version, if/when that is applied to UXP, we'll have successful connection in the UXP forks... Frankly, TLS 1.2 is still predominant, but with 1.3 steadily gaining ground; this specific connection test is but a margin case where 1.3 is involved, so I won't be losing any sleep over it...

IIRC, that was because Oracle decided they would no longer support the 32-bit OS architecture on JRE 9 and higher http://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-59701F80-5BB1-416D-835D-C39A9112FC1E

The latest version of Qihu's 360 Extreme Explorer (v11.0.2086.0, released May 16th 2019 - its default UA declares a Chromium 69.0.3497.100 compatibility ) will also pass the test : But this is on Windows Vista SP2 32-bit, not on XP SP3 32-bit (hence, one of you XP users would have to test... ) EDIT: Make sure in "flags" that chrome://flags/#tls13-variant is set to "Enabled (Final)"

Latest FileZilla 3.42.1 32-bit won't launch under Vista SP2 because of only one missing function in Vista's shell32.dll system file: ... and, actually, the very last Vista SP2 compatible version of FileZilla is 3.40.0-rc2, released on Jan 22nd 2019: You can download this Vista EoS version from the official repository at https://download.filezilla-project.org/client/ Final 3.40.0 was released three days later (Jan 25th 2019) but, as you've found out, it would run only on Win7+ FileZilla is open source, so perhaps one could recompile more recent source code to again target at least NT 6.0; here's hoping

This is most probably caused by the fact 4.6.2 Preview can be properly installed via the provided installer, while 4.6.2 Final can only be installed via a hack-ish way ; it is possible running just the .MSI (in the unpacked original setup) does not write all of the necessary registry keys and/or modify ENV VARs; most sadly, I'm not a coder so can't provide any substantial help, but googling the issue I found: https://stackoverflow.com/questions/5980847/visual-studio-2010-startup-type-initializer-for-module-threw-an-exception https://blogs.msdn.microsoft.com/rajakedar_ganta/2012/06/12/the-type-initializer-for-module-threw-an-exception/ Hope they make sense to you! Regards

... But I did say I stopped updating manually at the end of October 2017; also, some previous 4.6.1 updates were not included in my "Snipping Tool" screengrab (I would need to scroll down and take a second one to include all installed in chronological order.) ...

@Blados, @artomberus The best approach on (manually) updating a (manual) install of .NET FW 4.6.1/4.6.2/4.7.0/4.7.1/4.7.2 on Vista SP2 is to have access to a Windows 7 machine, where the exact .NET FW version is manually installed; you should then let WU check for .NET FW related updates and selectively hide upgrades to a higher version, if it's not what you have on the Vista machine (e.g. I understand that on Win7, MS will offer to upgrade you to 4.7.2 (4.8 maybe?) if you've got a previous version installed). Install only the patches offered for the .NET FW version you're interested in, then head to Control Panel => Installed Updates (for .NET FW) and write down the KB numbers of these patches. Track them down in MUC and then proceed to manually install on the Vista machine! My sister has a Win7SP1 x64 laptop, where I "froze" .NET FW to v4.6.1 and, to make a long story short, that was how I was updating my own 4.6.1 install on Vista!

4.7.2 belongs to the 4.7 family of .NET FW versions, comprising 4.7.0, 4.7.1 and 4.7.2; of course, 4.7 family isn't supported on WS2008SP2 (NT 6.0) , so, presumably, Microsoft don't test produced patch files on 4.7.x installed on WS2008SP2... However, Win7 SP1 is supported; it just so happens that the update mechanism of 4.7.x on Win7SP1 is similar to the one of patching 4.6.x under WS2008SP2, so that is why what @WinClient5270 stated above is correct To illustrate: By visiting Microsoft Update Catalog, latest updates for 4.7.2 on Win7 SP1 include, e.g. 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, and 4.7.2 for Windows 7 (KB 4495588) When you proceed to download, you are presented with file ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe Notice the ndp46-* prefix? This is exactly the same file you'd end up with if you wanted to fetch latest patch for 4.6 on WS2008SP2: 2019-05 Security and Quality Rollup for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495588) (Please also load and inspect https://www.catalog.update.microsoft.com/Search.aspx?q=KB4495588 ) On Win8+, the update mechanism of 4.7.x is different to both WS2008/Win7; there, the patches are being delivered in the form of "Windows" updates, i.e. .msu packages... 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 8.1 (KB4495585) => windows8.1-kb4495585-x86_14b43821fa547611902f85baac67e8f013c40613.msu So, we should really thank Windows 7 in this case!

If it was file dotnet-hosting-2.2.5-win.exe that you downloaded (96.3 MiB), you shouldn't have used 7-zip to unpack, but more specialised applications like Bioruebe's Universal Extractor 2 Result of extraction: I personally feel there's no way this would work under Vista, I merely wanted to point out what else to try when 7-zip fails to yield desired results...

api-ms-win-core-console-l1-1-0.dll (the module that couldn't be found and caused System.IO.FileNotFoundException) is actually part of KB2999226, aka Windows 10 Universal C Runtime (Win10UCRT), which itself is a prerequisite for Microsoft Visual C++ 2015+ on Vista SP2. Please install latest redistributable for MSVC2019 found here: https://visualstudio.microsoft.com/downloads/ (scroll down all the way to "Other Tools and Frameworks", expand, "Microsoft Visual C++ Redistributable for Visual Studio 2019", download files for both 32-bit & 64-bit and install; Windows6.0-KB2999226-x86.msu is included and will be co-installed if not found in the system). The only way to be definitive about that is if you inspect executables (*.exe & *.dll) with Dependency Walker (please do so after you've installed MSVC2019)

@UCyborg: many thanks indeed for your very erudite comment , am always keen to learn new things...

On their site (you linked to) they state: Do you reckon 7's SP1 + PU are just for .NET FW 4.7.2 compatibility reasons?

Neither could I , but here is some more test material: ShadowSocks is an application very popular in China, because it can be used to connect to specialised servers outside of the GFW and thus circumvent regime implemented censorship ; the windows binary is built on .NET Framework 4.x.x; the last executable that could be launched under Vista SP2 with 4.6.1 (Final) installed is v3.3.4 all the way back from Oct 2016 ; any more recent version will throw an error: Unlike ShareX, Shadowsocks.exe does not come with a *.config file we can patch, you do have to have 4.6.2+ installed to make it launch! In their Wiki it's noted (in Chinese) that .NET FW 4.6.2 is the minimum version required, along with latest Visual C++ 2015 Redistributable; also in their wiki they suggest So I think shadowsocks should be a perfect "test-bed" application for correctly functioning .NET FW 4.6.2/4.7.2[4.8.0?] under Vista SP2... People here with Vista SP2 VMs, the challenge is open!

armagaddon-2.0 bug (and fix) has to do with SIGNED extensions; uBlock-firefox-legacy-1.16.4.10 (from GitHub) is an UNSIGNED extension; to install it on FxESR 52.9.0[1], one must first flip (in about:config) xpinstall.signatures.required to false, restart the browser and then attempt to install; to remove warnings generated by installed unsigned extensions, read previous post in this page...

... As it finally turned out, it is yet again another case of intentional/artificial block of Vista by M$ ; the blocking code lies somewhere inside the compiled .EXE setup, but it's obviously absent in the unpacked .MSI installer.I do wonder if it's still possible to install 4.6.2 Final by running the Setup.exe file (86.1KB) that exists inside the (unpacked) directory; an inspection with Resource Hacker reveals it does indeed support Vista in its manifest: <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" /> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" /> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" /> </application> </compatibility> I guess if that doesn't work, on a 32-bit platform one should run netfx_Full_x86.msi (in the unpacked directory); as mentioned by Osman, in the root of the unpacked setup one can see prerequisite windows updates for Win8 (KB3151804), Win8.1 (KB3151864) and Win10 (KB3151900), but, surprisingly, not for Win7 (and, of course, none for WinVista, which the package doesn't officially support) - in any case, it should be stressed that the (somewhat unorthodox) 4.6.2 install shouldn't be attempted on a Vista system which isn't fully updated (SP1+SP2+all subsequent updates at least until EoS on April 2017), just for good measure... All in all, a very positive outcome from a joint effort, started by @Osman Kovan and joyfully concluded by @WinClient5270! Cheers PS: I couldn't help noticing how a 59.1 MiB file (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) blows up to more than 1.62 GiB (!) when expanded!

... Is there any specific reason you had not upgraded to the more secure 52.9.0esr version? 52.9.0esr is the last 52ESR build to have been officially released (and, of course, the last version of Firefox that would support XP/Vista), there shouldn't be any compatibility issues (extensions-wise or other) between what you now have (52.6.0esr) and the last of its breed, 52.9.0esr... Have you disabled application updates in Firefox? I was under the impression 52.6.0esr would auto-update to 52.9.0esr Best regards