Re: Searchfox now indexing m-beta, m-release, m-esr60

[Onno Ekker]

Op 12-3-2019 om 19:15 schreef Kartikaya Gupta:
> Due to popular demand, searchfox now also has
> mozilla-{beta,release,esr60} repos. Text search only for now; blame
> should appear within a couple of days or so. Follow along on bug
> 1282123 or just mash F5 periodically to find out when exactly.
> Rust/C++ indexing for beta and release will happen sometime after bug
> 1533801 arrives on those branches via the code train. Choo-choo!
> 
> Cheers,
> kats
> 

This is great, although it would be even more great if dxr would work
again for all products and branches...

See unassigned bug https://bugzil.la/1527889 - comm-central files are
out of date.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Onno Ekker]

On 12/03/2019 18:59, Sylvestre Ledru wrote:
> Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
>> 
>> Secondly, to bikeshed a little, could there be some name besides
>> "task" for
>> that third category? Like I said above, everything we work as
>> developers is
>> a developer task. "Refactor" seems like a clearer name, though maybe
>> it is
>> a little limiting. "Side grade"? :)
> 
> This is more than just refactoring. It is more "as an engineer, here is
> what I have to do".

Maybe call it "Engineering"? "Maintenance"?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_ALLOW_DOWNGRADE environment variable

[Onno Ekker]

Op 6-3-2019 om 18:26 schreef smaug:
> Hi all,
> 
> 
> looks like I didn't send email about, IMO, rather useful environment
> variable [1]:
> MOZ_ALLOW_DOWNGRADE does the same thing as --allow-downgrade passed to
> firefox,
> bypasses the profile downgrade protection.
> (At least I need to bypass that all the time when testing various local
> and/or nightly builds.)
> 
> 
> 
> -Olli
> 
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1528502


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Onno Ekker]

Hi David,

Thank you for your reply and the bug numbers.

It was still working for Thunderbird/SeaMonkey, which were based on
Gecko 52, and which still support legacy add-ons. They plan on keep
supporting legacy add-ons past Gecko 56/57 also, but I guess it will be
without the old add-on signing experience then.

Onno


Op 22-9-2017 om 18:27 schreef David Keeler:
> Hi Onno,
> 
> The work was done in bug 1382749. The first post in this thread outlined
> what would be removed as a result of doing this - namely the upper right
> corner of the label in the add-on installation dialog as you mentioned.
> Note that as of bug 1366243 (shipping in 56), by default Gecko-based
> products don't trust any code-signing roots, so this wouldn't work as
> before even without removing the now-dead code.
> 
> Cheers,
> David
> 
> On 09/22/2017 01:35 AM, Onno Ekker wrote:
>> Op 27-7-2017 om 07:03 schreef Andrew Swan:
>>> On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl <f...@gmx.com> wrote:
>>>
>>>> I need to look at the notifications for SeaMonkey anyway but how could
>>>> Thunderbird implement the standard doorhanger with no location bar? I think
>>>> the dialog should be retained for projects which do not have a location bar
>>>> and/or tabbrowser.
>>>
>>>
>>> That was poorly worded -- these applications should create listeners for
>>> the various events that are generated during the install process.  Whether
>>> you try to adapt the Firefox doorhangers somehow or keep some version of
>>> the current dialog (but apropos the original message in this thread, even
>>> that is likely to change) doesn't matter to me, but the existing code that
>>> displays a modal xul dialog from the guts of the addons manager isn't long
>>> for this world...
>>>
>>> This is straying off-topic for dev-platform, please follow up with me
>>> individually or on the dev-addons list if you have more questions.
>>>
>>> -Andrew
>>>
>>
>> Did something change here in TB/SM-code or in the methods they call?
>> When I now add/update an add-on manager (in TB 57.0a1), I don't see any
>> notice about the signature anymore. The upper right corner from my
>> previous screenshot is now empty.
>>
>> Is this on purpose or did something break? If on purpose, it would be
>> nice if it could be communicated. My old signing key is about to expire
>> and in order to get a new key, the CA now requires me to store it on a
>> smart card, so I almost bought a smart card and a card reader and
>> renewed my signing certificate for the price of some € 130,- and it
>> would be totally useless.
>>
>> Is there a bug about the removing of the "old way" of signing add-ons?
>>
>> Onno
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Onno Ekker]

