User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Firefox/6.0.1 SeaMonkey/2.3.1 Build ID: 20110830151746 Steps to reproduce: Downloaded Seamonkey 2.3.2 (Dutch version) Actual results: Program displays version 2.3.1 Certificate for DigiNotar is not recognized so it really is version 2.3.2 Expected results: Should display version 2.3.2
Confirming, the release notes of 2.3.2 are being shown, but the about window says 2.3.1
not sure it really is 2.3.2 - in the English, Macintosh .dmg, opening up the package, and looking at info.plist shows bundle: 2.3.1 digging down further - Contents/MacOS/application.ini: looking at the contents yields version 2.3.1 looks like the 2.3.2 readme has been bundled with the 2.3.1 application
To check if it is 2.3.2: Go to the site https://www.diginotar.nl/ When it shows an alert that the connection is insecure, it is 2.3.2 (where the root certificate of DigiNotar was removed). When the site is shown (it redirects to http://www.diginotar.nl/) you have 2.3.1 or before.
> looks like the 2.3.2 readme has been bundled with the 2.3.1 application No, that is not the case. You can verify that 'DigiNotar' is no longer shown as a Authority.
ok - the Mac version shows that dignotar.nl is untrusted, but... looking INSIDE the distribution files on 2.3.2.dmg - info.plist shows Bundle Version 2.3.1 - ../application.ini shows Version=2.3.1 can't quite dig into the binary but at least some of the files have NOT been updated to reflect 2.3.2
Just to note ... http://www.seamonkey-project.org/start/ Says, "Warning! You're using an old stable version of SeaMonkey (2.3.1), while we offer a newer version which contains important security fixes."
(In reply to therube from comment #7) > Just to note ... > > http://www.seamonkey-project.org/start/ > > Says, "Warning! You're using an old stable version of SeaMonkey (2.3.1), > while we offer a newer version which contains important security fixes." Fixed that. in short, Sadly this was an hg fail, on top of a slight configuration fail after automation fail. So what happend is this: * We bumped our version based on the cset I configured as the parent. Then tagging (another repo) failed, due to a relbranch conflict with Thunderbird. * When I re-ran tagging, I forgot to update the changeset to the newer one that was already bumped, even though I dropped the "bump the version" part to let us pass. * I noticed this error after tagging finished, but before builds started, I manually did an hg tag rather than try to rerun everything, apparantly the hg tag did not take properly: (http://hg.mozilla.org/releases/comm-release/rev/db1fd518fdf1 and http://hg.mozilla.org/releases/comm-release/rev/8ca0f604e932 were my new tagging pushes) * This left us in a state where COMM60_20110820_RELBRANCH was not the rev actually tagged This will be fixed by 2.3.3 :( (Mozilla needs to ship a slight correction to the build we just made). We will be shipping partial updates for *actual* 2.3.1 and 2.3.2 users. I apologize for the confusion.
Fixed by releasing 2.3.3