Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-12-01 10:06:46, Antoine Beaupré wrote:
> On 2016-11-30 23:59:32, Guido Günther wrote:
>> I remember the nss testsuite to run cleanly last time I checked a couple
>> of months ago so we should IMHO investigate.
>
> It seems that there are a lot of failing tests regarding FIPS support:
>
> [1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$' 
> /var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log 
> cert.sh: #320: Enable FIPS mode on database for FIPS PUB 140 Test Certificate 
> (11)  - FAILED
> fips.sh: #830: Verify this module is in FIPS mode (modutil -chkfips true) . - 
> FAILED
> fips.sh: #849: Run PK11MODE in FIPS mode (pk11mode) . - FAILED
> fips.sh: #850: Run PK11MODE in Non FIPS mode (pk11mode -n) . - FAILED
> fips.sh: #851: Init NSS with a corrupted library (dbtest -r) . - FAILED
> ssl.sh: #2681:  (modutil -fips true) produced a returncode of 11, expected is 
> 0 - FAILED
> ssl.sh: #2683:  (grep "FIPS PKCS #11") produced a returncode of 1, expected 
> is 0 - FAILED
> ssl.sh: #2684:  (modutil -fips true) produced a returncode of 11, expected is 
> 0 - FAILED
> ssl.sh: #2686:  (grep "FIPS PKCS #11") produced a returncode of 1, expected 
> is 0 - FAILED
> ssl.sh: #3144:  (modutil -fips false) produced a returncode of 13, expected 
> is 0 - FAILED
> ssl.sh: #3147:  (modutil -fips false) produced a returncode of 13, expected 
> is 0 - FAILED
> ssl.sh: #3150:  (modutil -fips true) produced a returncode of 11, expected is 
> 0 - FAILED
> ssl.sh: #3152:  (grep "FIPS PKCS #11") produced a returncode of 1, expected 
> is 0 - FAILED
> ssl.sh: #3153:  (modutil -fips true) produced a returncode of 11, expected is 
> 0 - FAILED
> ssl.sh: #3155:  (grep "FIPS PKCS #11") produced a returncode of 1, expected 
> is 0 - FAILED
> [1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$' 
> /var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log | wc
>  15 2221279
>
> The test suite hasn't completed yet, so two more are missing... But
> basically, this looks like *all* FIPS-related issues, except for #851.
>
> Does that ring a bell to anyone?

Okay, researching this further shows that the test suite also failed
back in the 3.14.5-1+deb7u6 package i had lying around:

NSS variables:
--
HOST=angela
DOMSUF=(none)
BUILD_OPT=
USE_64=
NSS_CYCLES="standard"
NSS_TESTS=""
NSS_SSL_TESTS="crl bypass_normal normal_bypass fips_normal normal_fips iopr"
NSS_SSL_RUN="cov auth stress"
NSS_AIA_PATH=
NSS_AIA_HTTP=
NSS_AIA_OCSP=
IOPR_HOSTADDR_LIST=
PKITS_DATA=

Tests summary:
--
Passed: 1284
Failed: 11
Failed with core:   0
Unknown status: 0

I haven't looked in details at which test is failing exactly. I tried
disabling the *fips* tests in the 3.26.2 build, and this is the result:

SUMMARY:

NSS variables:
--
HOST=angela
DOMSUF=(none)
BUILD_OPT=
USE_X32=
USE_64=
NSS_CYCLES="standard"
NSS_TESTS=""
NSS_SSL_TESTS="crl bypass_normal normal_bypass iopr policy"
NSS_SSL_RUN="cov auth stapling stress"
NSS_AIA_PATH=
NSS_AIA_HTTP=
NSS_AIA_OCSP=
IOPR_HOSTADDR_LIST=
PKITS_DATA=

Tests summary:
--
Passed: 7459
Failed: 5
Failed with core:   0
ASan failures:  0
Unknown status: 0

What's interesting is that the test suite failures did not break the
build in previous releases.

Guido: did you remember which package had a passing test suite? :)

I wonder if this could not be some nspr interaction, since that was
updated as well...

A.

-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Re: nss security update package ready for review

[Ola Lundqvist]

Hi

This was the case when I run the tests last time. If I remenber correctly
FIPS had to be enabled with sysctl and even with that I couldn't make it
work.

After reading more about FIPS I concluded that this is likely something
that nobody uses, at least likely not on wheezy.

/ Ola

Sent from a phone

Den 1 dec 2016 16:06 skrev "Antoine Beaupré" :

> On 2016-11-30 23:59:32, Guido Günther wrote:
> > I remember the nss testsuite to run cleanly last time I checked a couple
> > of months ago so we should IMHO investigate.
>
> It seems that there are a lot of failing tests regarding FIPS support:
>
> [1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$'
> /var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log
> cert.sh: #320: Enable FIPS mode on database for FIPS PUB 140 Test
> Certificate (11)  - FAILED
> fips.sh: #830: Verify this module is in FIPS mode (modutil -chkfips true)
> . - FAILED
> fips.sh: #849: Run PK11MODE in FIPS mode (pk11mode) . - FAILED
> fips.sh: #850: Run PK11MODE in Non FIPS mode (pk11mode -n) . - FAILED
> fips.sh: #851: Init NSS with a corrupted library (dbtest -r) . - FAILED
> ssl.sh: #2681:  (modutil -fips true) produced a returncode of 11, expected
> is 0 - FAILED
> ssl.sh: #2683:  (grep "FIPS PKCS #11") produced a returncode of 1,
> expected is 0 - FAILED
> ssl.sh: #2684:  (modutil -fips true) produced a returncode of 11, expected
> is 0 - FAILED
> ssl.sh: #2686:  (grep "FIPS PKCS #11") produced a returncode of 1,
> expected is 0 - FAILED
> ssl.sh: #3144:  (modutil -fips false) produced a returncode of 13,
> expected is 0 - FAILED
> ssl.sh: #3147:  (modutil -fips false) produced a returncode of 13,
> expected is 0 - FAILED
> ssl.sh: #3150:  (modutil -fips true) produced a returncode of 11, expected
> is 0 - FAILED
> ssl.sh: #3152:  (grep "FIPS PKCS #11") produced a returncode of 1,
> expected is 0 - FAILED
> ssl.sh: #3153:  (modutil -fips true) produced a returncode of 11, expected
> is 0 - FAILED
> ssl.sh: #3155:  (grep "FIPS PKCS #11") produced a returncode of 1,
> expected is 0 - FAILED
> [1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$'
> /var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log | wc
>  15 2221279
>
> The test suite hasn't completed yet, so two more are missing... But
> basically, this looks like *all* FIPS-related issues, except for #851.
>
> Does that ring a bell to anyone?
>
> A.
>
> --
> Il faut tout un village pour élever un enfant.
> - Proverbe africain
>

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-11-30 23:59:32, Guido Günther wrote:
> I remember the nss testsuite to run cleanly last time I checked a couple
> of months ago so we should IMHO investigate.

It seems that there are a lot of failing tests regarding FIPS support:

[1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$' 
/var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log 
cert.sh: #320: Enable FIPS mode on database for FIPS PUB 140 Test Certificate 
(11)  - FAILED
fips.sh: #830: Verify this module is in FIPS mode (modutil -chkfips true) . - 
FAILED
fips.sh: #849: Run PK11MODE in FIPS mode (pk11mode) . - FAILED
fips.sh: #850: Run PK11MODE in Non FIPS mode (pk11mode -n) . - FAILED
fips.sh: #851: Init NSS with a corrupted library (dbtest -r) . - FAILED
ssl.sh: #2681:  (modutil -fips true) produced a returncode of 11, expected is 0 
- FAILED
ssl.sh: #2683:  (grep "FIPS PKCS #11") produced a returncode of 1, expected is 
0 - FAILED
ssl.sh: #2684:  (modutil -fips true) produced a returncode of 11, expected is 0 
- FAILED
ssl.sh: #2686:  (grep "FIPS PKCS #11") produced a returncode of 1, expected is 
0 - FAILED
ssl.sh: #3144:  (modutil -fips false) produced a returncode of 13, expected is 
0 - FAILED
ssl.sh: #3147:  (modutil -fips false) produced a returncode of 13, expected is 
0 - FAILED
ssl.sh: #3150:  (modutil -fips true) produced a returncode of 11, expected is 0 
- FAILED
ssl.sh: #3152:  (grep "FIPS PKCS #11") produced a returncode of 1, expected is 
0 - FAILED
ssl.sh: #3153:  (modutil -fips true) produced a returncode of 11, expected is 0 
- FAILED
ssl.sh: #3155:  (grep "FIPS PKCS #11") produced a returncode of 1, expected is 
0 - FAILED
[1034]anarcat@angela:nss-3.26.2$ grep 'FAILED$' 
/var/cache/pbuilder/build//cow.13026/tmp/buildd/nss-3.26.2/build.log | wc
 15 2221279

The test suite hasn't completed yet, so two more are missing... But
basically, this looks like *all* FIPS-related issues, except for #851.

Does that ring a bell to anyone?

A.

-- 
Il faut tout un village pour élever un enfant.
- Proverbe africain

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-12-01 09:54:44, Salvatore Bonaccorso wrote:
> Hi Antoine,
>
> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
>> +
>> +  * Non-maintainer upload by the LTS Security Team.
>> +  * New upstream release to fix CVE-2016-9074
>
> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.
>
> The former if you import new orig source on top of the previous
> packaging to indicate the new import and have a version which is
> before any possible such ones uploaded to unstable (which is even true
> in this case because 2:3.26.2-1 is currently in unstable). The later
> is often prefered if the package is mostly are build of :3.26.2-1 for
> Wheezy. (The later proposed version works obviously as well in the
> case of just a new upstream import, but Release team has often as well
> done that distinction for the ~debXuY suffix).

Good point, sorry I got that one totally wrong.

The package is from wheezy with the upstream tarball imported, as that
is how it was done previously.

A.

-- 
Twenty years from now you will be more disappointed by the things that
you didn't do than by the ones you did do. So throw off the bowlines.
Sail away from the safe harbor. Catch the trade winds in your sails.
Explore. Dream. Discover.  - Mark Twain

Re: nss security update package ready for review

[Salvatore Bonaccorso]

Hi Antoine,

On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
> +
> +  * Non-maintainer upload by the LTS Security Team.
> +  * New upstream release to fix CVE-2016-9074

Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.

The former if you import new orig source on top of the previous
packaging to indicate the new import and have a version which is
before any possible such ones uploaded to unstable (which is even true
in this case because 2:3.26.2-1 is currently in unstable). The later
is often prefered if the package is mostly are build of :3.26.2-1 for
Wheezy. (The later proposed version works obviously as well in the
case of just a new upstream import, but Release team has often as well
done that distinction for the ~debXuY suffix).

Regards,
Salvatore

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-11-30 23:59:32, Guido Günther wrote:
> Hi Antoine,
> On Wed, Nov 30, 2016 at 11:03:39PM -0500, Antoine Beaupré wrote:
>> On 2016-11-30 16:46:17, Ola Lundqvist wrote:
>> > Hi
>> >
>> > There were no test suite before the update so I could not tell if it was a
>> > regression or not.
>> 
>> I just figured out how to hook up the test suite, and it fails:
>
> (Posting this here again since I'm not sure everybody working on nss in
> LTS is aware of it):
>
> We have patches to enable it during the build here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639

Sigh... I missed that in my research. I ended up with a similar patch
here.

> There's also more stuff like some minimal autopkgtests here:
>
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ease-lts;users=debian-lts@lists.debian.org

interesting...

>> Tests summary:
>> --
>> Passed: 8282
>> Failed: 17
>> Failed with core:   0
>> ASan failures:  0
>> Unknown status: 0
>> 
>> It takes a looong time to run here. I thought it was in a loop for a
>> while there.
>> 
>> I am not sure what to do next here - maybe I could test against the pre
>> 3.26 version from wheezy and see if the tests fail similarly...
>
> Do we really intend to track nss upstream from now on:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?Bug=824872
>
> I remember the nss testsuite to run cleanly last time I checked a couple
> of months ago so we should IMHO investigate.

Okay. One problem with the test suite is that it generates so much
output that it's basically impossible to see what the failure *was* -
I'll need to log all this and run the test suite again...

a.

-- 
Twenty years from now you will be more disappointed by the things that
you didn't do than by the ones you did do. So throw off the bowlines.
Sail away from the safe harbor. Catch the trade winds in your sails.
Explore. Dream. Discover.  - Mark Twain

Re: nss security update package ready for review

[Ola Lundqvist]

Hi

In LTS the hook is available in debian/rules but commented. The number
of failed test cases seems to be the same as I remember from when I
had to disable it.

// Ola

On 1 December 2016 at 05:59, Guido Günther  wrote:
> Hi Antoine,
> On Wed, Nov 30, 2016 at 11:03:39PM -0500, Antoine Beaupré wrote:
>> On 2016-11-30 16:46:17, Ola Lundqvist wrote:
>> > Hi
>> >
>> > There were no test suite before the update so I could not tell if it was a
>> > regression or not.
>>
>> I just figured out how to hook up the test suite, and it fails:
>
> (Posting this here again since I'm not sure everybody working on nss in
> LTS is aware of it):
>
> We have patches to enable it during the build here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639
>
> There's also more stuff like some minimal autopkgtests here:
>
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ease-lts;users=debian-lts@lists.debian.org
>
>> Tests summary:
>> --
>> Passed: 8282
>> Failed: 17
>> Failed with core:   0
>> ASan failures:  0
>> Unknown status: 0
>>
>> It takes a looong time to run here. I thought it was in a loop for a
>> while there.
>>
>> I am not sure what to do next here - maybe I could test against the pre
>> 3.26 version from wheezy and see if the tests fail similarly...
>
> Do we really intend to track nss upstream from now on:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?Bug=824872
>
> I remember the nss testsuite to run cleanly last time I checked a couple
> of months ago so we should IMHO investigate.
>
> Cheers,
>  -- Guidox



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: nss security update package ready for review

[Guido Günther]

Hi Antoine,
On Wed, Nov 30, 2016 at 11:03:39PM -0500, Antoine Beaupré wrote:
> On 2016-11-30 16:46:17, Ola Lundqvist wrote:
> > Hi
> >
> > There were no test suite before the update so I could not tell if it was a
> > regression or not.
> 
> I just figured out how to hook up the test suite, and it fails:

(Posting this here again since I'm not sure everybody working on nss in
LTS is aware of it):

We have patches to enable it during the build here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639

There's also more stuff like some minimal autopkgtests here:


https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ease-lts;users=debian-lts@lists.debian.org

> Tests summary:
> --
> Passed: 8282
> Failed: 17
> Failed with core:   0
> ASan failures:  0
> Unknown status: 0
> 
> It takes a looong time to run here. I thought it was in a loop for a
> while there.
> 
> I am not sure what to do next here - maybe I could test against the pre
> 3.26 version from wheezy and see if the tests fail similarly...

Do we really intend to track nss upstream from now on:

https://bugs.debian.org/cgi-bin/bugreport.cgi?Bug=824872

I remember the nss testsuite to run cleanly last time I checked a couple
of months ago so we should IMHO investigate.

Cheers,
 -- Guidox

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-11-30 16:46:17, Ola Lundqvist wrote:
> Hi
>
> There were no test suite before the update so I could not tell if it was a
> regression or not.

I just figured out how to hook up the test suite, and it fails:

Tests summary:
--
Passed: 8282
Failed: 17
Failed with core:   0
ASan failures:  0
Unknown status: 0

It takes a looong time to run here. I thought it was in a loop for a
while there.

I am not sure what to do next here - maybe I could test against the pre
3.26 version from wheezy and see if the tests fail similarly...

Any other ideas?

A.

-- 
The problem is not a lack of highly educated workers, the problem is a
lack of highly educated workers willing to work for the minimum wage or
lower in the U.S. Costs are driving outsourcing, not the quality of
American schools.   - Scott Kirwin, IT Professionals Association

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-11-30 16:46:17, Ola Lundqvist wrote:
> Hi
>
> There were no test suite before the update so I could not tell if it was a
> regression or not.

Ah, I see! Thanks for the updates, I'll see if i can fix the test
suite for a while otherwise I'll just stick with this...

A.

-- 
Drowning people
Sometimes die
Fighting their rescuers.
- Octavia Butler

Re: nss security update package ready for review

[Antoine Beaupré]

On 2016-11-30 16:17:50, Ola Lundqvist wrote:
> Hi Antoine
>
> I do not find it strange (as I was one of the two that did it). You
> are supposed to keep the changelog as far as I know. I mirrored the
> changes in stable/jessie. I never checked the unstable version (I do
> not think I did at least).

I did not find the wheezy update specifically strange, i found the
*stable* update strange: what you did was normal, you reused the update
from stable.

I find it strange that the stable backport was not simply importing the
package from testing, and is instead an hybrid between testing and
wheezy-security..

> However the resulting package was the same (as jessie at least) as I
> copied most of the changes from there. The only thing that was kept
> was the changelog and some minor things.
>
> The reason why the test suite is not run during build is that some
> tests failed. They were not essential for nss to work, but they failed
> the build.

Did the test suite pass before the update? That seems like a rather
serious problem: it makes maintenance of the package much harder in the
long term because now we do not know if we have a regression.

> I agree with you that it is better to update to the later version if
> this is just an upstream bugfix release.

Thanks!

By the way, in my previous message I refer to nss 2.26*, I obviously
meant nss 3.26*.

A.

-- 
Never be deceived that the rich will allow you to vote away their wealth.
- Lucy Parsons

Re: nss security update package ready for review

[Ola Lundqvist]

Hi Antoine

I do not find it strange (as I was one of the two that did it). You
are supposed to keep the changelog as far as I know. I mirrored the
changes in stable/jessie. I never checked the unstable version (I do
not think I did at least).

However the resulting package was the same (as jessie at least) as I
copied most of the changes from there. The only thing that was kept
was the changelog and some minor things.

The reason why the test suite is not run during build is that some
tests failed. They were not essential for nss to work, but they failed
the build.

I agree with you that it is better to update to the later version if
this is just an upstream bugfix release.

Best regards

// Ola

On 30 November 2016 at 22:05, Antoine Beaupré  wrote:
> I have looked at updating the nss package in wheezy to cover for a new
> security issue that came up. The package is ready for testing in:
>
> https://people.debian.org/~anarcat/debian/wheezy-lts/
>
> The diff between the upstream 2.26.2 release and the 2.26 release in
> wheezy is fairly small, so I felt it was better to upload the new
> version than to backport the patch. The same probably applies to wheezy.
>
> (The backport of 2.26-1 to jessie and wheezy was a bit strange, if you
> ask me: instead of just taking the package from stretch and adding a new
> changelog entry, the package from wheezy was updated with the upstream
> source. That seems backwards to me, because it makes it harder to import
> new packages from stretch in the future: we're forced to extract the
> upstream tarball and the .debian.tar.gz file on top of it...)
>
> Here's the debdiff:
>
>  debian/changelog  |   12
>  debian/changelog.n|  839 
> --
>  nss/.hg_archival.txt  |4
>  nss/external_tests/ssl_gtest/ssl_auth_unittest.cc |   69 +
>  nss/external_tests/ssl_gtest/tls_parser.h |1
>  nss/lib/nss/nss.h |4
>  nss/lib/softoken/softkver.h   |4
>  nss/lib/ssl/ssl3con.c |   94 +-
>  nss/lib/util/nssutil.h|4
>
> Note that I remove an odd changelog.n file that crept up in the previous
> upload, no idea what that thing was.
>
>
>
> I have yet to run the test suite, I am not sure why it's not being ran
> during build. I do not expect any significant regressions considering
> the change is so small, however.
>
> A.
>
> --
> One has a moral responsibility to disobey unjust laws.
> - Martin Luther King, Jr.
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---