Justin Wood (Callek) wrote:
On 8/26/2011 8:49 PM, NoOp wrote:
On 08/26/2011 01:33 PM, Robert Kaiser wrote:
David E. Ross schrieb:
Is there an official, end-user release of SeaMonkey 2.3.1? I've seen
some discussion about it, but there has been no announcement here.

The surroundings have already been pointed out by Callek et al., and
http://www.seamonkey-project.org/ has it listed.

This is a very small update to 2.3, but important to install as the only
change is to ensure that we can still send future updates even once the
current certificate of our update server expires.

Robert Kaiser



That's more than a little disconcerting: "we can still send future
updates even once the current certificate of our update server expires".

If your certificate has expired then you *shouldn't* be sending *updates
at all*. You should *fix* your certificate instead!

Are you stating that SeaMonkey doesn't adhere to these:
http://www.mozilla.org/projects/security/certs/policy/
<http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html>


<http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html>



A bit overdramatic, (our release notes for 2.3.1 explicitly say what
change we made, with a link to the bug). But it was not in KaiRo's mail.
Let me briefly explain.

Our current certificate will expire soon.
We have a new certificate that we would have already switched to if not
for this issue.

The two (old and new) certificates have a different CA Root.
SeaMonkey currently only accepts the *old* CA Root (and thus the new
certificate would never give current "SeaMonkey 2.1+" an update offer).
We are unable to renew the old certificate with the same CA Root, as
they no longer issue new certs with that root.

The change is simply *adding* our new root (and another backup root) to
our "acceptable certificate" list for our updates, we are *not* simply
serving updates without a certificate.


Hey,hey! How does the existence and release of SM 2.3.1 square with the
firm promise/policy not to issue any third level: patches, fixes, updates?
Shouldn't this fix have been held for a future 2.x release?
How does this play into the code changes being tested as 2.4?
:-) :-) ;-)
Are we seeing here an unheralded policy shift? back to reality?
Perhaps a return to, at least, error fix patches, via third level
of the release numbering scheme?
i.e. stabilize 2.x via a series of 2.x.n before releasing the
planned 2.x+1 ?
--
Rostyk
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey

Reply via email to