1427849 - Digitally sign geckodriver binaries on Linux and Windows

Status: VERIFIED FIXED

(Testing :: geckodriver, enhancement, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Originally filed as: https://github.com/mozilla/geckodriver/issues/1116

Currently the official geckodriver binary for releases as distributed via https://github.com/mozilla/geckodriver/releases is not signed.

Given that we build geckodriver in-tree now it should be possible to hook the signing part (similar to Firefox) up for the geckodriver binary.

Chris, whom from Releng we could talk to in figuring out what would be necessary to get this implemented? Thanks.

Comment 1

[Johan Lorenzo [:jlorenzo]]

Chatted with :whimboo on IRC to understand what's needed.


GOAL
* The main goal is to sign `bin/geckodriver` present in target.common.tests.zip[1].
* They would like to release a binary taken from mozilla-central at a given revision


TECHNICAL CONTEXT
* target.common.tests.zip is built on every push and on every nightly build.
* There is no external dependency (to sign) because geckodriver is statically linked binary.
* Windows and Mac verify the signature of binary executing it, but Linux doesn't. On Linux distros, signature verification is usually done against the package. Then, it's up to the package maintainer to verify the signature of the upstream binary. 


SUGGESTED SOLUTION
We sign gecko driver at each build of Firefox Nightly. The keys used will be the ones that signs Firefox Nightly. The downside of this approach is: You only have 2 changesets per day that you can release. Does this sound okay to you, :ato and :whimboo?
On the bright side, geckodriver can piggyback on what mozilla-central already has (see below for details of what needs to be tweaked). Otherwise, releng has to rethink the permission model in order to sign CI builds from mozilla-central with a non-dummy key (aka the "dep" key).


WHAT NEEDS TO CHANGE (if we sign at each Nightly)
* All platforms
  * We should update the task definition of the Nightly signing tasks by adding `public/target.common.tests.zip` to the list of upstream artifacts. This can be done by updating generate_specifications_of_artifacts_to_sign()[2]. Formats should be either sha2signcode (windows), macapp, or gpg (linux). We should ensure non-nightly builds aren't added.
  * Once geckodriver is signed, we can upload the file (and its signature, in the case of Linux) alone. Unlike Firefox, there is no need to package it back in a zip file. This means, we should just update the signing task of the nightly taskgraph - there is no need to modify repackage or repackage-signing.

* Windows
  * The signing_scriptworkers will extract the content of the zip archive for free, thanks to [3]. However, we should update _should_sign_windows()[4] to ensure we don't sign extra binaries in the new zip archive.

* Mac
  * We must extract the zipfile and give geckodriver alone to the signing server[5].
  * We need to update the signing server to be able to sign a file alone (instead of a .dmg package)[6]

* Linux
  * We must extract the zipfile and give geckodriver alone to the signing server.


Mac is the hardest platform, because it implies a change in an extra component (the signing server). Linux and Windows have about the same difficulty.



[1] For instance: https://queue.taskcluster.net/v1/task/GNo3owIhTEGufn2j_c40KQ/runs/0/artifacts/public/build/target.common.tests.zip
[2] https://searchfox.org/mozilla-central/rev/137f1b2f434346a0c3756ebfcbdbee4069e15dc8/taskcluster/taskgraph/util/signed_artifacts.py#11
[3] https://github.com/mozilla-releng/signingscript/blob/9c93715875a74e2d1f6842792f3a440dfeaf2090/signingscript/sign.py#L229
[4] https://github.com/mozilla-releng/signingscript/blob/9c93715875a74e2d1f6842792f3a440dfeaf2090/signingscript/sign.py#L236
[5] https://github.com/mozilla-releng/signingscript/blob/9c93715875a74e2d1f6842792f3a440dfeaf2090/signingscript/sign.py#L200
https://dxr.mozilla.org/build-central/rev/2cf0c5e65ade79e57d481ff3a39e20d41bcf60ea/tools/release/signing/signscript.py#170
[6] https://github.com/mozilla-releng/signingscript/blob/9c93715875a74e2d1f6842792f3a440dfeaf2090/signingscript/sign.py#L161

Comment 2

[Andreas Tolfsen ❲:ato❳]

Sorry for my belated response to this.  For what it’s worth,
I think you’ve got all the essential details right.

(In reply to Johan Lorenzo [:jlorenzo] from comment #1)

> SUGGESTED SOLUTION
> 
> We sign gecko driver at each build of Firefox Nightly. The keys
> used will be the ones that signs Firefox Nightly. The downside of
> this approach is: You only have 2 changesets per day that you can
> release. Does this sound okay to you, :ato and :whimboo?

It immediately sounds like a good idea to piggy-back on existing
Mozilla signing architecture, but since I don’t know how this
works in practice I have a few questions.  When you say that we only
sign twice daily, I assume you mean there are two changesets a day
that we release Nightly from.

What does that mean practically to a standalone program such as
geckodriver?  Does it mean that when we upload the release packages
to GitHub, the package must come from the official test package off
central?

Our current release pipeline only releases new versions when
we tag the git branch and push to the "release" branch on
https://github.com/mozilla/geckodriver.  With the approach you’re
suggesting, will we unconditionally build “snapshots” of
geckodriver twice daily?  Am I right in assuming we will have
to adjust our packaging scripts to produce something akin to
geckodriver-X.Y.Z-dirty.tar.gz if there have been changes since the
last release?

Comment 3

[Johan Lorenzo [:jlorenzo]]

(In reply to Andreas Tolfsen ‹:ato› from comment #2)
> When you say that we only sign twice daily, I assume you mean there
> are two changesets a day that we release Nightly from.
That's right.

> Does it mean that when we upload the release packages to GitHub,
> the package must come from the official test package off central?
Yes, that would be the way. Otherwise, signing has to be done differently from what Firefox does. Basically, our current signing pipeline ensures the code comes from a trusted tree. That's something harder if you want to introduce human decisions. 

> Our current release pipeline only releases new versions when
> we tag the git branch and push to the "release" branch on
> https://github.com/mozilla/geckodriver. 
In your current pipeline, where do the builds come from? 

> With the approach you’re suggesting, will we unconditionally build
> “snapshots” of geckodriver twice daily?
That's right.

> Am I right in assuming we will have to adjust our packaging scripts
> to produce something akin to geckodriver-X.Y.Z-dirty.tar.gz if
> there have been changes since the last release?
I'm unsure to understand the scope of this question. Do you mean something along: "Each geckodriver build has to be named named "geckodriver-X.Y.Z-dirty.tar.gz" and uploaded to Github releases?



Anyway, we can still implement a simpler solution[1]. This one would give you more control on what you sign. However, this requires the geckodriver team to securely use and store a GPG key. Moreover, like bloudraak said[2], Windows users will still see a warning because the executable doesn't come from a trusted party (i.e.: the build isn't signed). What do you think, Andreas?

[1] The one described in the Github issue https://github.com/mozilla/geckodriver/issues/1116#issuecomment-362608498
[2] https://github.com/mozilla/geckodriver/issues/1116#issuecomment-362688269

Comment 4

[Andreas Tolfsen ❲:ato❳]

Thanks for your prompt reply!

(In reply to Johan Lorenzo [:jlorenzo] from comment #3)

> (In reply to Andreas Tolfsen ‹:ato› from comment #2)
> 
> > Our current release pipeline only releases new versions when
> > we tag the git branch and push to the "release" branch on
> > https://github.com/mozilla/geckodriver.
> 
> In your current pipeline, where do the builds come from?

Builds are done on Travis and a release will be made when a commit
is tagged.

> > With the approach you’re suggesting, will we unconditionally
> > build “snapshots” of geckodriver twice daily?
> 
> That's right.

Just a quick follow-up on this: How do we identify the commits?

> > Am I right in assuming we will have to adjust our
> > packaging scripts to produce something akin to
> > geckodriver-X.Y.Z-dirty.tar.gz if there have been changes since
> > the last release?
> 
> I'm unsure to understand the scope of this question. Do you mean
> something along: "Each geckodriver build has to be named named
> "geckodriver-X.Y.Z-dirty.tar.gz" and uploaded to Github releases?

You’re right, I think distribution and packaging goes beyond
the scope of signing the binaries.  At some point we will need to
address packaging for the signed commits when the version number is
bumped, and have a TC task that uploads the packages to GitHub.

However, for Firefox, do we sign the final package (.tar.gz) or the
binary itself?

> Anyway, we can still implement a simpler solution[1]. This one
> would give you more control on what you sign. However, this
> requires the geckodriver team to securely use and store a GPG
> key. Moreover, like bloudraak said[2], Windows users will still
> see a warning because the executable doesn't come from a trusted
> party (i.e.: the build isn't signed).

I think it is well worth leveraging the existing Firefox signing
infrastructure.  I predict a daily limit of two releases a day will
not be a problem for us.

I should reveal that we are eyeing a future where geckodriver is
distributed alongside the Firefox binary, so this makes a lot of
sense for us.

Comment 5

[Johan Lorenzo [:jlorenzo]]

(In reply to Andreas Tolfsen ‹:ato› from comment #4)
> Builds are done on Travis and a release will be made when a commit
> is tagged.

Ah I see! I though you guys already relied on the builds made on Taskcluster. In the new model, Travis won't be involved anymore. You will manually upload new releases based on the signed artifacts on Taskcluster.

> Just a quick follow-up on this: How do we identify the commits?

Very good question! There are a few ways. You can either:
* Look at the Nightly-signing jobs on Treeherder: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-job_type_symbol=Ns
* Look at the Taskcluster's index. For instance, the latest nightly on linux is at: https://tools.taskcluster.net/index/gecko.v2.mozilla-central.signed-nightly.latest.firefox-l10n.linux-opt/en-US. There you can look at the task, and see against what revision it was created.

> You’re right, I think distribution and packaging goes beyond
> the scope of signing the binaries.  At some point we will need to
> address packaging for the signed commits when the version number is
> bumped, and have a TC task that uploads the packages to GitHub.

Nice! May I have a look at an example of this task? 


> However, for Firefox, do we sign the final package (.tar.gz) or the
> binary itself?

It depends on the platform: 
* Windows binaries are signed. That's why the original github issue was filed
* Mac and Linux packages are signed, but not the binaries.

> I think it is well worth leveraging the existing Firefox signing
> infrastructure.  I predict a daily limit of two releases a day will
> not be a problem for us.
Sweet!

Comment 6

[Andreas Tolfsen ❲:ato❳]

Thanks again for all the useful feedback.

(In reply to Johan Lorenzo [:jlorenzo] from comment #5)

> (In reply to Andreas Tolfsen ‹:ato› from comment #4)
> 
> > Builds are done on Travis and a release will be made when a
> > commit is tagged.
> 
> Ah I see! I though you guys already relied on the builds made
> on Taskcluster.

Alas not yet, see bug 1372587 for details.

> In the new model, Travis won't be involved anymore. You will
> manually upload new releases based on the signed artifacts on
> Taskcluster.

Indeed.  There are a couple of unrelated things, such as lack of
platform support, that prevents us from actually releasing from
Taskcluster, but none of this prevents us from getting digital
signing sorted out.

> > You’re right, I think distribution and packaging goes beyond
> > the scope of signing the binaries.  At some point we will need
> > to address packaging for the signed commits when the version
> > number is bumped, and have a TC task that uploads the packages
> > to GitHub.
> 
> Nice! May I have a look at an example of this task?

On Travis we use this:

	https://searchfox.org/mozilla-central/rev/056a4057575029f58eb69ae89bc7b6c3c11e2e28/testing/geckodriver/build.sh#113-134

But based on what you’re telling me, because the macOS and Linux
packages need to be signed, we need to sort out packaging on TC for
every build before we can fix this bug.

I’ve filed bug 1441581 to always run packaging steps on TC when we
build.

> > However, for Firefox, do we sign the final package (.tar.gz) or
> > the binary itself?
> 
> It depends on the platform:
> 
> * Windows binaries are signed. That's why the original github
>   issue was filed
> * Mac and Linux packages are signed, but not the binaries

Understood.

Comment 7

[Johan Lorenzo [:jlorenzo]]

(In reply to Andreas Tolfsen ‹:ato› from comment #6)
> Thanks again for all the useful feedback.
No problem! I'm glad to help :) 

> There are a couple of unrelated things, such as lack of
> platform support, that prevents us from actually releasing from
> Taskcluster, but none of this prevents us from getting digital
> signing sorted out.

I agree. We can take away some of the complexity by starting off with Windows. That's the platform that yells when binaries aren't signed. Linux (and its different flavors) doesn't [they check signatures at installation time]. Mac doesn't warn out if the program is started via the Terminal, which is the case for many developers, I think. 

> But based on what you’re telling me, because the macOS and Linux
> packages need to be signed, we need to sort out packaging on TC for
> every build before we can fix this bug.

Yes, the would be great to have the package create at the output of the build task, I think. If that's too much work, then we can proceed with "WHAT NEEDS TO CHANGE" in comment 1.

Comment 8

[Andreas Tolfsen ❲:ato❳]

Yes, let’s take this step by step.  Signing the Windows binary so
it doesn’t shout at you seems like the priority here.  I’ve filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1442340 specifically
about this, and turned this bug into a tracking bug.

Comment 10

[Andreas Tolfsen ❲:ato❳]

geckodriver is now built on Windows, which means we should have
everything in place for signing the binaries.  jlorenzo, do you
have capacity to look at this?

Comment 11

[Johan Lorenzo [:jlorenzo]]

I talked to :catlee about this project for Q4. Deferring the call to him.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Johan, on bug 1493948 we want to package geckodriver into its own artifact beside the test archive (which is only used for our CI test jobs). As such I would have to setup a task which picks the geckodriver binary from the common.tests archive, and moves it into a separate geckodriver tar.gz or zip file. 

Given that this would effectively duplicate the binary. But we actually only need to sign the binary we are about to release and which will be the product of that to be created task. 

I wonder if the signing task could actually do that move into the target artifact. If not, where would be the best place to inject the task in the taskgraph of a Nightly build?

Thanks!

Comment 13

[Chris AtLee [:catlee]]

I don't think the signing task is the right place to do the move into the target artifact. Generally our signing tasks are responsible for only signing.

It sounds a bit like you want a "repackage" task after signing the geckoview binary is signed that will produce your final geckodriver zip file.

Comment 14

[Johan Lorenzo [:jlorenzo]]

I agree with :catlee, the signing task run on critical machines and we don't want to overload them with grunt work. 

Out of curiosity, why do you need geckodriver.exe to be in a zip file? If it's because some resource files must be packaged alongside the binary, then repackage task is the way to go. This means the nightly graph will be:

+---------------------+    +-----------------------------+    +---------------------+
| build task produces | -> | first repackage task takes   | -> | signing task signs  |
| common.test.zip     |    | geckodriver.exe out of      |    | geckodriver.exe and |
+---------------------+    | common.test.zip and exposes |    | exposes it as a TC  |
                           | as a taskcluster artifact   |    | artifact            |
                           +-----------------------------+    +---------------------+
                    |                                            |
                    ˇ                                            ˇ                                               
                    +--------------------------------------------+
                    | second repackage tasks takes signed        |
                    | geckodriver.exe and bundles all necessary  |
                    | files in a tar.gz/zip archive               |
                    +--------------------------------------------+

How does that sound to you?

Comment 15

[Andreas Tolfsen ❲:ato❳]

Thanks for the illustrative diagram, jlorenzo, much obliged!

That does indeed sound reasonable to me.  Since geckodriver.exe is
already part of common.test.zip, extracting it from there to sign
it, before we re-package it into a .zip file we can distribute to
consumers sounds like it would fulfil the requirements we have.

I’m assuming in this process, the first-repackage-task above only
runs once/twice a day when signing is being done?

I’ll needinfo whimboo here to get everyone on board before we move
forward.

Comment 16

[Johan Lorenzo [:jlorenzo]]

(In reply to Andreas Tolfsen ❲:ato❳ from comment #15)
> I’m assuming in this process, the first-repackage-task above only
> runs once/twice a day when signing is being done?
That's right, it should happen every time a new nightly is kicked off, which is usually twice a day.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Johan Lorenzo [:jlorenzo] - On PTO - Back on November 19th from comment #16)
> > I’m assuming in this process, the first-repackage-task above only
> > runs once/twice a day when signing is being done?
> That's right, it should happen every time a new nightly is kicked off, which
> is usually twice a day.

I wonder if we would need this second repackaging task at all. Once we extracted the binary from the common.tests package we could directly create a zip file, which then the signing task can use to sign the binary. Given that the signing task has to produce another artifact it could directly create a new zip file, right? And I assume we can use this last produced zip file for our distribution.

How long will those artifacts from signing tasks be available? I wonder if we could just point our release page to those files, or if we still better have to copy those to a different location.

Comment 18

[Johan Lorenzo [:jlorenzo]]

:whimboo and I discussed over IRC. 

Content of the final zip file: just geckoview.exe. However, some files (like a README) may be added in the future. If the geckoview drivers want to change what they publish in the final zip, it's best to keep the second repackaging task. If we wanted to put the zip archive creation within the signing task, you would need Release Engineering to accept your changes in this external repo[1] and deploy it to the signing workers. This is what we wanted to avoid when we move from Buildbot to Taskcluster. 

> How long will those artifacts from signing tasks be available?

It depends on when the signing task expires[2]. By default and more specifically on nightly, tasks expire after a year[3]. 

Both repackaging tasks must be defined under [4] (create a new folder and put a kind.yml). The content of kind.yml may reuse existing docker-worker definitions. You need docker-worker if you want to pass a command line. I know this example, on top of my head[5], but there may be better example out there. 
The signing task is defined here[6], but the magic actually happens there [7]. I think you should add the kind of the first repackage task under [8] and add the zip artifact and somewhere here [9]


[1] https://github.com/mozilla-releng/signingscript
[2] https://github.com/mozilla-releng/scriptworker/blob/b09074dcd114254505b8c77e767b6c850c9fce3b/scriptworker/artifacts.py#L265
[3] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/taskcluster/taskgraph/transforms/task.py#1710
[4] https://searchfox.org/mozilla-central/source/taskcluster/ci
[5] https://searchfox.org/mozilla-central/source/taskcluster/ci/release-snap-repackage/kind.yml#27
[6] https://searchfox.org/mozilla-central/source/taskcluster/ci/build-signing/kind.yml
[7] https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/transforms/build_signing.py
[8] https://searchfox.org/mozilla-central/source/taskcluster/ci/build-signing/kind.yml#14
[9] https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/util/signed_artifacts.py#47

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Johan for the detailed answer! I think that should be enough information to get us started.

Just to be sure about the process now... I will have to implement the first repackaging step now as best on a different bug. Then once landed you can follow-up here with the signing? And at last we have the final repackaging step (if needed)? Or could all be done in a single bug.

What would you suggest? Thanks

Comment 20

[Johan Lorenzo [:jlorenzo]]

Multiple bugs sounds great! Releng can follow up once the first repackage is live :)

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sorry for the delay here, but bug 1493948 will cover that. It's something I want to work on next now.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Chris, I started to work on the repackage task to extract the geckodriver binary from common.tests.zip. Not sure how long it will take given that it is new to me. If RelEng would have a bit of capacity and take it, I assume it would be done much faster. If not, I will continue and may have a lot of questions through.

Given all the discussion above I wonder if you could have a look at comment 1 again. Is the signing something RelEng could do in Q1 or early Q2? Maybe there are some dependencies listed in comment 1 which are independent from my work and already could be worked on?

Thanks in advance.

Comment 23

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1427849 - Part 1: Add geckodriver-release TC kind.

These tasks fetch build artifacts and extract them. Then there's a
final repackaging job that produces the format that the existing
geckodriver Github releases have.

Eventually, signing jobs will sit between the fetch and the
repackaging job.

Comment 24

[Nick Alexander :nalexander [he/him]]

Oh my, apparently two people wanted this in the last ~24 hours. Henrik, please take over :)

The next steps would be to add a new taskgraph transform to remove all the duplication in the tasks; they're very manual right now. I'm not 100% sure this does the right thing because my try jobs aren't appearing on TH right now.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sounds amazing! But lets take this conversation / work over to bug 1493948. This bug is for the signing job only.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With bug 1493948 fixed now, there shouldn't be a blocker anymore for RelEng to get started on that bug. Given that I haven't gotten feedback from catlee yet, I wonder whom else I could ask if there is any work for this bug planned in Q1/Q2? Johan, maybe know whom to ask?

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Repack jobs appear here now:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=geckodriver

Comment 28

[Johan Lorenzo [:jlorenzo]]

:jlund may have some input regarding comment 26 and comment 22.

Comment 29

[Jordan Lund (:jlund)]

@whimboo - sounds like we provide some authenticity through signing the checksums file. So this is mostly about ensuring that AV and windows security doesn't prevent execution of geckodriver itself? How important is this?

@jlorenzo - Depending on priority, we could fit it in in Q2. Not in Q1 given time left and other work in flight. Does that sound reasonable to you if we put it on your plate?

@mtabara - I want to put this on your radar as you have vested interest in how we declare artifacts. It sounds like from bug 1493948 we are extracting the webdriver artifact out later on in the per-checkin graph and will end up needing to be beetmoved? Does this break our goal of having all release artifacts defined from in-tree manifest?

Comment 30

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Jordan Lund (:jlund) from comment #29)

@whimboo - sounds like we provide some authenticity through signing the checksums file. So this is mostly about ensuring that AV and windows security doesn't prevent execution of geckodriver itself? How important is this?

Correct. For each release of geckodriver we have such reports from users. We lived with that already for a while, and it would be great to see the binary signed. But it is not critical right now. If there would be a chance for Q2 that would be great.

@mtabara - I want to put this on your radar as you have vested interest in how we declare artifacts. It sounds like from bug 1493948 we are extracting the webdriver artifact out later on in the per-checkin graph and will end up needing to be beetmoved? Does this break our goal of having all release artifacts defined from in-tree manifest?

Callek pinged me on IRC and there is also some work he will do which will refactor parts of that. Maybe he can explain it here.

Comment 31

[Justin Wood (:Callek)]

To be clear the work whimboo mentioned was shippable builds, which I feel like mihai and jordan have a good understanding on. I'm happy to chat with others but I don't think it directly impacts this bug any more than me just needing to know what this bugs general plan and needs were, so I can make sure my code doesn't hamper this effort

Comment 32

[Johan Lorenzo [:jlorenzo]]

(In reply to Jordan Lund (:jlund) from comment #29)

@jlorenzo - Depending on priority, we could fit it in in Q2. Not in Q1 given time left and other work in flight. Does that sound reasonable to you if we put it on your plate?

I can work on this in Q2 👍

Comment 33

[Johan Lorenzo [:jlorenzo]]

Attachment: Bug 1427849 - Digitally sign geckodriver binaries on Windows and Linux

Digitally sign geckodriver binaries on Windows and Linux

Comment 34

[Johan Lorenzo [:jlorenzo]]

Status update:

Windows signature

I checked the signature[1] of my try build[2]:

SignTool verify /v geckodriver.exe

Signature Index: 0 (Primary Signature)
Hash of file (sha1): EF4AA0E309F44B84B12D662810432F725D4D5DEF

Signing Certificate Chain:
    Issued to: Mozilla Fake SPC
    Issued by: Mozilla Fake CA
    Expires:   Tue Jun 30 17:20:46 2037
    SHA1 hash: B7298151F99A58B118109BDDB8523BD91517BCB8

File is not timestamped.

SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

This shows the binary was indeed signed. The error tells the signing key that was used is not trusted. That's what we want on try. Result should be different once it's landed.

Linux signature

It's a regular detached gpg signature[3]

Mac signature

Like said in comment 1, Mac requires more work. That said bug 1470607 is paving the way. I'm planning on not landing the mac signature, until bug 1470607 is done. I can open a followup bug.

[1] https://docs.microsoft.com/en-us/windows/desktop/seccrypto/using-signtool-to-verify-a-file-signature
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=186dcadf5b929cf876189982fc44225dd8fe4c63&selectedJob=241003234
[3] https://treeherder.mozilla.org/#/jobs?repo=try&revision=186dcadf5b929cf876189982fc44225dd8fe4c63&selectedJob=241002480

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Fantastic news Johan! I agree that we should get this landed as is, and have a follow-up bug for the Mac signing part. I will file a bug in a moment.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/80a5deca7438
Digitally sign geckodriver binaries on Windows and Linux r=aki

Comment 37

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/80a5deca7438

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Starting with https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=geckodriver&revision=4b0811d7b8e1591d4e48a26bdb8666a1bc5ccf61 we now have signed builds on Windows and Linux! Tested and it looks great. Thanks a lot Johan!

Comment 39

[Johan Lorenzo [:jlorenzo]]

I confirm Windows doesn't yell anymore when trying to start the binary. I ran signtool.exe against the binaries in comment 38 and here's the output:

c:\Program Files (x86)\Windows Kits\10\bin\x64>signtool.exe verify /v /pa c:\Users\gilou\Documents\geckodriver-1\geckodriver.exe

Verifying: c:\Users\gilou\Documents\geckodriver-1\geckodriver.exe
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 551690840E1E6ECE7AC83CD9BEC113C8223CBB7A

Signing Certificate Chain:
    Issued to: DigiCert Assured ID Root CA
    Issued by: DigiCert Assured ID Root CA
    Expires:   Mon Nov 10 02:00:00 2031
    SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

        Issued to: DigiCert SHA2 Assured ID Code Signing CA
        Issued by: DigiCert Assured ID Root CA
        Expires:   Sun Oct 22 14:00:00 2028
        SHA1 hash: 92C1588E85AF2201CE7915E8538B492F605B80C6

            Issued to: Mozilla Corporation
            Issued by: DigiCert SHA2 Assured ID Code Signing CA
            Expires:   Fri Jun 28 14:00:00 2019
            SHA1 hash: B6B24AEA9E983ED6BDA9586A145A7DDD7E220196

The signature is timestamped: Wed Apr 24 02:17:44 2019
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

        Issued to: Symantec Time Stamping Services CA - G2
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 01:59:59 2020
        SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

            Issued to: Symantec Time Stamping Services Signer - G4
            Issued by: Symantec Time Stamping Services CA - G2
            Expires:   Wed Dec 30 01:59:59 2020
            SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4


Successfully verified: c:\Users\gilou\Documents\geckodriver-1\geckodriver.exe

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Note for anybody trying to verify a signature with SignTool: don't forget to put the /pa flag, otherwise SignTool outputs an error because [1][2]:

/pa Specifies that the Default Authentication Verification Policy is used. If the /pa option is not specified, SignTool uses the Windows Driver Verification Policy. This option cannot be used with the catdb options.

[1] https://stackoverflow.com/questions/2722061/why-is-my-code-signing-ms-authenticode-verification-failing
[2] https://docs.microsoft.com/en-us/windows/desktop/seccrypto/signtool