Taskcluster index: gecko.v1 routes are going away

[Michael Shal]

Hi all,

Builds will no longer publish to the gecko.v1 namespace in the Taskcluster
index. Please use gecko.v2 for any future projects that need to find
artifacts in Taskcluster.

Feel free to contact me with any questions!

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

Want to learn TLS certificate verification best practices

[Ben Cottrell]

Hi all,

I'm working on an (unfortunately closed-source) project that needs
to closely approximate the behavior of an actual web browser, in
the limited scope of making HTTPS connections and accurately warning
about certificate problems. So I need to learn about "what real
browsers do" and it seems to me that the people on this list are
probably some pretty good giants to stand on the shoulders of!

Here's what I've read already:
* Joshua Davies, "Implementing SSL/TLS," chapter 5 ("creating
  a network of trust using X.509 certificates")
* RFC5280 section 6 (path validation)
* RFC6960 (OCSP)
* RFC6066 section 8 (OCSP stapling)
* RFC6961 (multiple-response OCSP stapling)
So I have an idea of what kinds of protocols and standards are out
there, but what I'm missing is how (and to what extent) all these
protocols get used in practice by real browsers.

I think I have two main questions:

1. In as much detail as possible, what steps does Firefox take to
   verify certificates? If there's a formal engineering spec that
   describes the whole process, I'd love a pointer to it.

   Specifically, I'm interested in questions like: Does Firefox even
   bother with "traditional" CRLs, or does it rely entirely on OCSP
   and/or stapling from the server? What X.509 extensions does it pay
   attention to on the certificates? Does Firefox implement the
   entirety of RFC5280 section 6 or does it omit things like policy
   mapping and permitted subtrees? Does it use Authority Key
   Identifier / Subject Key Identifier, as the RFC suggests, *only* in
   cases where the issuer/subject DNs are ambiguous, or does it treat
   the key identifiers (if present) as the primary source of truth?

2. How bad is OpenSSL's certificate-verifying behavior, really? I know
   you folks felt like you had to write mozilla::pkix from scratch to
   get the quality you needed. And it's true that I haven't yet tried
   to make OpenSSL do OCSP, so I'm not sure yet how hard that will be.

   But just talking about the basic bread and butter of RFC5280 section
   6, if we populate the certificate store, turn on SSL_VERIFY_PEER,
   and just let it do its thing, would we be getting behavior that is
   95% the same as what a real browser would do? 80% the same? 40%?

I'd also be happy with pointers to best-practices type documents that
you folks trust. What did the people who wrote mozilla::pkix read, as
preparation for that project? 

Thanks!!

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

Re: Proposed W3C Charter: Web Platform Working Group

[L. David Baron]

On Friday 2016-09-30 14:02 -0700, Tantek Çelik wrote:
> Also, just found this in the charter:
>   announcement
> Not really acceptable.

I think it should link to the same URL as the other "(announcement)"
link.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Platform Working Group

[Tantek Çelik]

On Fri, Sep 30, 2016 at 12:51 PM, L. David Baron  wrote:
> On Thursday 2016-09-29 07:46 -0700, Tantek Çelik wrote:
>> > Marked as deliverables to be taken up if incubation suggests likely 
>> > success:
>> >  Background Synchronisation; Filesystem API; FindText API; HTML Import; 
>> > Input Methods; Packaging; Quota API
>>
>> This section is confusing and weakly worded.
>>
>> Expanded just below this link:
>> https://www.w3.org/2016/08/web-platform-charter-draft.html#web-workers
>> as Potential deliverables (no id / fraglink)
>>
>> Either these are some sort of odd pre-incubation special treatment
>> (bad / unnecessary in a charter), or if this is a claim that the
>> listed specs *have* passed incubation, I'd expect citations that
>> document as such (not just a link to an intent template). Otherwise
>> wait for specs to pass incubation, document as such, and then propose
>> a charter update with actual (not "potential") deliverables.
>>
>> I'd prefer that these "Potential deliverables" be dropped (FO), unless
>> citations are provided to incubation successes, and if so, then just
>> make them "deliverables".
>
> I'm a little concerned about making this a formal objection.
> Rechartering is a somewhat painful process, and if a group thinks
> that a particular incubation project is likely to suceed in the near
> future and doesn't want to have to recharter again, it seems
> reasonable to allow them to say that they'd like the result of that
> incubation to be in their charter scope.

That reasoning works for me.

However:

> Or are these things that are just starting out rather than things
> that have been in progress for a while?  (That seems unlikely, since
> I've been hearing about some of them for quite a while.)

I don't know for each of the specific items, so I'm going to dig
deeper and see if I can determine their relative incubation maturity.
I too have been hearing about some of them for a while (e.g. BG sync).

I would have preferred that any such item come with a citation of a
specific "Intent to Migrate"[1] post with details for evaluation per
the WICG/WPWG's own processes but I'm not seeing any.

Also, just found this in the charter:
  announcement
Not really acceptable.

Tantek

[1] https://wicg.github.io/admin/intent-to-migrate.html

>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: hg.mozilla.org certificate fingerprint changed?

[ISHIKAWA,chiaki]

On 2016/10/01 4:23, Ralph Giles wrote:

The change was announced here and on firefox-dev a few weeks ago. See
for example 
https://groups.google.com/d/msg/mozilla.dev.platform/LOC83qKUPfk/cZtmaEbOAwAJ


Obviously I missed it during a busy trip. Thank you.
(It would be nice to have the announcement on dev-apps-thunderbird and 
dev-builds ML as well. I would have noticed this if all these MLs have 
the announcement...)



It might be nice if `mach mercurial-setup` did this kind of update?


As Gregory Szorc  already noted, it is an egg and 
chicken problem. As a matter of fact, I tried "mach mercurial-setup" 
just in case, and bumped into the already outdated cert issue since

the data/code used by mach mercurial-setup is taken from hg.mozilla.org.

My |hg| is 3.9.1, but I am not sure if my Python is new enough so that 
the security handling mentioned by Gregory works or not.


Short of automation and one-time announcement,
it may be a good idea to have a secure web page that lists the latest 
fingerprint of certs used by major mozilla servers that users interact 
DIRECTLY (bugzilla and hg come to my mind.)
Then many of us can calmly check the fingerprints for the servers when 
some mismatch is reported by tools like ssh/https-related tools, and 
decide to update the local check/verification data assuming that they 
have missed the update announcements.


TIA



 -r

On Fri, Sep 30, 2016 at 12:18 PM, ISHIKAWA,chiaki  wrote:

In the last few days, hg.mozilla.org certificate fingerprint seems to have
changed.
I noticed this because the trial to update local copy of mozilla-central
repository within C-C repository failed due to

m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
pulling from https://hg.mozilla.org/mozilla-central/
abort: certificate for hg.mozilla.org has unexpected fingerprint
73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56
(check hostfingerprint configuration)

But I did not see any announcement of this change.
(It is possible that I missed it during a hectic schedule during a trip).

However, it is great to see a posting of such major infra change in advace,
especially security-related one.

Finally, I bit the bullet and changed it, but checked bugzilla
just in case, and found
https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
which seems to be related.

Automation is nice, but I still would like to see an announcement of server
certificate change in advance.

TIA


___
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




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

Re: hg.mozilla.org certificate fingerprint changed?

[Ralph Giles]

On Fri, Sep 30, 2016 at 12:33 PM, Gregory Szorc  wrote:
> `mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the
> version-control-tools repository, which is where most of the logic for `mach
> mercurial-setup` lives (because we have a nice testing harness in
> version-control-tools). `mach mercurial-setup` doesn't pin the hash when
> invoking `hg pull` because to do so would require vendoring the hash in the

> ... that means if you ran `mach mercurial-setup` on an old revision,
> the pinned hash would be guaranteed to be incorrect and the connection would
> always fail.

Hmm. We should be able to use the fact that keys aren't reused. What
if mercurial-setup had a vendored list of keys it knows have been
rotated out in the past and another list which will be rotated in in
the future of that particular revision? It could safely remove the
former if it finds them in .hgrc because if you were able to pull a
revision with that key marked expired, that should still be true when
it's invoked later. Since mercurial 3.8 and later support multiple
fingerprints, it would be safe to add any expected-to-be-used keys, as
long as they aren't later compromised. Setting some kind of time
window beyond which mercurial-setup doesn't attempt to install new
keys would limit the potential damage. No worse that trusting a
particular TLS config?

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

Re: Proposed W3C Charter: Web Platform Working Group

[L. David Baron]

On Thursday 2016-09-29 07:46 -0700, Tantek Çelik wrote:
> > Marked as deliverables to be taken up if incubation suggests likely success:
> >  Background Synchronisation; Filesystem API; FindText API; HTML Import; 
> > Input Methods; Packaging; Quota API
> 
> This section is confusing and weakly worded.
> 
> Expanded just below this link:
> https://www.w3.org/2016/08/web-platform-charter-draft.html#web-workers
> as Potential deliverables (no id / fraglink)
> 
> Either these are some sort of odd pre-incubation special treatment
> (bad / unnecessary in a charter), or if this is a claim that the
> listed specs *have* passed incubation, I'd expect citations that
> document as such (not just a link to an intent template). Otherwise
> wait for specs to pass incubation, document as such, and then propose
> a charter update with actual (not "potential") deliverables.
> 
> I'd prefer that these "Potential deliverables" be dropped (FO), unless
> citations are provided to incubation successes, and if so, then just
> make them "deliverables".

I'm a little concerned about making this a formal objection.
Rechartering is a somewhat painful process, and if a group thinks
that a particular incubation project is likely to suceed in the near
future and doesn't want to have to recharter again, it seems
reasonable to allow them to say that they'd like the result of that
incubation to be in their charter scope.

Or are these things that are just starting out rather than things
that have been in progress for a while?  (That seems unlikely, since
I've been hearing about some of them for quite a while.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: hg.mozilla.org certificate fingerprint changed?

[Gregory Szorc]

`mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the
version-control-tools repository, which is where most of the logic for
`mach mercurial-setup` lives (because we have a nice testing harness in
version-control-tools). `mach mercurial-setup` doesn't pin the hash when
invoking `hg pull` because to do so would require vendoring the hash in the
repo and that means if you ran `mach mercurial-setup` on an old revision,
the pinned hash would be guaranteed to be incorrect and the connection
would always fail. We /could/ hardcode the certificate expiration date and
refuse to pin when it is known expired. But if we rotate the cert early,
you're back to a pinned cert failure. Security is hard.

As of a week ago, `mach mercurial-setup` doesn't pin certs if Python +
Mercurial is secure, where "secure" means Mercurial 3.9 and a Python that
can speak modern TLS foo (which sadly many Python installations do not
support, including the system Python on OS X). So unless you are the super
paranoid type who doesn't trust your trusted CA bundle, you can delete the
pinned fingerprints from your hgrc. If `mach mercurial-setup` thinks your
Python+Mercurial is insecure, it will re-add them.

On Fri, Sep 30, 2016 at 12:23 PM, Ralph Giles  wrote:

> The change was announced here and on firefox-dev a few weeks ago. See
> for example https://groups.google.com/d/msg/mozilla.dev.platform/
> LOC83qKUPfk/cZtmaEbOAwAJ
>
> It might be nice if `mach mercurial-setup` did this kind of update?
>
>  -r
>
> On Fri, Sep 30, 2016 at 12:18 PM, ISHIKAWA,chiaki 
> wrote:
> > In the last few days, hg.mozilla.org certificate fingerprint seems to
> have
> > changed.
> > I noticed this because the trial to update local copy of mozilla-central
> > repository within C-C repository failed due to
> >
> > m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
> > pulling from https://hg.mozilla.org/mozilla-central/
> > abort: certificate for hg.mozilla.org has unexpected fingerprint
> > 73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56
> > (check hostfingerprint configuration)
> >
> > But I did not see any announcement of this change.
> > (It is possible that I missed it during a hectic schedule during a trip).
> >
> > However, it is great to see a posting of such major infra change in
> advace,
> > especially security-related one.
> >
> > Finally, I bit the bullet and changed it, but checked bugzilla
> > just in case, and found
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
> > which seems to be related.
> >
> > Automation is nice, but I still would like to see an announcement of
> server
> > certificate change in advance.
> >
> > TIA
> >
> >
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: hg.mozilla.org certificate fingerprint changed?

[Ralph Giles]

The change was announced here and on firefox-dev a few weeks ago. See
for example 
https://groups.google.com/d/msg/mozilla.dev.platform/LOC83qKUPfk/cZtmaEbOAwAJ

It might be nice if `mach mercurial-setup` did this kind of update?

 -r

On Fri, Sep 30, 2016 at 12:18 PM, ISHIKAWA,chiaki  wrote:
> In the last few days, hg.mozilla.org certificate fingerprint seems to have
> changed.
> I noticed this because the trial to update local copy of mozilla-central
> repository within C-C repository failed due to
>
> m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
> pulling from https://hg.mozilla.org/mozilla-central/
> abort: certificate for hg.mozilla.org has unexpected fingerprint
> 73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56
> (check hostfingerprint configuration)
>
> But I did not see any announcement of this change.
> (It is possible that I missed it during a hectic schedule during a trip).
>
> However, it is great to see a posting of such major infra change in advace,
> especially security-related one.
>
> Finally, I bit the bullet and changed it, but checked bugzilla
> just in case, and found
> https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
> which seems to be related.
>
> Automation is nice, but I still would like to see an announcement of server
> certificate change in advance.
>
> TIA
>
>
> ___
> 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

hg.mozilla.org certificate fingerprint changed?

[ISHIKAWA,chiaki]

In the last few days, hg.mozilla.org certificate fingerprint seems to  
have changed.
I noticed this because the trial to update local copy of mozilla-central  
repository within C-C repository failed due to


m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
pulling from https://hg.mozilla.org/mozilla-central/
abort: certificate for hg.mozilla.org has unexpected fingerprint  
73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56

(check hostfingerprint configuration)

But I did not see any announcement of this change.
(It is possible that I missed it during a hectic schedule during a trip).

However, it is great to see a posting of such major infra change in  
advace, especially security-related one.


Finally, I bit the bullet and changed it, but checked bugzilla
just in case, and found
https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
which seems to be related.

Automation is nice, but I still would like to see an announcement of  
server certificate change in advance.


TIA


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

Heads Up: Mac CFMessagePort/CFPasteboardSetup Error Messages

[Haik Aftandilian]

Since the integration of bug 1299329
​[1] ​
​in Nightly, these error messages are printed to the terminal and
system.log so you'll see them when running Firefox from the command line on
Mac.
​They are not known to cause any browser issues so you can ignore them.
These are due to sandbox restrictions imposed on content processes.
​ I filed bug 1306663[2] to track the work to remove the messages. More
context on 1299329​ for those interested.​


plugin-container[96229:2989903] *** CFMessagePort: bootstrap_register():
failed 1100 (0x44c) 'Permission denied', port = 0x4b2f, name =
'com.apple.tsm.portname'
See /usr/include/servers/bootstrap_defs.h for the error codes.

plugin-container[96229:2989903] void __CFPasteboardSetup() : Failed to
allocate communication port for com.apple.CFPasteboardClient; this is
likely due to sandbox restrictions

​1. ​*Bug 1299329*
 - Remove
printing-related privileges from content process sandbox
2. *Bug 1306663*
 - Investigate
Preventing OS X CFMessagePort/CFPasteboardSetup Error Messages

​Thanks,
Haik​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removal of B2G from mozilla-central

[Benjamin Francis]

On 30 September 2016 at 11:31, Gabriele Svelto  wrote:

> Since gonk is a widget on its own, during the internal discussions about
> it I - and others who worked on B2G - repeatedly asked for the gonk
> widget to be left in the code even after the removal of all the
> B2G-specific APIs (as a tier3 platform obviously).
>
...

> - We would still have the functionality to render web content into the
> low-levels of the Android graphics stack
>

+1

I still personally think that the Gonk widget layer is a valuable asset in
its own right and that we may eventually find that we need it in Connected
Devices. If it helps, think of it as the Brillo widget layer given Gonk is
much the same thing as Google Brillo (AOSP minus Java).

Part of the B2G decision appears to be to remove this code, but it's true
there was no public discussion about this as there was with the Qt widget
layer where the option was given for someone to volunteer to maintain it.

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

Re: Removal of B2G from mozilla-central

[Gabriele Svelto]

On 30/09/2016 06:04, Chris Peterson wrote:
> Is Gonk used anywhere besides B2G? Can we remove all Gonk code, e.g.
> dom/camera/Gonk* and #ifdef MOZ_WIDGET_GONK?

Gonk is not used anywhere else, some of it's code was merged with
Fennec's code to reduce the maintenance burden but there's still quite a
bit that's B2G-specific.

Since gonk is a widget on its own, during the internal discussions about
it I - and others who worked on B2G - repeatedly asked for the gonk
widget to be left in the code even after the removal of all the
B2G-specific APIs (as a tier3 platform obviously).

This would allow a few things to happen:

- We would still have the functionality to render web content into the
low-levels of the Android graphics stack

- We could keep developing B2G OS using fully web APIs by implementing
all the B2G-specific bits in external daemons with web-facing interfaces
that would live out of mozilla-central

As far as mozilla-central is concerned this would mean that all gonk
directories for non-standard APIs would still be removed, this includes:

- dom/media/platforms/gonk
- dom/cellbroadcast/gonk
- dom/system/gonk
- dom/secureelement/gonk
- dom/nfc/gonk
- dom/telephony/gonk
- dom/mobilemessage/gonk
- dom/icc/gonk
- dom/mobileconnection/gonk
- dom/wappush/gonk
- dom/voicemail/gonk

All the code protected by MOZ_WIDGET_GONK but B2G-specific would still
be removed, that means pretty much all the code under netwerk, dom,
security, etc...

What would be left would be essentially:

hal/gonk
widget/gonk

The amount of code in both directories would be cut down significantly
though as all the code needed to support the non standard APIs would be
removed.

We'd still have some MOZ_WIDGET_GONK-specific stuff under gfx/ and
media/ but it's not much and I wouldn't mind removing all the
non-necessary stuff (e.g. screen recording, overlays, ...). Besides
being tier3 nobody should mind breaking it. We'd fix it up ourselves.

Since there's not been a public discussion on this like we had for the
Qt widget [1] I'd like to talk about it here. Note that I've been
personally taking part in the efforts of removing the B2G-specific APIs
mostly because I know how they work and what non-obvious parts of our
codebase they affect.

 Gabriele

[1] https://lists.mozilla.org/pipermail/dev-platform/2016-June/015447.html



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform