Tails

#1 Updated by intrigeri 2016-05-15 00:50:16

Two things:

• I’ve been told that adding one’s own key to the list of those trusted by Firefox for signing extensions is not so hard, and well documented. We do that for our APT repo, perhaps we can do the same for amnesia branding?
• Disabling xpinstall.signatures.required is probably OK as a short-term workaround for 2.4, but on the slightly longer term I’d like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

#2 Updated by anonym 2016-05-15 03:47:39

intrigeri wrote:
> Two things:
>
> * I’ve been told that adding one’s own key to the list of those trusted by Firefox for signing extensions is not so hard, and well documented. We do that for our APT repo, perhaps we can do the same for amnesia branding?

Sure, but will this actually be possible since the key has to be available during build, for everyone? Well, we can generate the signing key during build and then let it disappear into the empty void, but it feels wrong.

> * Disabling xpinstall.signatures.required is probably OK as a short-term workaround for 2.4

Thanks, I feel more confident about Feature #11403 with you “probably” backing me on this. :)

> but on the slightly longer term I’d like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?

#3 Updated by intrigeri 2016-05-16 14:01:20

> Sure, but will this actually be possible since the key has to be available during build, for everyone?

Well, that’s not what I meant. We could do exactly the same as what we do for our custom Debian packages: build, sign and publish outside of the regular build process.

> Well, we can generate the signing key during build and then let it disappear into the empty void, but it feels wrong.

Agreed.

>> but on the slightly longer term I’d like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.

> Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?

Yes, we do: when they haven’t enough room left for an incremental upgrade, users are pointed to a full ISO download, and that uses DAVE. Nothing tells them that they need to download the ISO from a non-Tails system.

#4 Updated by anonym 2016-05-17 16:17:55

intrigeri wrote:
> > Sure, but will this actually be possible since the key has to be available during build, for everyone?
>
> Well, that’s not what I meant. We could do exactly the same as what we do for our custom Debian packages: build, sign and publish outside of the regular build process.

I see. IMHO generating it during build is very nice, and I think I’d rather modify the langpacks (which do not need be signed) with the corresponding changes rather than introducing yet another .deb to maintain.

> >> but on the slightly longer term I’d like to see it enabled, because we rely a lot on DAVE nowadays to secure Tails ISO downloads.
>
> > Clearly I agree that we need a better solution, but inside Tails we do not really depend much on DAVE, right?
>
> Yes, we do: when they haven’t enough room left for an incremental upgrade, users are pointed to a full ISO download, and that uses DAVE. Nothing tells them that they need to download the ISO from a non-Tails system.

Got it, thanks!

#5 Updated by intrigeri 2016-05-17 16:50:41

> I see. IMHO generating it during build is very nice, and I think I’d rather modify the langpacks (which do not need be signed) with the corresponding changes

Fine by me.

> rather than introducing yet another .deb to maintain.

Just to clarify, I was not suggesting to introduce a .deb, but to build, sign and publish the add-on in XPI format.

#8 Updated by anonym 2016-12-14 18:54:22

I think an easier way to support this is:

• Replace AdBlock Plus with uBlock Origins (Feature #9833)
• Kill the amnesia branding plugin, and instead modify the langpacks. We do that any way, so why not some more? :)

#12 Updated by anonym 2016-12-14 19:19:43

anonym wrote:
> I think an easier way to support this is:
>
> * Replace AdBlock Plus with uBlock Origins (Feature #9833)

This wont help us apparently: installing uBlock Origins via the .deb still results in an unsigned add-on.

Worst case: we fetch the addon (AdBlock Plus or uBlock Origins) from AMO at build time. The extension signing should make this safe even if we just fetch over https.

> * Kill the amnesia branding plugin, and instead modify the langpacks. We do that any way, so why not some more? :)

This still works.

#14 Updated by spriver 2017-01-05 19:44:07

Working on Feature #9833 I did some tests with installing addons via apt (xul-ext-ublock-origin). My findings were:

• After the installation it will be loaded as a signed addon in FF45-esr, FF50 and FF51 from /usr/share/xul-ext/ublock-origin
• Once the addon will be linked via ln -s into a location in the browsers hidden folder in the home directory (e.g. _{/.mozilla/firefox/$profilename/extensions on a pure Debian, resp.}/.tor-browser/profile-default/extensions for Tails) the signing will be broken
• Loading a plugin for Tor Browser in Tails from a location that is not in ~/.tor-browser/profile.default/ is not possible. I suspect that this is a security mechanism of the TBB as deactivating AppArmor for TBB in Tails won’t change it.

#22 Updated by intrigeri 2017-05-19 20:14:54

Code review passes.