1324501 - Package and deploy SHA384 capable signmar

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Rail Aliiev [:rail]]

We need to package and deploy SHA384 capable signmar to be installed in parallel with https://hg.mozilla.org/build/puppet/file/tip/modules/packages/manifests/mozilla/signmar.pp for both linux and mac.

Comment 1

[Rail Aliiev [:rail]]

I tried to compile signmar with patches from bug 1105689. Everything works fine except that now it requires libmozsqlite3.so in LD_LIBRARY_PATH:

./obj-x86_64-pc-linux-gnu/dist/bin/signmar: error while loading shared libraries: libmozsqlite3.so: cannot open shared object file: No such file or directory


Robert, do you know if libmozsqlite3.so is really required? If yes, can it be statically linked to simplify the deployment?

Otherwise we'll need to add a wrapper to set LD_LIBRARY_PATH before calling signmar and this is ugly. :(

Comment 2

[Robert Strong (they/them - no direct email)]

Rail, could you verify that running the same commands / scripts while using SHA1 without the patches doesn't also require libmozsqlite3.so? I thought it already did and I'd be surprised if changing it to SHA384 would cause that.

Comment 3

[Rail Aliiev [:rail]]

Yup, the same issue without the patch applied.

Comment 4

[Robert Strong (they/them - no direct email)]

So, the libmozsqlite3.so requirement is pre-existing.

Comment 5

[Rail Aliiev [:rail]]

Looks like it comes from nss. I hacked it a bit and with https://gist.github.com/rail/065e96c5f5b5d55d6c948bf80fe02fe7 it doesn't require libmozsqlite3.so anymore and prints the help message. I haven't tried to sign/verify anything yet.

Comment 6

[Rail Aliiev [:rail]]

I tried to sign a random mar file with a temp key and it seems working.

Robert, can you verify that the key and the mar file meet the new requirements:

https://people-mozilla.org/~raliiev/sha384/

FTR, the temp key was generated like this:

mkdir -p secrets/mar
certutil -d secrets/mar -N
certutil -d secrets/mar -S -n rel1 -t ",,u" -g 4096 -s "CN=Release MAR signing key" -x
certutil -L -d secrets/mar -n rel1 -r > release_mar_signing.der

The mar was signed like this:

signmar -d secrets/mar -n rel1  -s /tmp/firefox-47.0-48.0.1.en-US.mac.partial.mar /tmp/out.mar

And verified (returned 0):

signmar -d secrets/mar -n rel1  -v /tmp/out.mar

Comment 7

[Rail Aliiev [:rail]]

Hmm, just thought about double checking and it looks like that hack is not enough:

ldd signmar 
        linux-vdso.so.1 (0x00007fff8d9c8000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe082048000)
        libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007fe081e08000)
        libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007fe081c03000)
        libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007fe0819ff000)
        libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007fe0816b5000)
        libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007fe081485000)
        libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x00007fe081258000)
        libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007fe081000000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe080dfc000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe080a7b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe080777000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe08055e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0801c0000)
        /lib64/ld-linux-x86-64.so.2 (0x0000558eddf21000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe07ffb8000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe07fd9e000)

I already have some libs installed globally, but it may not work on our signing server.

I also tried to force MOZ_FOLD_LIBS=1, but nss won't link properly...

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #7)
> Hmm, just thought about double checking and it looks like that hack is not
> enough:
> 
> ldd signmar 
>         linux-vdso.so.1 (0x00007fff8d9c8000)
>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007fe082048000)
>         libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so
> (0x00007fe081e08000)
>         libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so
> (0x00007fe081c03000)
>         libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so
> (0x00007fe0819ff000)
>         libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so
> (0x00007fe0816b5000)
>         libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so
> (0x00007fe081485000)
>         libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so
> (0x00007fe081258000)
>         libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so
> (0x00007fe081000000)
>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe080dfc000)
>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x00007fe080a7b000)
>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe080777000)
>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x00007fe08055e000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0801c0000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000558eddf21000)
>         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe07ffb8000)
>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe07fd9e000)
> 
> I already have some libs installed globally, but it may not work on our
> signing server.
> 
> I also tried to force MOZ_FOLD_LIBS=1, but nss won't link properly...
See bug 1326208 comment #1

Comment 9

[Robert Strong (they/them - no direct email)]

