[tbb-dev] TBB vs mandatory extension signing

[Georg Koppen]

anonym:
> Georg Koppen:
>> anonym:
>>> [This is a repost of my full original post. It contains a line consisting only of "--" which makes some MUA:s think "ah, the rest is a signature, let's hide it".]
>>>
>>> Hi,
>>>
>>> In Tails we've been wondering what to do about Firefox's mandatory extension signing [1] in FF52ESR since the opt-out preference that we have been using for FF45ESR will be removed from released versions. Today I found the Tor Browser's solution for tor-browser-52.0.2esr-7.0-2 in commit 584c17c1b3e07239b8dd195e8b91eefb2ff9b2f4; here's an extract:
>>>
>>>      function isCorrectlySigned(aAddon) {
>>>        // Add-ons without an "isCorrectlySigned" property are correctly signed as
>>>        // they aren't the correct type for signing.
>>>     +  if (aAddon.id == "torbutton at torproject.org" ||
>>>     +      aAddon.id == "tor-launcher at torproject.org" ||
>>>     +      aAddon.id == "https-everywhere-eff at eff.org") {
>>>     +    return true;
>>>     +  }
>>>        return aAddon.isCorrectlySigned !== false;
>>>      }
>>>
>>> So it's a list of exceptions. In Tails we install two additional extensions we'd like exceptions for:
>>>
>>> * a localization-related extension that we generate dynamically *during build*, so signing will be impossible.
>>> * Ublock Origin, which we install from Debian, and the signature is missing.
>>>
>>> Can this list of exceptions be moved to an external file that we in Tails can modify instead? I think I have exhausted all options we have on our side. [2]
>>
>> Hm. I have not thought about having a different method for setting up a
>> whitelist, so, maybe?
> 
> "Maybe" as in "patches welcome"? :P Or is there something you find problematic with this whole idea?

I am not so happy with the external file idea. Maybe having a preference
would be enough? In general, I like to avoid complexity in this
particular area but if there is no other way to keep Tails working I
think we would take a patch.

>> Regarding your [2]: the binary files are just
>> optimizations. You can delete the respective file(s) and the
>> uncompressed one(s) will be used. That should have a tiny performance
>> impact but that might be negligible in your case.
> 
> What do you mean with "uncompressed one(s)"? In my attempt of [2] I removed the affected .jsm files inside the omni.ja archives, hoping that the pure .js ones would be used (with a negligible performance hit), but when I tried starting Tor Browser I got tons of errors logged to stderr, no add-ons were loaded, abd the add-on manager only showed the "Get add-ons" tab. I might have done something wrong, so I'll retry once I've gotten your clarification.
> 
> Note that in Tails the Tor Browser directory is not writeable by the user running Tor Browser (only the profile directory is) which might influence this e.g. if Tor Browser would like to write uncompressed .jsm files into the Tor Browser directory. 

That's what I meant. I've been working with this method for a while now
when I need to modify js stuff related to the Firefox front-end side as
this is the fasted way to test changes. I had no issues so far. Note
that with 7.0a3 there should be no compressed JS code modules etc. in
omni.ja files anymore. See:
https://trac.torproject.org/projects/tor/ticket/21960 and the linked
Mozilla bug for further details. We are currently doing the hopefully
final -build5 and the 7.0a3 we give out should have it.

[snip]

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170418/c9c8ffb3/attachment.sig>