Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On Tue, Sep 01, 2020 at 07:17:29PM +0200, Moritz Muehlenhoff wrote: > On Tue, Sep 01, 2020 at 04:35:42PM +0200, Emilio Pozuelo Monfort wrote: > > On 01/09/2020 14:05, Christoph Martin wrote: > > > Hi, > > > > > > I am not shure if I can help, but I can try and have a look at it. > > > > > > Yes please upload your LLVM9 and wasi-libc backports. > > > > fwiw I started to look at this and have an LLVM 10 backport ready. Should > > we go > > with that instead? > > I'm fine either way. > > > It may be more future-proof, in case we need it for a future > > rustc for the next ESR bump. > > My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to > be proven wrong :-) So maybe let's directly move to 10 directly. > > Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against > LLVM, then. Note Firefox doesn't need wasi-libc at the moment. Neither does thunderbird AFAICT. Mike
Re: Wheezy update of nss?
On Tue, Nov 22, 2016 at 07:10:02AM +0100, Salvatore Bonaccorso wrote: > On Mon, Nov 21, 2016 at 11:26:29PM +0100, Ola Lundqvist wrote: > > On 21 November 2016 at 23:23, Mike Hommey <m...@glandium.org> wrote: > > > > > You probably want the security team here, they take care of NSS in > > > jessie. > > > > > > On Mon, Nov 21, 2016 at 10:31:35PM +0100, Ola Lundqvist wrote: > > > > Hello dear maintainer(s), > > > > > > > > The Debian LTS team would like to fix the security issues which are > > > > currently open in the Wheezy version of nss: > > > > https://security-tracker.debian.org/tracker/CVE-2016-8635 > > I think this one is fixed with th import of 2:3.25-1 in unstable, and > thus contained in all suites already. The issue was fixed in 3.21.3, > but for Debian the changes for "validating dh_Ys against the group > prime" via ssl_IsValidDHEShare went into 2:3.25-1. > > Mike ist that correct? I can only presume, I don't have access to the corresponding upstream bug. Mike
Re: Wheezy update of nss?
You probably want the security team here, they take care of NSS in jessie. On Mon, Nov 21, 2016 at 10:31:35PM +0100, Ola Lundqvist wrote: > Hello dear maintainer(s), > > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of nss: > https://security-tracker.debian.org/tracker/CVE-2016-8635 > > Would you like to take care of this yourself? > > If yes, please follow the workflow we have defined here: > https://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-lts@lists.debian.org > (via a debdiff, or with an URL pointing to the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > You can also opt-out from receiving future similar emails in your > answer and then the LTS Team will take care of nss updates > for the LTS releases. (In case we don't get any answer for months, > we may also take it as an opt-out, too.) > > Thank you very much. > > Ola Lundqvist, > on behalf of the Debian LTS team. > > PS: A member of the LTS team might start working on this update at > any point in time. You can verify whether someone is registered > on this update in this file: > https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup > > ___ > pkg-mozilla-maintainers mailing list > pkg-mozilla-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozilla-maintainers
Re: Regression problem, call for advice Re: Call for advice and testing of nss (and nspr) and intention to upload correction
On Fri, Nov 04, 2016 at 01:17:36PM +0100, Ola Lundqvist wrote: > Hi all > > I have now analyzed the problem and the problem is that libfreebl3.so have > been split into a libfreebl3.so that is pre-loaded and a libfreeblpriv3.so > that is dynamically loaded by libfreebl3.so. This works well in many > situations but apparently not in google chrome. I guess this is because of > some kind of forking mechanism. Are you sure it's not caused by chromium's sandboxing? Surely more recent versions of chromium can handle the split, and maybe they had to do something for that to work. It would be worth looking at the chromium source history to find out what they did. Mike
Re: Regression problem, call for advice Re: Call for advice and testing of nss (and nspr) and intention to upload correction
On Tue, Nov 01, 2016 at 11:37:29PM +0100, Ola Lundqvist wrote: > Hi Ben, Balint and others > > I'd like to have some advice on this regression. > > 1) Is this worth investigating? > - Chrome is not supported, however we have now made it to crash. Ben > obviously like that but maybe others do not have the same opinion. > 2) Is this severe enough for me to revert the nss 3.26 upload? > If yes, how do I do that in the best way? I can not easily replace the > .orig file, but I can make a version without an orig file maybe. And > replace the source with the old one. Not sure how I should name the > versions in that case. > 3) If we think it is worth investigating do anyone have a good idea on how > to do that. This is a multi-threaded program and gdb did not really help. > When I run strace chrome fails as I'm running it with strace... So I end up > in another problem. The only remaining thing seem to be to add quite a few > printf statements. I'll do that tomorrow unless someone have told me to do > otherwise. http://www.rr-project.org Mike
Re: Wheezy update of firefox-esr?
On Sun, Sep 25, 2016 at 01:08:55AM +0200, Bálint Réczey wrote: > Hi, > > 2016-09-24 15:34 GMT+02:00 Balint Reczey <bal...@balintreczey.hu>: > > Hi, > > > > On 09/24/2016 12:51 AM, Mike Hommey wrote: > >> On Fri, Sep 23, 2016 at 07:57:45PM +0200, Bálint Réczey wrote: > >>> Hi, > >>> > >>> 2016-09-20 23:43 GMT+02:00 Chris Lamb <la...@debian.org>: > >>>> Hello dear maintainer(s), > >>>> > >>>> the Debian LTS team would like to fix the security issues which are > >>>> currently open in the Wheezy version of firefox-esr: > >>>> https://security-tracker.debian.org/tracker/source-package/firefox-esr > >>>> > >>>> Would you like to take care of this yourself? > >>>> > >>>> If yes, please follow the workflow we have defined here: > >>>> https://wiki.debian.org/LTS/Development > >>>> > >>>> If that workflow is a burden to you, feel free to just prepare an > >>>> updated source package and send it to debian-lts@lists.debian.org > >>>> (via a debdiff, or with an URL pointing to the source package, > >>>> or even with a pointer to your packaging repository), and the members > >>>> of the LTS team will take care of the rest. Indicate clearly whether you > >>>> have tested the updated package or not. > >>>> > >>>> If you don't want to take care of this update, it's not a problem, we > >>>> will do our best with your package. Just let us know whether you would > >>>> like to review and/or test the updated package before it gets released. > >>>> > >>>> You can also opt-out from receiving future similar emails in your > >>>> answer and then the LTS Team will take care of firefox-esr updates > >>>> for the LTS releases. (In case we don't get any answer for months, > >>>> we may also take it as an opt-out, too.) > >>> > >>> I think Mike would like the LTS Team to prepare the future updates: > >>> > >>> On Thu, Aug 04, 2016 at 06:32:14PM +0900, Mike Hommey wrote: > >>>> On Thu, Aug 04, 2016 at 11:04:47AM +0200, Markus Koschany wrote: > >>>>> Hello Mike, > >>>>> > >>>>> Thank you for preparing the security update of firefox-esr. I have just > >>>>> sent a security announcement for your update in Wheezy to the > >>>>> debian-lts-announce mailing list. If you want to take care of this next > >>>>> time, please follow our guidelines which we have outlined at [1]. If > >>>>> this is a burden for you, no problem, we will do our best and take care > >>>>> of the rest. In this case we would like to ask you to send a short > >>>>> reminder to debian-lts, so that we can prepare the announcement in a > >>>>> timely manner. > >>>> > >>>> Heh, I hadn't realized that wasn't handled by standard DSAs, sorry about > >>>> that. That these updates go through the same security-master doesn't > >>>> help making it obvious they are different. > >>>> > >>>> Anyways, I'd rather not have more work to do, so if can send > >>>> announcements, that works for me. Or you can deal with the backport > >>>> from back to back. > >>> ... > >>> > >>> I have added firefox-esr to lts-do-not-call and started preparing the > >>> update. > >> > >> Thanks. > > > > I have prepared the update. > > > > Please see the diff to jessie-security's version attached. > > > > Changes: > > > > firefox-esr (45.4.0esr-1~deb7u1) wheezy-security; urgency=medium > > . > >[ Mike Hommey ] > >* New upstream release. > >* Fixes for mfsa2016-86, also known as: > > CVE-2016-5270, CVE-2016-5272, CVE-2016-5276, CVE-2016-5274, > > CVE-2016-5277, CVE-2016-5278, CVE-2016-5280, CVE-2016-5281, > > CVE-2016-5284, CVE-2016-5250, CVE-2016-5261, CVE-2016-5257. > > . > >* debian/control*, debian/rules: Compile with GCC 5 on testing/unstable > > on arm* because of crashes when building with GCC 6. (FTBFS) > >* debian/rules: Build with -fno-schedule-insns2 and > > -fno-delete-null-pointer-checks with GCC >= 6 because it miscompiles > > Firefox. Closes: #836533. > > . > >* config/gcc-stl-wrapper.template.h, memory/mozalloc/throw_gcc.h: > > Don't include mozalloc.h from the cstdlib wrapper. bz#1245076, > > bz#1259537. > > Closes: #822715. > >* build/gyp.mozbuild: Disable libyuv assembly on mips64. (FTBFS) > > > > > > The binary packages for amd64 are also available for testing here: > > > > deb https://people.debian.org/~rbalint/ppa/wheezy-lts UNRELEASED/ > > > > I ran browser benchmarks to stress test the package and also visited a > > few sites manually. > > > > I plan uploading the package around 21:00 UTC. > > ARM builds are failing for the package due to looking for gcc-5 . :-( > > I'm fixing that shortly. That was fixed in 45.4.0esr-1~deb8u2. Mike
Re: CVE-2016-2839 / Firefox-ESR
On Wed, Aug 17, 2016 at 09:00:30AM +0100, Chris Lamb wrote: > Hi Brian, > > > 45.3.0esr-1~deb7u1 in wheezy is vulnerable. > > 45.3.0esr-1~deb8u1 in jessie is vulnerable. > > 45.3.0esr-1 in sid and stretch is not vulnerable. > > > > Which makes me wonder if Wheezy and Jessie versions have been fixed, but > > not marked as such > > Good spot. > > CVE-2016-2839 is marked as fixed in the changelog of 45.3.0esr-1~deb7u1. > Mike, as author of that changelog entry, can you comment here? All 45.3.0esr-1* versions are fixed, but this only actually affects when playing videos with ffmpeg 0.10 installed. *not* ffmpeg 1.0, *not* libav. So for most practical purposes, wheezy and jessie are not /really/ affected as long as only packages from wheezy and jessie are used. Mike
Re: Security update of firefox-esr for Wheezy
On Thu, Aug 04, 2016 at 11:04:47AM +0200, Markus Koschany wrote: > Hello Mike, > > Thank you for preparing the security update of firefox-esr. I have just > sent a security announcement for your update in Wheezy to the > debian-lts-announce mailing list. If you want to take care of this next > time, please follow our guidelines which we have outlined at [1]. If > this is a burden for you, no problem, we will do our best and take care > of the rest. In this case we would like to ask you to send a short > reminder to debian-lts, so that we can prepare the announcement in a > timely manner. Heh, I hadn't realized that wasn't handled by standard DSAs, sorry about that. That these updates go through the same security-master doesn't help making it obvious they are different. Anyways, I'd rather not have more work to do, so if can send announcements, that works for me. Or you can deal with the backport from back to back. Please note that the next ESR bump (52) will require GCC 4.8, which is not in wheezy, so I won't be building ESR45 for wheezy past 45.8, presumably some time in April next year. Cheers, Mike
Accepted firefox-esr 45.3.0esr-1~deb7u1 (source all amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 03 Aug 2016 06:33:48 +0900 Source: firefox-esr Binary: firefox-esr iceweasel firefox-esr-dbg iceweasel-dbg firefox-esr-dev iceweasel-dev firefox-esr-l10n-all iceweasel-l10n-all firefox-esr-l10n-ach iceweasel-l10n-ach firefox-esr-l10n-af iceweasel-l10n-af firefox-esr-l10n-an iceweasel-l10n-an firefox-esr-l10n-ar iceweasel-l10n-ar firefox-esr-l10n-as iceweasel-l10n-as firefox-esr-l10n-ast iceweasel-l10n-ast firefox-esr-l10n-az iceweasel-l10n-az firefox-esr-l10n-be iceweasel-l10n-be firefox-esr-l10n-bg iceweasel-l10n-bg firefox-esr-l10n-bn-bd iceweasel-l10n-bn-bd firefox-esr-l10n-bn-in iceweasel-l10n-bn-in firefox-esr-l10n-br iceweasel-l10n-br firefox-esr-l10n-bs iceweasel-l10n-bs firefox-esr-l10n-ca iceweasel-l10n-ca firefox-esr-l10n-cs iceweasel-l10n-cs firefox-esr-l10n-cy iceweasel-l10n-cy firefox-esr-l10n-da iceweasel-l10n-da firefox-esr-l10n-de iceweasel-l10n-de firefox-esr-l10n-dsb iceweasel-l10n-dsb firefox-esr-l10n-el iceweasel-l10n-el firefox-esr-l10n-en-gb iceweasel-l10n-en-gb firefox-esr-l10n-en-za iceweasel-l10n-en-za firefox-esr-l10n-eo iceweasel-l10n-eo firefox-esr-l10n-es-ar iceweasel-l10n-es-ar firefox-esr-l10n-es-cl iceweasel-l10n-es-cl firefox-esr-l10n-es-es iceweasel-l10n-es-es firefox-esr-l10n-es-mx iceweasel-l10n-es-mx firefox-esr-l10n-et iceweasel-l10n-et firefox-esr-l10n-eu iceweasel-l10n-eu firefox-esr-l10n-fa iceweasel-l10n-fa firefox-esr-l10n-ff iceweasel-l10n-ff firefox-esr-l10n-fi iceweasel-l10n-fi firefox-esr-l10n-fr iceweasel-l10n-fr firefox-esr-l10n-fy-nl iceweasel-l10n-fy-nl firefox-esr-l10n-ga-ie iceweasel-l10n-ga-ie firefox-esr-l10n-gd iceweasel-l10n-gd firefox-esr-l10n-gl iceweasel-l10n-gl firefox-esr-l10n-gn iceweasel-l10n-gn firefox-esr-l10n-gu-in iceweasel-l10n-gu-in firefox-esr-l10n-he iceweasel-l10n-he firefox-esr-l10n-hi-in iceweasel-l10n-hi-in firefox-esr-l10n-hr iceweasel-l10n-hr firefox-esr-l10n-hsb iceweasel-l10n-hsb firefox-esr-l10n-hu iceweasel-l10n-hu firefox-esr-l10n-hy-am iceweasel-l10n-hy-am firefox-esr-l10n-id iceweasel-l10n-id firefox-esr-l10n-is iceweasel-l10n-is firefox-esr-l10n-it iceweasel-l10n-it firefox-esr-l10n-ja iceweasel-l10n-ja firefox-esr-l10n-kk iceweasel-l10n-kk firefox-esr-l10n-km iceweasel-l10n-km firefox-esr-l10n-kn iceweasel-l10n-kn firefox-esr-l10n-ko iceweasel-l10n-ko firefox-esr-l10n-lij iceweasel-l10n-lij firefox-esr-l10n-lt iceweasel-l10n-lt firefox-esr-l10n-lv iceweasel-l10n-lv firefox-esr-l10n-mai iceweasel-l10n-mai firefox-esr-l10n-mk iceweasel-l10n-mk firefox-esr-l10n-ml iceweasel-l10n-ml firefox-esr-l10n-mr iceweasel-l10n-mr firefox-esr-l10n-ms iceweasel-l10n-ms firefox-esr-l10n-nb-no iceweasel-l10n-nb-no firefox-esr-l10n-nl iceweasel-l10n-nl firefox-esr-l10n-nn-no iceweasel-l10n-nn-no firefox-esr-l10n-or iceweasel-l10n-or firefox-esr-l10n-pa-in iceweasel-l10n-pa-in firefox-esr-l10n-pl iceweasel-l10n-pl firefox-esr-l10n-pt-br iceweasel-l10n-pt-br firefox-esr-l10n-pt-pt iceweasel-l10n-pt-pt firefox-esr-l10n-rm iceweasel-l10n-rm firefox-esr-l10n-ro iceweasel-l10n-ro firefox-esr-l10n-ru iceweasel-l10n-ru firefox-esr-l10n-si iceweasel-l10n-si firefox-esr-l10n-sk iceweasel-l10n-sk firefox-esr-l10n-sl iceweasel-l10n-sl firefox-esr-l10n-son iceweasel-l10n-son firefox-esr-l10n-sq iceweasel-l10n-sq firefox-esr-l10n-sr iceweasel-l10n-sr firefox-esr-l10n-sv-se iceweasel-l10n-sv-se firefox-esr-l10n-ta iceweasel-l10n-ta firefox-esr-l10n-te iceweasel-l10n-te firefox-esr-l10n-th iceweasel-l10n-th firefox-esr-l10n-tr iceweasel-l10n-tr firefox-esr-l10n-uk iceweasel-l10n-uk firefox-esr-l10n-uz iceweasel-l10n-uz firefox-esr-l10n-vi iceweasel-l10n-vi firefox-esr-l10n-xh iceweasel-l10n-xh firefox-esr-l10n-zh-cn iceweasel-l10n-zh-cn firefox-esr-l10n-zh-tw iceweasel-l10n-zh-tw Architecture: source all amd64 Version: 45.3.0esr-1~deb7u1 Distribution: oldstable-security Urgency: medium Maintainer: Maintainers of Mozilla-related packages <pkg-mozilla-maintain...@lists.alioth.debian.org> Changed-By: Mike Hommey <gland...@debian.org> Description: firefox-esr - Mozilla Firefox web browser - Extended Support Release (ESR) firefox-esr-dbg - Debugging symbols for Firefox ESR firefox-esr-dev - Development files for the Gecko engine library firefox-esr-l10n-ach - Acoli language package for Firefox ESR firefox-esr-l10n-af - Afrikaans language package for Firefox ESR firefox-esr-l10n-all - All language packages for Firefox ESR (meta) firefox-esr-l10n-an - Aragonese language package for Firefox ESR firefox-esr-l10n-ar - Arabic language package for Firefox ESR firefox-esr-l10n-as - Assamese language package for Firefox ESR firefox-esr-l10n-ast - Asturian language package for Firefox ESR firefox-esr-l10n-az - Azerbaijani language package for Firefox ESR firefox-esr-l10n-be - Belarusian language package for Firefox ESR firefox-esr-l10n-bg - Bulgarian language package for Firefox ESR firefox-esr-l10n-bn-bd - Bengali
Re: Iceweasel 45 for Wheezy-LTS
On Fri, May 27, 2016 at 08:59:53AM +0200, Guido Günther wrote: > Hi Mike, > On Thu, May 26, 2016 at 10:29:22PM +0900, Mike Hommey wrote: > > On Sun, May 22, 2016 at 07:34:29PM +0200, Guido Günther wrote: > > > Hi Mike, > > > I'm currently looking into building icedove 45 for Wheezy-LTS. I wonder > > > if I should do the same for Iceweasel or if you intend to keep > > > maintaining Iceweasel in LTS yourself? > > > > I don't know yet. The last message in bug 815006 makes me think it might > > be better to avoid the rename to Firefox in stable, so depending on the > > outcome of that, continuing to support oldstable may or may not be low > > overhead. > > Given that the security team is fine with it I think moving to firefox > makes sense. Please let me know how you intend to handle it so I can > take care of it in case you don't want to support LTS. > > BTW any particular reason or starting with 45.2 and not 45.0 as stated in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006#85 > > or is this just a resource problem. Because that leaves/left 12 weeks for things to settle down. Releasing 45.0esr to stable would have been a disaster without that kind of buffer. Mike
Re: Iceweasel 45 for Wheezy-LTS
On Sun, May 22, 2016 at 07:34:29PM +0200, Guido Günther wrote: > Hi Mike, > I'm currently looking into building icedove 45 for Wheezy-LTS. I wonder > if I should do the same for Iceweasel or if you intend to keep > maintaining Iceweasel in LTS yourself? I don't know yet. The last message in bug 815006 makes me think it might be better to avoid the rename to Firefox in stable, so depending on the outcome of that, continuing to support oldstable may or may not be low overhead. Mike
Re: Unsupported packages for Wheezy LTS
On Thu, Nov 05, 2015 at 08:43:38AM +0100, Moritz Muehlenhoff wrote: > On Thu, Nov 05, 2015 at 06:47:03AM +0900, Mike Hommey wrote: > > First and foremost, while GCC 4.7 is the current > > minimum version supported, it's likely to become GCC 4.8 in the near > > future, because of some wanted C++11/C++14 features. > > That problem also bit us with chromium in wheezy. Introducing an updated > g++ isn't simple since libstdc++ is also built from the source package. Note that Firefox /can/ build with GCC > 4.7 but still depend on libstdc++ from GCC 4.3, thanks to nasty tricks. https://dxr.mozilla.org/mozilla-central/source/build/unix/stdc++compat/stdc++compat.cpp Mike
Re: Using the same nss in all suites
On Thu, Nov 05, 2015 at 09:00:51PM +0100, Florian Weimer wrote: > * Mike Hommey: > > > On ABI stability, both NSPR and NSS have a very strict policy. NSPR > > receives very few ABI changes, and it's only adding new functions. NSS > > has much more ABI changes, but also only adding new functions. > > This is incorrect, there have been unplanned ABI changes related to > SSL_ImplementedCiphers variable: > > <http://openwall.com/lists/oss-security/2015/09/07/6> Urgh. That would have been unintentional. > I will fix the glibc warning to be much more explicit about this. > > > The biggest issue with NSS version bumps is that defaults change, > > such as cyphers, protocols, etc. That can have unexpected > > consequences on existing setups. > > The typical complaint with NSS is the opposite, tha the defaults do > not change fast enough. Iceweasel/Mozilla PSM overrides basically all > the settings, so what you see there does not reflect upstream NSS > defaults. One of the things I had in mind is bug 561918. Things like this happen from time to time, and merely upgrading NSS shouldn't have such unintended consequences, but it does. (BTW, 5 years later, I can probably flip the pref back to the NSS default) Mike
Re: Unsupported packages for Wheezy LTS
On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote: > [ Many people are on copy, please trim the list as appropriate when you reply > ] > > On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote: > > These need to be discussed, since they will be a significant > > time drain (e.g. are they in the sponsors's interests?). They > > are supportable, but it will take a lot of work and sometimes > > special domain knowledge: > > > > icedove > > iceweasel > > qemu > > qemu-kvm > > xen > > libvirt > > ffmpeg -> libav > > vlc > > rails -> several split packages (only the 3.2 packages are supported in > > wheezy) > > Nobody commented here but I believe that we should aim to support them. > Except vlc, they are all used by some of the current sponsors (even though > they are not currently supported in squeeze). > > It would be good to identify Debian maintainers with the required "special > domain knowledge" for all those packages so that they can be paid to > take care of those packages when the need arises (cf > https://www.freexian.com/services/debian-lts-details.html#join for > details about requirement for paid contributors). Speaking for iceweasel, backports to wheezy are not a significant overhead compared to packaging for unstable and stable-security. With that being said, the fact that we're backporting new upstream ESR releases is going to have its own problems sooner or later, related to the toolchains. First and foremost, while GCC 4.7 is the current minimum version supported, it's likely to become GCC 4.8 in the near future, because of some wanted C++11/C++14 features. Second, Firefox is soon going to require the rust compiler, which we have no package for except in unstable. So there should be a discussion about what we do about those toolchains first (and that's a broader discussion to have than LTS). Mike
Re: Using the same nss in all suites
On Thu, Nov 05, 2015 at 08:25:47AM +0100, Guido Günther wrote: > Hi, > > Backporting fixes for nss can become a challenge over time due to: > > * Bugs related to MFAs (often containing test cases) being restricted so > one can only look at hg and try to find all the relevant commits. > > * The library has rather frequent security updates > > * The code diverges over the years > > > I haven't found an explicit statement about ABI stability on the nss > site but RedHat and others seem to be doing fine with always using the > latest version in all suites and I wonder if we should do the same. This > would probably include updating the nspr dependency from time to time > too. > > I wonder what's the maintainers and security teams stance on this? > Should we do this? Should we start with this during Jessie? If so I > would be happy to prepare packages for the different distributions and > do some testing. On ABI stability, both NSPR and NSS have a very strict policy. NSPR receives very few ABI changes, and it's only adding new functions. NSS has much more ABI changes, but also only adding new functions. The biggest issue with NSS version bumps is that defaults change, such as cyphers, protocols, etc. That can have unexpected consequences on existing setups. Mike
Re: squeeze update of nss?
On Sun, Nov 01, 2015 at 02:48:38PM +0100, Guido Günther wrote: > Hello dear maintainer, > > the Debian LTS team would like to fix the security issues which are > currently open in the Squeeze version of nss: > https://security-tracker.debian.org/tracker/CVE-2015-4000 > > Would you like to take care of this yourself? The security team has been dealing with NSS updates to stable, and I'd rather they or you take care of oldstable LTS. That being said, the tracker says the issue is not fixed in stable, and I'd think it's bad practice to fix it in LTS before it's fixed in stable. Mike (While on the subject, there's another round of Iceweasel security updates coming, along with NSPR and NSS fixes, this time) > > If yes, please follow the workflow we have defined here: > http://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-lts@lists.debian.org > (via a debdiff, or with an URL pointing to the the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > Thank you very much. > > Guido Günther, > on behalf of the Debian LTS team. > > PS: A member of the LTS team might start working on this update at > any point in time. You can verify whether someone is registered > on this update in this file: > https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup > > ___ > pkg-mozilla-maintainers mailing list > pkg-mozilla-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozilla-maintainers