Op 27-7-2017 om 07:03 schreef Andrew Swan:
> On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl  wrote:
> 
>> I need to look at the notifications for SeaMonkey anyway but how could
>> Thunderbird implement the standard doorhanger with no location bar? I think
>> the dialog should be retained for projects which do not have a location bar
>> and/or tabbrowser.
> 
> 
> That was poorly worded -- these applications should create listeners for
> the various events that are generated during the install process.  Whether
> you try to adapt the Firefox doorhangers somehow or keep some version of
> the current dialog (but apropos the original message in this thread, even
> that is likely to change) doesn't matter to me, but the existing code that
> displays a modal xul dialog from the guts of the addons manager isn't long
> for this world...
> 
> This is straying off-topic for dev-platform, please follow up with me
> individually or on the dev-addons list if you have more questions.
> 
> -Andrew
> 

Did something change here in TB/SM-code or in the methods they call?
When I now add/update an add-on manager (in TB 57.0a1), I don't see any
notice about the signature anymore. The upper right corner from my
previous screenshot is now empty.

Is this on purpose or did something break? If on purpose, it would be
nice if it could be communicated. My old signing key is about to expire
and in order to get a new key, the CA now requires me to store it on a
smart card, so I almost bought a smart card and a card reader and
renewed my signing certificate for the price of some € 130,- and it
would be totally useless.

Is there a bug about the removing of the "old way" of signing add-ons?

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing "the old way" of signing add-ons

[Onno Ekker]

Op 7/23/2017 om 2:12 AM schreef Andrew Swan:
> On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch  wrote:
> 
>> Since you're saying that we're still using the old interface, in fact
>> Andrew said: "old add-on install
>> confirmation dialog, that dialog includes a note about the certificate",
>> would you be able to give us some exact DXR references which would save us
>> a lot of searching.
>>
> 
> The dialog I mentioned is:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallConfirm.xul
> 
> The listbox in that dialog holds instances of:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/xpinstallItem.xml
> 
> The label in those items with the class "xpinstallItemSigned" ends up
> holding either certificate details or some default message like "Author not
> verified"
> 
> While we're on the topic, Thunderbird and Seamonkey should look at moving
> over to the doorhanger addon install flow that Firefox uses -- that xul
> dialog and everything that supports it are unused in Firefox and its days
> are numbered.
> 
> -Andrew
> 

Looks like this indeed still used by both Thunderbird and SeaMonkey:
http://i.imgur.com/Q7tQIsN.png (sorry for the Dutch screenshot).
I've also verified with DOM Inspector, that this is indeed above
mentioned dialog window.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming SSH Host Key Rotation for hg.mozilla.org

[Onno Ekker]

Op 5-4-2016 om 3:09 schreef Philip Chee:
> On 04/04/2016 23:52, Gregory Szorc wrote:
>> We also changed the SSH server config to only support the "modern" set of
>> ciphers, MACs, algorithms, etc from
>> https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern. If you are
>> running an old SSH client, it may not be able to connect.
>>
>> If you encounter problems connecting, complain in #vcs with a link to
>> pastebinned `ssh -v` output so we can see what your client supports so we
>> may consider adding legacy support on the server as a stop-gap. But
>> upgrading your SSH client to something that supports modern crypto is
>> highly preferred. More and more Mozilla systems will be adopting these
>> "modern" SSH server settings. So you'll have to upgrade sometime.
> 
> I'm using TortoiseHg whichh uses PuTTY and PLINK internally. I've
> deleted the mozilla host key and accepted the new one.
> 
> Now I can't push to comm-central via TortoiseHg. I can't push directly
> via hg.exe either. Putty error message is uninformative.
> 
> Phil
> 
> 

I had my old SSH-key not only stored as hg.mozilla.org, but also as
numeric ip-address, which prevented the new one from working correctly.
Maybe something similar also happens for you?
Check your ~/.ssh/known_hosts file.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documenting uses of Github at Mozilla

[Onno Ekker]

On 9/30/2014 11:44 PM, Eric Shepherd wrote:
 Last week the idea came up that it would be helpful to create a list on
 MDN of the Mozilla projects that are on GitHub, with links to those
 sites. I have two questions:
 
 1. Do we already have such a list anywhere?
 
 2. If you have a project (or projects) on Github, please let me know!
 I'd like to make sure people know where it is if they're looking for it.
 

Please define Mozilla projects.

I have my Thunderbird extension mirrored on GitHub and I know there are
a couple more projects hosted there. If you want to include those in
your list, it is probably best to also post in mozilla.dev.extensions...

Also I'd like to know why you seem to limit this to GitHub. I think
there are Mozilla projects hosted on other repository sites, like
Mozdev, Google Code, SourceForge or BitBucket.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Add-on File Registration PRD

[Onno Ekker]

