Add-on security restrictions - Mozilla

This is a discussion on Add-on security restrictions - Mozilla ; Crossposting this to a few newsgroups. I have just checked in Bug 378216, Disable insecure extension updates by default, and wanted to give a quick heads up on it. What this means is that we are now enforcing a security ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Add-on security restrictions

  1. Add-on security restrictions

    Crossposting this to a few newsgroups.

    I have just checked in Bug 378216, Disable insecure extension updates by
    default, and wanted to give a quick heads up on it.

    What this means is that we are now enforcing a security restriction on
    all add-ons. To be specific, if an add-on does not provide a secure
    method of auto-updating then by default Firefox will refuse to install
    the add-on. If you have add-ons already installed that are insecure in
    this way then they will be automatically disabled.

    The good news is that addons.mozilla.org already uses SSL for it's
    updates, so any add-ons you have installed from there will be unaffected
    by this change. Equally any add-on authors who use SSL on their site,
    their add-ons will be unaffected. Personally I found 2 of my add-ons
    were disabled by it, that's 2 out of nearly 20, so hopefully you won't
    see a major impact.

    For add-on authors there is an alternate way to provide secure updates
    without investing in an SSL key involving digital signatures,
    unfortunately we've had to hold off on providing the software to make
    that possible until the backend changes were complete and reviewed. I
    hope to have something usable available not too long after M8 is released.

    If you want to see more of the specifics the best place to look is
    probably at the wiki page at
    http://wiki.mozilla.org/User:Mossop:...UpdateSecurity

    Cheers

    Dave

  2. Re: Add-on security restrictions

    Dave Townsend wrote:
    > Crossposting this to a few newsgroups.
    >
    > I have just checked in Bug 378216, Disable insecure extension updates by
    > default, and wanted to give a quick heads up on it.
    >
    > What this means is that we are now enforcing a security restriction on
    > all add-ons. To be specific, if an add-on does not provide a secure
    > method of auto-updating then by default Firefox will refuse to install
    > the add-on. If you have add-ons already installed that are insecure in
    > this way then they will be automatically disabled.
    >
    > The good news is that addons.mozilla.org already uses SSL for it's
    > updates, so any add-ons you have installed from there will be unaffected
    > by this change. Equally any add-on authors who use SSL on their site,
    > their add-ons will be unaffected. Personally I found 2 of my add-ons
    > were disabled by it, that's 2 out of nearly 20, so hopefully you won't
    > see a major impact.
    >
    > For add-on authors there is an alternate way to provide secure updates
    > without investing in an SSL key involving digital signatures,
    > unfortunately we've had to hold off on providing the software to make
    > that possible until the backend changes were complete and reviewed.


    Does checking in the code *before* providing that software, and thus
    screwing add-on authors over at mozdev.org (and their customers) count
    for you or what? Obviously not it seems.

    > I
    > hope to have something usable available not too long after M8 is released.


    So when will M8 be released? People have to guess? Not everyone will
    know where to look for this kind of info you know.

    > If you want to see more of the specifics the best place to look is
    > probably at the wiki page at
    > http://wiki.mozilla.org/User:Mossop:...UpdateSecurity


    Which is pretty much useless for mozdev.org and other third party add-on
    provider platforms.

    --
    Michael Vincent van Rantwijk
    - MultiZilla Project Team Lead
    - XUL Boot Camp Staff member (ActiveState Training Partner)
    - iPhone Application Developer


  3. Re: Add-on security restrictions

    Michael Vincent van Rantwijk, MultiZilla wrote:
    > Dave Townsend wrote:
    >> Crossposting this to a few newsgroups.
    >>
    >> I have just checked in Bug 378216, Disable insecure extension updates
    >> by default, and wanted to give a quick heads up on it.
    >>
    >> What this means is that we are now enforcing a security restriction on
    >> all add-ons. To be specific, if an add-on does not provide a secure
    >> method of auto-updating then by default Firefox will refuse to install
    >> the add-on. If you have add-ons already installed that are insecure in
    >> this way then they will be automatically disabled.
    >>
    >> The good news is that addons.mozilla.org already uses SSL for it's
    >> updates, so any add-ons you have installed from there will be
    >> unaffected by this change. Equally any add-on authors who use SSL on
    >> their site, their add-ons will be unaffected. Personally I found 2 of
    >> my add-ons were disabled by it, that's 2 out of nearly 20, so
    >> hopefully you won't see a major impact.
    >>
    >> For add-on authors there is an alternate way to provide secure updates
    >> without investing in an SSL key involving digital signatures,
    >> unfortunately we've had to hold off on providing the software to make
    >> that possible until the backend changes were complete and reviewed.

    >
    > Does checking in the code *before* providing that software, and thus
    > screwing add-on authors over at mozdev.org (and their customers) count
    > for you or what? Obviously not it seems.


    Unfortunately we are up against platform freeze deadlines so getting the
    backend in before freeze was the most important issue. Of course we are
    only impacting nightly testers here which I'm sure you'll agree is a
    small percentage of the Firefox user base and the tools I speak of will
    be out well in advance of the final Firefox 3 release.

    As it happens I have spoken to a few of the mozdev.org admins and they
    appeared happy with the way things were going.

    >> I hope to have something usable available not too long after M8 is
    >> released.

    >
    > So when will M8 be released? People have to guess? Not everyone will
    > know where to look for this kind of info you know.


    M8 is currently scheduled for release around September 18th. Depending
    on workload it's possible we could have a beta release of the tools
    around that time too.

    >> If you want to see more of the specifics the best place to look is
    >> probably at the wiki page at
    >> http://wiki.mozilla.org/User:Mossop:...UpdateSecurity

    >
    > Which is pretty much useless for mozdev.org and other third party add-on
    > provider platforms.


    Sorry, I'm not sure what is useless for third party add-on providers,
    could you elaborate a little please?

    Dave


  4. Re: Add-on security restrictions

    Dave Townsend wrote:
    > Michael Vincent van Rantwijk, MultiZilla wrote:
    >> Dave Townsend wrote:
    >>> Crossposting this to a few newsgroups.
    >>>
    >>> I have just checked in Bug 378216, Disable insecure extension updates
    >>> by default, and wanted to give a quick heads up on it.
    >>>
    >>> What this means is that we are now enforcing a security restriction
    >>> on all add-ons. To be specific, if an add-on does not provide a
    >>> secure method of auto-updating then by default Firefox will refuse to
    >>> install the add-on. If you have add-ons already installed that are
    >>> insecure in this way then they will be automatically disabled.
    >>>
    >>> The good news is that addons.mozilla.org already uses SSL for it's
    >>> updates, so any add-ons you have installed from there will be
    >>> unaffected by this change. Equally any add-on authors who use SSL on
    >>> their site, their add-ons will be unaffected. Personally I found 2 of
    >>> my add-ons were disabled by it, that's 2 out of nearly 20, so
    >>> hopefully you won't see a major impact.
    >>>
    >>> For add-on authors there is an alternate way to provide secure
    >>> updates without investing in an SSL key involving digital signatures,
    >>> unfortunately we've had to hold off on providing the software to make
    >>> that possible until the backend changes were complete and reviewed.

    >>
    >> Does checking in the code *before* providing that software, and thus
    >> screwing add-on authors over at mozdev.org (and their customers) count
    >> for you or what? Obviously not it seems.

    >
    > Unfortunately we are up against platform freeze deadlines so getting the
    > backend in before freeze was the most important issue.


    I see. Thanks for the heads up.

    > Of course we are
    > only impacting nightly testers here which I'm sure you'll agree is a
    > small percentage of the Firefox user base and the tools I speak of will
    > be out well in advance of the final Firefox 3 release.


    Probably yes, but can you please start by letting people know *how* to
    make it work? It might even resolve the issue for most people.

    > As it happens I have spoken to a few of the mozdev.org admins and they
    > appeared happy with the way things were going.


    That's great and all that but mozdev.org admins are not the ones
    providing add-ons to and/or supporting end-users (client, customers or
    whatever) with their add-ons, but that's us the authors.

    No SSL requirement is good, I agree, and this is a change for the better
    (read better security) which is also good, but the timing sucks for
    people who aren't part of amo, for whatever reasons(s), and for people
    using add-ons from them.

    >>> I hope to have something usable available not too long after M8 is
    >>> released.

    >>
    >> So when will M8 be released? People have to guess? Not everyone will
    >> know where to look for this kind of info you know.

    >
    > M8 is currently scheduled for release around September 18th. Depending
    > on workload it's possible we could have a beta release of the tools
    > around that time too.


    That is two weeks, and add-on authors will also need some time to solve
    this issue. Are you a happy camper without the add-ons you need? Would
    you keep testing Firefox without them? I won't.

    >>> If you want to see more of the specifics the best place to look is
    >>> probably at the wiki page at
    >>> http://wiki.mozilla.org/User:Mossop:...UpdateSecurity

    >>
    >> Which is pretty much useless for mozdev.org and other third party
    >> add-on provider platforms.

    >
    > Sorry, I'm not sure what is useless for third party add-on providers,
    > could you elaborate a little please?


    There's no info about the process involved, about how you should add
    keys to add-ons. This missing part of the puzzle should have been there
    before, or right after the CVS commit

    Thanks,

    --
    Michael Vincent van Rantwijk
    - MultiZilla Project Team Lead
    - XUL Boot Camp Staff member (ActiveState Training Partner)
    - iPhone Application Developer


  5. Re: Add-on security restrictions

    Michael Vincent van Rantwijk, MultiZilla wrote:
    > Dave Townsend wrote:
    >> Michael Vincent van Rantwijk, MultiZilla wrote:
    >>> Dave Townsend wrote:
    >>>> I hope to have something usable available not too long after M8 is
    >>>> released.
    >>>
    >>> So when will M8 be released? People have to guess? Not everyone
    >>> will know where to look for this kind of info you know.

    >>
    >> M8 is currently scheduled for release around September 18th. Depending
    >> on workload it's possible we could have a beta release of the tools
    >> around that time too.

    >
    > That is two weeks, and add-on authors will also need some time to solve
    > this issue. Are you a happy camper without the add-ons you need? Would
    > you keep testing Firefox without them? I won't.


    Maybe I'm lucky, but it only disabled 2 of my add-ons

    >>>> If you want to see more of the specifics the best place to look is
    >>>> probably at the wiki page at
    >>>> http://wiki.mozilla.org/User:Mossop:...UpdateSecurity
    >>>
    >>> Which is pretty much useless for mozdev.org and other third party
    >>> add-on provider platforms.

    >>
    >> Sorry, I'm not sure what is useless for third party add-on providers,
    >> could you elaborate a little please?

    >
    > There's no info about the process involved, about how you should add
    > keys to add-ons. This missing part of the puzzle should have been there
    > before, or right after the CVS commit


    I can take some time to write up the technical details of exactly how to
    add a public key to an addon, how to sign the manifest etc. But really
    that is worthless unless you have the software to do it. I would have
    much preferred to make that software available weeks before the landing,
    sadly timing constraints made that impossible.

    Dave

  6. Re: Add-on security restrictions

    Dave Townsend wrote:
    > Michael Vincent van Rantwijk, MultiZilla wrote:
    >> Dave Townsend wrote:
    >>> Michael Vincent van Rantwijk, MultiZilla wrote:
    >>>> Dave Townsend wrote:
    >>>>> I hope to have something usable available not too long after M8 is
    >>>>> released.
    >>>>
    >>>> So when will M8 be released? People have to guess? Not everyone
    >>>> will know where to look for this kind of info you know.
    >>>
    >>> M8 is currently scheduled for release around September 18th.
    >>> Depending on workload it's possible we could have a beta release of
    >>> the tools around that time too.

    >>
    >> That is two weeks, and add-on authors will also need some time to
    >> solve this issue. Are you a happy camper without the add-ons you
    >> need? Would you keep testing Firefox without them? I won't.

    >
    > Maybe I'm lucky, but it only disabled 2 of my add-ons
    >
    >>>>> If you want to see more of the specifics the best place to look is
    >>>>> probably at the wiki page at
    >>>>> http://wiki.mozilla.org/User:Mossop:...UpdateSecurity
    >>>>
    >>>> Which is pretty much useless for mozdev.org and other third party
    >>>> add-on provider platforms.
    >>>
    >>> Sorry, I'm not sure what is useless for third party add-on providers,
    >>> could you elaborate a little please?

    >>
    >> There's no info about the process involved, about how you should add
    >> keys to add-ons. This missing part of the puzzle should have been
    >> there before, or right after the CVS commit

    >
    > I can take some time to write up the technical details of exactly how to
    > add a public key to an addon, how to sign the manifest etc. But really
    > that is worthless unless you have the software to do it.


    Signing shouldn't be hard or too difficult, and I take it you'll need
    freely available tools, right?

    > I would have
    > much preferred to make that software available weeks before the landing,
    > sadly timing constraints made that impossible.


    I understand, and hopefully you too for people with their back against
    the wall.

    --
    Michael Vincent van Rantwijk
    - MultiZilla Project Team Lead
    - XUL Boot Camp Staff member (ActiveState Training Partner)
    - iPhone Application Developer


  7. Re: Add-on security restrictions

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512

    Michael Vincent van Rantwijk, MultiZilla wrote:
    > Signing shouldn't be hard or too difficult, and I take it you'll need
    > freely available tools, right?


    For instance, an OpenPGP compliant tool. It'd be great to have OpenPGP support natively in Firefox.
    Would make things much easier for the openpgp-addons teams (FireGPG / Enigform / Enigmail).

    - --
    Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
    Servicios Ofrecidos: http://www.buanzo.com.ar/pro/
    Unase a los Foros GNU/Buanzo - La palabra Comunidad en su maxima expresion.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFG3LJpAlpOsGhXcE0RChBQAJ92OomGRh1nBx6dATwNaF jMUf22kQCfSPti
    hoqf6eGkyjfJC++HV4qhyvE=
    =JcAJ
    -----END PGP SIGNATURE-----

  8. Re: Add-on security restrictions

    On 9/3/2007 3:48 PM, Dave Townsend wrote:
    > Crossposting this to a few newsgroups.
    >
    > I have just checked in Bug 378216, Disable insecure extension updates by
    > default, and wanted to give a quick heads up on it.
    >
    > What this means is that we are now enforcing a security restriction on
    > all add-ons. To be specific, if an add-on does not provide a secure
    > method of auto-updating then by default Firefox will refuse to install
    > the add-on. If you have add-ons already installed that are insecure in
    > this way then they will be automatically disabled.
    >
    > The good news is that addons.mozilla.org already uses SSL for it's
    > updates, so any add-ons you have installed from there will be unaffected
    > by this change. Equally any add-on authors who use SSL on their site,
    > their add-ons will be unaffected. Personally I found 2 of my add-ons
    > were disabled by it, that's 2 out of nearly 20, so hopefully you won't
    > see a major impact.
    >
    > For add-on authors there is an alternate way to provide secure updates
    > without investing in an SSL key involving digital signatures,
    > unfortunately we've had to hold off on providing the software to make
    > that possible until the backend changes were complete and reviewed. I
    > hope to have something usable available not too long after M8 is released.
    >
    > If you want to see more of the specifics the best place to look is
    > probably at the wiki page at
    > http://wiki.mozilla.org/User:Mossop:...UpdateSecurity
    >
    > Cheers
    >
    > Dave


    What about extensions from Mozdev? Among them are PrefBar, FlashBlock,
    and Mnenhy, all of which are extensively used.

    --

    David E. Ross
    .

    Anyone who thinks government owns a monopoly on inefficient, obstructive
    bureaucracy has obviously never worked for a large corporation. 1997

  9. Re: Add-on security restrictions

    Well here it is, been pushing long and hard to get a release version out
    for you guys. You can now get the McCoy tool from
    http://developer.mozilla.org/en/docs/McCoy and start making your updates
    secure even if you aren't using SSL.

    Please keep in mind that this is an early release version, so there are
    some poorly worded dialogs in there because that's what XULRunner
    provides by default and stuff like that. File bugs on any issues you
    come across.

    Dave

  10. Re: Add-on security restrictions

    Dave Townsend wrote the following on 09-17-2007 4:45 PM:

    > Well here it is, been pushing long and hard to get a release version out
    > for you guys. You can now get the McCoy tool from
    > http://developer.mozilla.org/en/docs/McCoy and start making your updates
    > secure even if you aren't using SSL.
    >
    > Please keep in mind that this is an early release version, so there are
    > some poorly worded dialogs in there because that's what XULRunner
    > provides by default and stuff like that. File bugs on any issues you
    > come across.
    >
    > Dave


    I cannot thank you enough!!!!!!!!!!!!!!!

    --
    Regards,
    CatThief

    To reply privately, please PM me at MozillaZine...
    http://forums.mozillazine.org/profil...rofile&u=25774

+ Reply to Thread