1257627 - fix workflow of development of talos addons

Status: RESOLVED FIXED

(Testing :: Talos, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

talos development is not exciting anymore- we can make it better!

right now any changes to addons (which is most tests) need to be signed before landing on inbound.  In fact we can land a bunch of changes and inbound will only run the signed addons- so code can get landed and not used.

I propose that we make a method to resolve this discrepancy by either 1 of 2 methods:
1) have a task (like flake8 already runs per talos job) which compares the signed addon source with the checked in source, turn the job orange if it fails, this is simple with:
foreach addon:
  unzip addon-signed.xpi
  diff -r addon_src/ unzipped_addon/ | grep -v META-INF
  ^ if any differences report an error

2) unpack all addon-signed.xpi files (this would just be adding META-INF files to the tree).  At runtime dynamically build the signed.xpi and this will fail if the files don't match the checksums.


Once we have this, then we can determine where and when we force the signing.  Right now we use the addons from source on try, but the signed.xpi files everywhere else.  Ideally we can find the right balance.


The long term goal would be to make all addons install dynamically (except for ones related to startup- this could include profiling, talos-powers, etc.)  This would reduce the need for signing.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

verifying these on try is confusing as there are 2 spots where we hack addons:
https://dxr.mozilla.org/mozilla-central/search?q=path%3Atesting%2Ftalos+try%27&redirect=false

I was pinging in bug 1306780 and on irc from :philor regarding the confusion here.

Comment 2

[Avi Halachmi (:avih)]

(In reply to Joel Maher ( :jmaher) from comment #0)
> 1) have a task (like flake8 already runs per talos job) which compares the
> signed addon source with the checked in source, turn the job orange if it
> fails ...
>
> 2) unpack all addon-signed.xpi files (this would just be adding META-INF
> files to the tree).  At runtime dynamically build the signed.xpi and this
> will fail if the files don't match the checksums.

I'm not entirely sure I understand 2, but I still think there's a 3rd option, at least as wishful thinking:

- Devs commit changes only to sources (like it used to be before the signing), and there's some [semi/pseudo/fully] automatic server-side thingy which, if it detects that the sources don't match the xpi, then it:
- recreates the xpi from the newly updates sources
- signs the newly created xpi
- pushes the newly signed xpi

So in effect pushing new versions of the source files will automatically push a new signed version of the xpi which reflects the new sources.

Comment 3

[Avi Halachmi (:avih)]

ryanvm suggested another option today:
- Removing the XPIs from the repo.
- Create the XPIs on the fly (which talos already does).
- Sign the XPIs during the build process where necessary (e.g. for non-try pushes).

He says there are already other things we sign using some secure infrastructure, for instance OS X and Windows builds, so preferably we can use a similar thing for addons, and avoid including signed binaries at the repo to begin with.

Ryan, did I get it right? any pointers for this?

Comment 4

[Ryan VanderMeulen [:RyanVM]]

It just seems silly to me that we need to send our own internal test XPIs to AMO for signing. Why can't we bundle and sign them as part of the packaging process? Besides the repo bloat from having checkin-in binary blobs, it's a really annoying inconsistency between Try and production branches that's already proven to cause backouts and needless churn.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

if we sign them on the fly, we would need to update the version number automatically for each signing.  That alone seems scary enough to me.

if there is a better suggestion for doing this, I am all ears- that is why this bug is on file :)

Comment 6

[Avi Halachmi (:avih)]

(In reply to Joel Maher ( :jmaher) from comment #5)
> if we sign them on the fly, we would need to update the version number
> automatically for each signing.  That alone seems scary enough to me.

I believe the requirement to update the version number comes from AMO. But if we establish a different system for signing during the build process without involving AMO, then I think versioning should not be an issue. I.e. just sign with whatever version the last commit had.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

we do not need signed addons anymore