Jorge Villalobos wrote:
 Cross posting to dev.planning, where I originally intended this to be.
 Please follow up to dev.planning.
 
 Jorge
 
 On 10/30/13 3:42 PM, Jorge Villalobos wrote:
 Hello!

 As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
 and others have been collaborating for over a year in a project called
 Squeaky [1]. Our aim is to improve user experience for add-ons,
 particularly add-ons that we consider bad for various levels of bad.

 Part of our work consists on pushing forward improvements in Firefox
 that we think will significantly achieve our goals, which is why I'm
 submitting this spec for discussion:

 https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing

 The Add-on File Registration System is intended to create an add-on file
 repository that all add-on developers need to submit their files to.
 This repository won't publish any of the files, and inclusion won't
 require more than passing a series of automatic malware checks. We will
 store the files and generated hashes for them.

 On the client side, Firefox will compute the hashes of add-on files
 being installed and query the API for it. If the file is registered, it
 can be installed, otherwise it can't (there is planned transition period
 to ease adoption). There will also be periodic checks of installed
 add-ons to make sure they are registered. All AMO files would be
 registered automatically.

 This system will allow us to better keep track of add-on IDs, be able to
 easily find the files they correspond to, and have effective
 communication channels to their developers. It's not a silver bullet to
 solve add-on malware problems, but it raises the bar for malware developers.

 We believe this strikes the right balance between a completely closed
 system (where only AMO add-ons are allowed) and the completely open but
 risky system we currently have in place. Developers are still free to
 distribute add-ons as they please, while we get a much-needed set of
 tools to fight malware and keep it at bay.

 There are more details in the doc, so please give it a read and post
 your comments and questions on this thread.

 Jorge Villalobos
 Add-ons Developer Relations Lead

 [1] https://wiki.mozilla.org/AMO/Squeaky

 

Hi,

I have another use case which isn't clearly described by the current doc.

I have an English version of Firefox/Thunderbird installed with
additional language packs from
http://ftp.mozilla.org/pub/mozilla.org/%APP%/%CHANNEL%/%VERSION%/%OS%/xpi/.

After each update I have to manually add the language packs again.
Those files are created by Mozilla but aren't published to amo.

It would be a real shame if it wouldn't be possible anymore to add
different languages to your installation.

Onno

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Add-on File Registration PRD

[Onno Ekker]

On 10/30/2013 10:55 PM, Jorge Villalobos wrote:
 Cross posting to dev.planning, where I originally intended this to be.
 Please follow up to dev.planning.
 
 Jorge
 
 On 10/30/13 3:42 PM, Jorge Villalobos wrote:
 Hello!

 As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
 and others have been collaborating for over a year in a project called
 Squeaky [1]. Our aim is to improve user experience for add-ons,
 particularly add-ons that we consider bad for various levels of bad.

 Part of our work consists on pushing forward improvements in Firefox
 that we think will significantly achieve our goals, which is why I'm
 submitting this spec for discussion:

 https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing

 The Add-on File Registration System is intended to create an add-on file
 repository that all add-on developers need to submit their files to.
 This repository won't publish any of the files, and inclusion won't
 require more than passing a series of automatic malware checks. We will
 store the files and generated hashes for them.

 On the client side, Firefox will compute the hashes of add-on files
 being installed and query the API for it. If the file is registered, it
 can be installed, otherwise it can't (there is planned transition period
 to ease adoption). There will also be periodic checks of installed
 add-ons to make sure they are registered. All AMO files would be
 registered automatically.

 This system will allow us to better keep track of add-on IDs, be able to
 easily find the files they correspond to, and have effective
 communication channels to their developers. It's not a silver bullet to
 solve add-on malware problems, but it raises the bar for malware developers.

 We believe this strikes the right balance between a completely closed
 system (where only AMO add-ons are allowed) and the completely open but
 risky system we currently have in place. Developers are still free to
 distribute add-ons as they please, while we get a much-needed set of
 tools to fight malware and keep it at bay.

 There are more details in the doc, so please give it a read and post
 your comments and questions on this thread.

 Jorge Villalobos
 Add-ons Developer Relations Lead

 [1] https://wiki.mozilla.org/AMO/Squeaky

 

Can everyone submit an add-on to Squeaky? Or only the add-on developer?
I ask this because to me it's not clear what happens to the metadata,
like in install.rdf. It's still necessary sometimes to edit this file,
especially for the targetApplication's maxVersion. There are also other
local edits (forks or branches) possible to existing add-ons, that are
not (yet) in the official version.

Onno
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform