Firefox 3.0 and openSUSE 11.0

Posted on by

Since I saw some comments/requests during openSUSE 11.0’s beta phase that Firefox is still at 3.0b5 level even as Firefox 3.0rc1 is already out I want to give a short comment on what the plans are.
In openSUSE’s roadmap there was a freeze for packages containing cryptographic algorithms at April 7th. At that point Firefox 3.0b5 was current and so it’s not allowed to make cryptographic changes after that date. As Firefox depends heavily on Mozilla’s NSS which holds these algorithms we have to keep them in sync to be sure everything works.
When openSUSE 11.0 gets finally released there will be an online update to the latest Firefox package.
If you want to test what actually will end up in that package you can subscribe to the buildservice repository mozilla:beta and get the latest package there.
You are welcome to report issues with that in Novell bugzilla’s Firefox component mentioning that you use the buildservice package.

Share

9 thoughts on “Firefox 3.0 and openSUSE 11.0”

  1. I must admit I don’t really understand the situation.
    Why there is a “crypto freeze”? I suppose it’s to have time to test (the important) cryptographic algorithms. But then are you saying that these cryptographic algorithms that have been so tested in betas… are going to be updated the first day openSUSE is released???

  2. crypto freeze is needed because of US export regulations. Don’t ask me for details but I understand that every export of cryptographic software has to be approved from US authorities (you know Novell is a US company).
    And about your second statement: Yes, the crypto stuff gets updated then but you also can see how to test the latest stuff and it’s not like it was a major update or so. So far there are not a lot of changes in NSS between current and beta version.

  3. Why realise openSUSE 11.0 with a beta version of Firefox? I think it should be better to stay with teh last stable version…
    The browser is an important part for the secutity of a OS. I’ll never feel secure to committ a bank transition with a browser in its beta or RC version…

  4. There were several reasons for that decision:
    1. Firefox’ roadmap wasn’t fixed and FF3 was expected much earlier
    2. The last stable version is 2.0.0.x and most people would complain having that version instead of a new major version which was released even before the upcoming openSUSE version will be released.
    3. Once openSUSE 11.0 is released people want to run an update anyway and will get the latest greated (final) Firefox version

  5. > And about your second statement: Yes, the crypto stuff gets updated
    > then but you also can see how to test the latest stuff and it’s not like it
    > was a major update or so. So far there are not a lot of changes in NSS
    > between current and beta version.
    Ok. I have no problems with NSS being updated, I use the packages from the OBS and still I’m confident they are safe enough. I was just confused for not being updated before release and being updated after release… US export regulations explain it.

    I thought these export regulations were from the PGP/Zimmermann times. I don’t think today makes any sense… I’m sure North Korea already has any information they could obtain from consumer software.

  6. Firefox is probably the most used and most tested application in openSUSE 11. This seems worth making an exception (should be really easy to catch regressions). RC1 fixes many Beta5 bugs that make popular web apps like GMail *very* slow. Believe it or not, many users are going to judge openSUSE 11 based on their browsing experience.

    Please keep this in mind!

  7. There were no dependencies except xulrunner190 that had to be updated as part of moving from 3.0b5 -> 3.0rc1, so the crypto argument sounds moot to me—unless the crypto is in xul, which I do not think, it’s in mozilla-nss.

  8. That’s bad but just means that release numbers in Factory are counting faster than in the OBS repository 🙁 The mozilla-nss package in OBS is indeed quite newer than the one in Factory (it has been updated yesterday to the latest NSS tag to feature FF3.0rc2).
    Anyway in the meantime I figured that having the crypto source code in a package is enough for the limitations to be applied 🙁

  9. Speaking of numbers moving faster than others: for years now, release numbers in the normal tree (e.g. /10.2/suse/i586) have sometimes been higher than those in the update tree (update/10.2/rpm/i586) creating a lot of confusion which of the ones the real update actually is.

Comments are closed.