needinfo myself for comment #6

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #6)
> I tried to sign a random mar file with a temp key and it seems working.
> 
> Robert, can you verify that the key and the mar file meet the new
> requirements:
> 
> https://people-mozilla.org/~raliiev/sha384/
> 
> FTR, the temp key was generated like this:
> 
> mkdir -p secrets/mar
> certutil -d secrets/mar -N
> certutil -d secrets/mar -S -n rel1 -t ",,u" -g 4096 -s "CN=Release MAR
> signing key" -x
> certutil -L -d secrets/mar -n rel1 -r > release_mar_signing.der
> 
> The mar was signed like this:
> 
> signmar -d secrets/mar -n rel1  -s
> /tmp/firefox-47.0-48.0.1.en-US.mac.partial.mar /tmp/out.mar
> 
> And verified (returned 0):
> 
> signmar -d secrets/mar -n rel1  -v /tmp/out.mar
That cert is sha256. I am fairly certain that you want to create the cert as follows

certutil -d secrets/mar -S -n rel1 -w -3 -v 0 -t ",,u" -Z SHA384 -g 4096 -s "CN=Release MAR signing key" -x

-w -3 sets the valid from date offset by negative 3 months
-v 0 sets the date valid to 0 months

Comment 11

[Robert Strong (they/them - no direct email)]

As previously, we'll also want a secondary certificate for backup just in case.

Comment 12

[Rail Aliiev [:rail]]

Great! Thanks for the tip. I'm almost done with the packaging, the rest should be more or less straight forward.

Comment 13

[Rail Aliiev [:rail]]

Attachment: Bug 1324501 - Package and deploy SHA384 capable signmar

Review commit: https://reviewboard.mozilla.org/r/103570/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/103570/

Comment 14

[Rail Aliiev [:rail]]

The plan for deployment

1) resolve bug 1324507 and copy the keys to the corresponding directories

2) copy the generated (marsign-sha384) and required (patchelf) RPMs to our repo

3) resolve and deploy bug 1324502 (restart signing servers)

4) land the change and restart the signing servers

5) eat a cookie :)

After this is done, we can try to enable it on Oak

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8825393 [details]
Bug 1324501 - Package and deploy SHA384 capable signmar

https://reviewboard.mozilla.org/r/103570/#review104796

Comment 16

[Rail Aliiev [:rail]]

Comment on attachment 8825393 [details]
Bug 1324501 - Package and deploy SHA384 capable signmar

remote:   https://hg.mozilla.org/build/puppet/rev/3ea2d5c4872ffed3bd19d1074df007e346ecaa29
remote:   https://hg.mozilla.org/build/puppet/rev/1256f24ee2c4107beddb88fd79762be5dc9e353d
remote:   https://hg.mozilla.org/build/puppet/rev/5de232f573ca1ce971f25e78cc85f6402ebc7836


Still need to restart the servers

Comment 17

[Rail Aliiev [:rail]]

Attachment: repo.diff

Forgot to add the repo

Comment 18

[Rail Aliiev [:rail]]

Comment on attachment 8826281 [details] [diff] [review]
repo.diff

remote:   https://hg.mozilla.org/build/puppet/rev/e6c09a8730620ba56c5c847db4d3838930d5966b
remote:   https://hg.mozilla.org/build/puppet/rev/0ad9c50e193ccad5eedb926f52ffa03e5aa08611

Comment 19

[Rail Aliiev [:rail]]

Attachment: osx.diff

We don't sign MAR files on OS X anymore.

Comment 20

[Justin Wood (:Callek)]

Comment on attachment 8826302 [details] [diff] [review]
osx.diff

Review of attachment 8826302 [details] [diff] [review]:
-----------------------------------------------------------------

Might be safer to only move signmar_sha384 to inside the centos block, rather than removing the signmar install itself from everything... but either way r+

Comment 21

[Rail Aliiev [:rail]]

Comment on attachment 8826302 [details] [diff] [review]
osx.diff

(In reply to Justin Wood (:Callek) from comment #20)
> Comment on attachment 8826302 [details] [diff] [review]
> osx.diff
> 
> Review of attachment 8826302 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Might be safer to only move signmar_sha384 to inside the centos block,
> rather than removing the signmar install itself from everything... but
> either way r+

Yeah, that was my first patch. But then I thought that there is no reason to keep them so far apart. :)