Re: Updates: General
Edmund Wong wrote: > It is also not likely that we'd set the update system to use > SSLv3 or TLSv1 (thanks to Heartbleed, Poodle, and whatever > else) and set to a lower cypher set. Despite the attacks listed I believe supporting TLSv1 with a very limited cypher set should be possible. Even SM 1.1.x does support ecdhe_ecdsa_aes and ecdhe_rsa_aes. Since these cyphers are enabled by default supporting them with TLSv1 on the server should be fine. Regards, Gunther ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Edmund Wong wrote: Hi All, I hope all is well with everyone. I've been spending a lot of time working on the update system. When I started this project some time ago, I had just wanted to use the old system and update (pun not intended)it. Gave up that idea and went for something else. Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. I had the intention of setting up the new system such that all versions (2.0 to 2.53.5.1 etc) can update properly. After getting a simple working prototype running, I realized that it's no longer possible to even update anything <= 2.23. To be honest, I always thought (probably just assumed) that the main problem with updating from older versions was that the Mozilla server they were hard-coded to check for updates ceased to exist (or at least stopped hosting SeaMonkey updates). So you were having to set up a new server to host updates, but even then older versions wouldn't know about it so wouldn't pick up any updates. I hadn't realised there was any possibility that new infrastructure might eventually enable those older versions to update as well. There's bound to come a point, though, where an old version is just too old to be able to support updating automatically! -- Mark. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Don Spam's Reckless Son wrote on 07/12/20 21:40: Edmund Wong wrote: Hi All, I hope all is well with everyone. I've been spending a lot of time working on the update system. When I started this project some time ago, I had just wanted to use the old system and update (pun not intended)it. Gave up that idea and went for something else. Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. I had the intention of setting up the new system such that all versions (2.0 to 2.53.5.1 etc) can update properly. After getting a simple working prototype running, I realized that it's no longer possible to even update anything <= 2.23. Our update site uses TLSv1.1 or 1.2 (and a better set of cyphers) which these versions don't support and it's no longer possible to patch these versions to support TLSv1.1 or TLSv1.2. It is also not likely that we'd set the update system to use SSLv3 or TLSv1 (thanks to Heartbleed, Poodle, and whatever else) and set to a lower cypher set. Errors: Version 2.1 to 2.23 gets a 'ssl_error_no_cypher_overlap' error. Version 2.0x gets a "Data transfer interupted" error. I haven't tested version 1.x. or the Mozilla Suite. So, I have come to the conclusion that it doesn't seem possible to update 2.0 to the latest and greatest. Here's a list of versions and their supported status: Versions o Mozilla Suite, 1.x, 2.0x, <= 2.23 : Not supported. [Related gecko versions: 1.8, 1.8.1, 1.9.1, <= 26 o versions >= 2.24: Supported [related gecko versions: >= 27] This is only considering versions as they are; Not the underlying operating system support. That's my update on the updates. [Probably going to be an update to this update that updates on the update...etc... ad nauseum] We're nearly there. I just need to make sure that the update process won't update systems that *shouldn't* be updated. i.e Updating 2.49.5 to 2.53 on a Winxp system or, in the case of Linux distros own compiled versions, they also won't be updated. [Though I have been told that Linux distros-own compiled versions won't query the update server.] Edmund Just one question to that: I have an ancient profile which I found on an unused machine and where I'd like to at least have access to the emails there. Would a modern Seamonkey be able to understand them; are the profile incompatibilities in the email handling, the browser side or in common parts such as password handling? "ancient" certainly means < 2.24 and it may even mean < 2.0. Don, might it be possible to use MozBackup to backup the old profile, copy the file to your new(er) computer and then use MozBackup to expand the (old) profile into a (new) profile to see if your new(er) SeaMonkey can make any sense of it?? -- Daniel User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.5.1 Build identifier: 20201115194905 Linux User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623 ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
On 12/7/2020 4:05 PM, Edmund Wong wrote: What I do know is that there was never an automatic upgrade path from < 2.0 to 2.0. It was always manual. I think the best way is to backup the profile, and upgrade SeaMonkey manually from < 2.0 to 2.0, then 2.0 to 2.1..etc up until 2.24 (while backing up the profile as you go). The release notes of the various versions should offer some guidance. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Don Spam's Reckless Son wrote: > Edmund Wong wrote: >> Hi All, >> >> I hope all is well with everyone. >> >> I've been spending a lot of time working on the update system. When I >> started this project some time ago, I had just wanted to use the >> old system and update (pun not intended)it. Gave up that idea and went >> for something else. >> >> Now fast forward a few years to 2020 after working on this on-and-off. >> With the release process still being half-manually generated (though >> the process has gotten a bit faster), I figured I'd tackle this update >> issue once and for all. >> >> I had the intention of setting up the new system such that all versions >> (2.0 to 2.53.5.1 etc) can update properly. After getting a simple >> working prototype running, I realized that it's no longer possible to >> even update anything <= 2.23. >> >> Our update site uses TLSv1.1 or 1.2 (and a better set of cyphers) which >> these versions don't support and it's no longer possible to patch these >> versions to support TLSv1.1 or TLSv1.2. >> >> It is also not likely that we'd set the update system to use >> SSLv3 or TLSv1 (thanks to Heartbleed, Poodle, and whatever >> else) and set to a lower cypher set. >> >> Errors: >> Version 2.1 to 2.23 gets a 'ssl_error_no_cypher_overlap' error. >> >> Version 2.0x gets a "Data transfer interupted" error. >> >> I haven't tested version 1.x. or the Mozilla Suite. >> >> >> So, I have come to the conclusion that it doesn't seem possible to >> update 2.0 to the latest and greatest. >> >> Here's a list of versions and their supported status: >> >> Versions >> >> o Mozilla Suite, 1.x, 2.0x, <= 2.23 : Not supported. >> [Related gecko versions: 1.8, 1.8.1, 1.9.1, <= 26 >> >> o versions >= 2.24: Supported >> [related gecko versions: >= 27] >> >> This is only considering versions as they are; Not the underlying >> operating system support. >> >> That's my update on the updates. [Probably going to be an update to >> this update that updates on the update...etc... ad nauseum] >> We're nearly there. I just need to make sure that the update process >> won't update systems that *shouldn't* be updated. i.e Updating 2.49.5 >> to 2.53 on a Winxp system or, in the case of Linux distros own compiled >> versions, they also won't be updated. [Though I have been told >> that Linux distros-own compiled versions won't query the update >> server.] >> >> >> Edmund >> > > Just one question to that: I have an ancient profile which I found on an > unused machine and where I'd like to at least have access to the emails > there. > Would a modern Seamonkey be able to understand them; are the profile > incompatibilities in the email handling, the browser side or in common > parts such as password handling? "ancient" certainly means < 2.24 and > it may even mean < 2.0. > There will definitely be incompatabilities which could cause either SeaMonkey to crash or the profile getting corrupted. This would definitely apply to anything < 2.0. As for the differences, unfortunately, I don't know the inner workings of the profile code to tell which part would work and which part won't. What I do know is that there was never an automatic upgrade path from < 2.0 to 2.0. It was always manual. I think the best way is to backup the profile, and upgrade SeaMonkey manually from < 2.0 to 2.0, then 2.0 to 2.1..etc up until 2.24 (while backing up the profile as you go). Again, I apologize for not being too specific or helpful. Edmund ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
On 12/7/20 5:34 PM, mozilla-lists.mbou...@spamgourmet.com wrote: WaltS48 wrote: On 12/7/20 2:43 PM, Gerry Hickman wrote: Edmund Wong wrote: Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. The way it works on Linux distros is really much better than I remember on Windows where individual apps had their own updaters with their own schedules, installers, and admin rights. On Linux distros, you run a simple command and the whole o/s (and all apps) offer their updates. The issue for Edmund is trying to ensure that, when SeaMonkey is built by a distro and installed via their package manager, SeaMonkey's built-in updater doesn't interfere with that. The system package keeps track of files it installs, so that they can be removed as necessary when the package is updated or uninstalled. If SeaMonkey installed an update through its own mechanism, that would be outside the control and knowledge of the system's package manager and could break future updates and uninstalls. > Some applications provide a build-time option to disable automatic updates. I don't know if SeaMonkey has such an option, but if it does the onus might be on the people building packages for distros to use that option to disable SeaMonkey's updates. Not sure where that would leave Ubuntuzilla though, as I think they simply package the official builds, so probably wouldn't be compiled with that option. The Firefox and Thunderbird builds built by Ubuntu have "--disable-updater" in the configure options. Ubuntu doesn't provide SeaMonkey in its main repo anymore. For SeaMonkey on Ubuntu (and its derivatives such as Mint), there's the Ubuntuzilla repository: https://sourceforge.net/p/ubuntuzilla/wiki/Main_Page/ I'm not interested in adding any other repositories. I have to download and install each new version over the old. An internal app update mechanism would be greatly appreciated. Even if SeaMonkey's built-in updater did work, personally I'd still use Ubuntuzilla since I find it more convenient to manage updates through the system's package manager, along with everything else. I'd rather use the SeaMonkey built-in updater since the system's package manager doesn't provide the application. I actually prefer the Windows way of installing and updating the applications from their developers. -- OS: Ubuntu Linux 18.04LTS - Gnome Desktop https://www.thunderbird.net/en-US/get-involved/ https://give.thunderbird.net/en-US/ ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
WaltS48 wrote: On 12/7/20 2:43 PM, Gerry Hickman wrote: Edmund Wong wrote: Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. The way it works on Linux distros is really much better than I remember on Windows where individual apps had their own updaters with their own schedules, installers, and admin rights. On Linux distros, you run a simple command and the whole o/s (and all apps) offer their updates. The issue for Edmund is trying to ensure that, when SeaMonkey is built by a distro and installed via their package manager, SeaMonkey's built-in updater doesn't interfere with that. The system package keeps track of files it installs, so that they can be removed as necessary when the package is updated or uninstalled. If SeaMonkey installed an update through its own mechanism, that would be outside the control and knowledge of the system's package manager and could break future updates and uninstalls. Some applications provide a build-time option to disable automatic updates. I don't know if SeaMonkey has such an option, but if it does the onus might be on the people building packages for distros to use that option to disable SeaMonkey's updates. Not sure where that would leave Ubuntuzilla though, as I think they simply package the official builds, so probably wouldn't be compiled with that option. SeaMonkey is already in EPEL for example, so it's a ten second job to update it. You don't need to run an exe file (installer), you just copy a few files, and you can even downgrade. What is EPEL? Extra Packages for Enterprise Linux. It's a non-default repository with additional packages for Red Hat (and derivatives such as CentOS). No good for Ubuntu though, as Red Hat uses RPM packages and Ubuntu uses Deb packages. Ubuntu doesn't provide SeaMonkey in its main repo anymore. For SeaMonkey on Ubuntu (and its derivatives such as Mint), there's the Ubuntuzilla repository: https://sourceforge.net/p/ubuntuzilla/wiki/Main_Page/ I have to download and install each new version over the old. An internal app update mechanism would be greatly appreciated. Even if SeaMonkey's built-in updater did work, personally I'd still use Ubuntuzilla since I find it more convenient to manage updates through the system's package manager, along with everything else. -- Mark. ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
WaltS48 wrote: What is EPEL? Ubuntu doesn't provide SeaMonkey in its main repo anymore. I have to download and install each new version over the old. An internal app update mechanism would be greatly appreciated. EPEL is "Extra Packages for Enterprise Linux", you can add it as a repository to either RHEL (Red Hat Enterprise Linux) or to CentOS. The packages are in RPM format, (Red Hat Package Manager). The package manager is a robust way to manage installed programs, for example checking dependencies and preventing conflicts. Ubuntu uses APT and *.deb packages. -- Gerry Hickman (London UK) ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
On 12/7/20 2:43 PM, Gerry Hickman wrote: Edmund Wong wrote: Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. The way it works on Linux distros is really much better than I remember on Windows where individual apps had their own updaters with their own schedules, installers, and admin rights. On Linux distros, you run a simple command and the whole o/s (and all apps) offer their updates. SeaMonkey is already in EPEL for example, so it's a ten second job to update it. You don't need to run an exe file (installer), you just copy a few files, and you can even downgrade. What is EPEL? Ubuntu doesn't provide SeaMonkey in its main repo anymore. I have to download and install each new version over the old. An internal app update mechanism would be greatly appreciated. -- OS: Ubuntu Linux 18.04LTS - Gnome Desktop https://www.thunderbird.net/en-US/get-involved/ https://give.thunderbird.net/en-US/ ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Don Spam's Reckless Son wrote: Just one question to that: I have an ancient profile which I found on an unused machine and where I'd like to at least have access to the emails there. Would a modern Seamonkey be able to understand them I'd say it's important that you upgrade (and test) any old profiles as soon as possible, so they're at least compatible with the current version. Make (and keep) a backup before upgrading. -- Gerry Hickman (London UK) ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Edmund Wong wrote: Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. The way it works on Linux distros is really much better than I remember on Windows where individual apps had their own updaters with their own schedules, installers, and admin rights. On Linux distros, you run a simple command and the whole o/s (and all apps) offer their updates. SeaMonkey is already in EPEL for example, so it's a ten second job to update it. You don't need to run an exe file (installer), you just copy a few files, and you can even downgrade. -- Gerry Hickman (London UK) ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Re: Updates: General
Edmund Wong wrote: Hi All, I hope all is well with everyone. I've been spending a lot of time working on the update system. When I started this project some time ago, I had just wanted to use the old system and update (pun not intended)it. Gave up that idea and went for something else. Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. I had the intention of setting up the new system such that all versions (2.0 to 2.53.5.1 etc) can update properly. After getting a simple working prototype running, I realized that it's no longer possible to even update anything <= 2.23. Our update site uses TLSv1.1 or 1.2 (and a better set of cyphers) which these versions don't support and it's no longer possible to patch these versions to support TLSv1.1 or TLSv1.2. It is also not likely that we'd set the update system to use SSLv3 or TLSv1 (thanks to Heartbleed, Poodle, and whatever else) and set to a lower cypher set. Errors: Version 2.1 to 2.23 gets a 'ssl_error_no_cypher_overlap' error. Version 2.0x gets a "Data transfer interupted" error. I haven't tested version 1.x. or the Mozilla Suite. So, I have come to the conclusion that it doesn't seem possible to update 2.0 to the latest and greatest. Here's a list of versions and their supported status: Versions o Mozilla Suite, 1.x, 2.0x, <= 2.23 : Not supported. [Related gecko versions: 1.8, 1.8.1, 1.9.1, <= 26 o versions >= 2.24: Supported [related gecko versions: >= 27] This is only considering versions as they are; Not the underlying operating system support. That's my update on the updates. [Probably going to be an update to this update that updates on the update...etc... ad nauseum] We're nearly there. I just need to make sure that the update process won't update systems that *shouldn't* be updated. i.e Updating 2.49.5 to 2.53 on a Winxp system or, in the case of Linux distros own compiled versions, they also won't be updated. [Though I have been told that Linux distros-own compiled versions won't query the update server.] Edmund Just one question to that: I have an ancient profile which I found on an unused machine and where I'd like to at least have access to the emails there. Would a modern Seamonkey be able to understand them; are the profile incompatibilities in the email handling, the browser side or in common parts such as password handling? "ancient" certainly means < 2.24 and it may even mean < 2.0. -- spammo ergo sum, viruses courtesy of https://www.nsa.gov/malware/ ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
Updates: General
Hi All, I hope all is well with everyone. I've been spending a lot of time working on the update system. When I started this project some time ago, I had just wanted to use the old system and update (pun not intended)it. Gave up that idea and went for something else. Now fast forward a few years to 2020 after working on this on-and-off. With the release process still being half-manually generated (though the process has gotten a bit faster), I figured I'd tackle this update issue once and for all. I had the intention of setting up the new system such that all versions (2.0 to 2.53.5.1 etc) can update properly. After getting a simple working prototype running, I realized that it's no longer possible to even update anything <= 2.23. Our update site uses TLSv1.1 or 1.2 (and a better set of cyphers) which these versions don't support and it's no longer possible to patch these versions to support TLSv1.1 or TLSv1.2. It is also not likely that we'd set the update system to use SSLv3 or TLSv1 (thanks to Heartbleed, Poodle, and whatever else) and set to a lower cypher set. Errors: Version 2.1 to 2.23 gets a 'ssl_error_no_cypher_overlap' error. Version 2.0x gets a "Data transfer interupted" error. I haven't tested version 1.x. or the Mozilla Suite. So, I have come to the conclusion that it doesn't seem possible to update 2.0 to the latest and greatest. Here's a list of versions and their supported status: Versions o Mozilla Suite, 1.x, 2.0x, <= 2.23 : Not supported. [Related gecko versions: 1.8, 1.8.1, 1.9.1, <= 26 o versions >= 2.24: Supported [related gecko versions: >= 27] This is only considering versions as they are; Not the underlying operating system support. That's my update on the updates. [Probably going to be an update to this update that updates on the update...etc... ad nauseum] We're nearly there. I just need to make sure that the update process won't update systems that *shouldn't* be updated. i.e Updating 2.49.5 to 2.53 on a Winxp system or, in the case of Linux distros own compiled versions, they also won't be updated. [Though I have been told that Linux distros-own compiled versions won't query the update server.] Edmund ___ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
