1193672 - Dictionaries without type=64 in install.rdf are treated like regular extensions

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, defect)

Description

[Paul [pwd]]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150811101443

Steps to reproduce:

Dictionaries are unsigned meaning they get disabled.

Comment 1

[Paul [pwd]]

UK speaking users need to either be migrated to a newer add-on or this one needs to be signed.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

I tried installing a couple of dictionaries and got a signing warning. I think it's because they have no type declaration.

I found one with the right type (64) and that one didn't cause any issues: https://addons.mozilla.org/addon/assamese-spell-checker/

So, this brings up a couple of questions:
1) What should we do about these dictionaries, sign them, find a way to allow their installation without a type, or find a way to add the right type (pushing devs won't get us far)?
2) Can an extension just use type=64 to bypass signing? Are there runtime restrictions on what type=64 can do?

Comment 3

[Dave Townsend [:mossop]]

(In reply to Jorge Villalobos [:jorgev] from comment #2)
> I tried installing a couple of dictionaries and got a signing warning. I
> think it's because they have no type declaration.
> 
> I found one with the right type (64) and that one didn't cause any issues:
> https://addons.mozilla.org/addon/assamese-spell-checker/
> 
> So, this brings up a couple of questions:
> 1) What should we do about these dictionaries, sign them, find a way to
> allow their installation without a type, or find a way to add the right type
> (pushing devs won't get us far)?

If there is a way to auto-detect safely then I'm open to that.

> 2) Can an extension just use type=64 to bypass signing? Are there runtime
> restrictions on what type=64 can do?

A type 64 add-on gets installed but then we run a custom startup script for it (https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/SpellCheckDictionaryBootstrap.js). Short of a vulnerability in hunspell they shouldn't be able to do anything else there.

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Dave Townsend [:mossop] from comment #3)
> (In reply to Jorge Villalobos [:jorgev] from comment #2)
> > I tried installing a couple of dictionaries and got a signing warning. I
> > think it's because they have no type declaration.
> > 
> > I found one with the right type (64) and that one didn't cause any issues:
> > https://addons.mozilla.org/addon/assamese-spell-checker/
> > 
> > So, this brings up a couple of questions:
> > 1) What should we do about these dictionaries, sign them, find a way to
> > allow their installation without a type, or find a way to add the right type
> > (pushing devs won't get us far)?
> 
> If there is a way to auto-detect safely then I'm open to that.

Dictionary add-on IDs follow this pattern: [e-mail]. Perhaps making that equivalent to type=64 when no type is present would be enough.

Comment 5

[Jorge Villalobos [:jorgev] (he/him)]

Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.

Sorry for the bug spam, and happy Friday!