info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Signed Extensions
40 views
Skip to first unread message
David E. Ross
May 30, 2015, 10:28:32 PM5/30/15
to
When existing extensions are signed and made available at
addons.mozilla.org to comply with bug 238960, the file names must be
made distinct. Otherwise, users cannot distinguish their archived .xpi
files that are signed from those that are not signed. (Yes, users do
indeed archive .xpi files.) This is a basic principle of configuration
management.
Followup-To: mozilla.dev.planning
--
David E. Ross
I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.
addons.mozilla.org to comply with bug 238960, the file names must be
made distinct. Otherwise, users cannot distinguish their archived .xpi
files that are signed from those that are not signed. (Yes, users do
indeed archive .xpi files.) This is a basic principle of configuration
management.
Followup-To: mozilla.dev.planning
--
David E. Ross
I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.
David E. Ross
Jun 2, 2015, 11:49:47 PM6/2/15
to
On 5/30/2015 7:28 PM, David E. Ross wrote:
> When existing extensions are signed and made available at
> addons.mozilla.org to comply with bug 238960, the file names must be
> made distinct. Otherwise, users cannot distinguish their archived .xpi
> files that are signed from those that are not signed. (Yes, users do
> indeed archive .xpi files.) This is a basic principle of configuration
> management.
>
> Followup-To: mozilla.dev.planning
>
Furthermore, maximum application versions in the install.rdf file --
> When existing extensions are signed and made available at
> addons.mozilla.org to comply with bug 238960, the file names must be
> made distinct. Otherwise, users cannot distinguish their archived .xpi
> files that are signed from those that are not signed. (Yes, users do
> indeed archive .xpi files.) This is a basic principle of configuration
> management.
>
> Followup-To: mozilla.dev.planning
>
item <em:maxVersion> -- are not being updated to reflect current versions.
Daniel Veditz
Jun 3, 2015, 1:39:58 PM6/3/15
to dev-pl...@lists.mozilla.org
Why would we update the maxVersion or anything else? We're signing the
archive, not modifying it any more than necessary. If the existing
maxVersion works then it will still work; if the existing maxVersion
doesn't work then the author should already have plans to update it and it
will get re-signed when that happens.
I don't understand your comment about the filenames. None of the add-ons I
have installed have versions as part of the name. How many people are
actually reaching into our CDN and using the internal filename? In any case
the signed/not-signed versions were not intended to be different in any
meaningful way and only have a different version as a hack to trigger an
update. You'd have better luck reaching the AMO developers in an
addons-related forum rather than here. I'm guessing the damage is done and
it's not worth re-generating all the signed files to fix it at this point,
and for future add-on updates it won't be an issue since there will only
ever be the signed version.
-Dan Veditz
archive, not modifying it any more than necessary. If the existing
maxVersion works then it will still work; if the existing maxVersion
doesn't work then the author should already have plans to update it and it
will get re-signed when that happens.
I don't understand your comment about the filenames. None of the add-ons I
have installed have versions as part of the name. How many people are
actually reaching into our CDN and using the internal filename? In any case
the signed/not-signed versions were not intended to be different in any
meaningful way and only have a different version as a hack to trigger an
update. You'd have better luck reaching the AMO developers in an
addons-related forum rather than here. I'm guessing the damage is done and
it's not worth re-generating all the signed files to fix it at this point,
and for future add-on updates it won't be an issue since there will only
ever be the signed version.
-Dan Veditz
0 new messages